From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 15:11:20 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6207B2EE for ; Mon, 27 Apr 2015 15:11:20 +0000 (UTC) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1991B110D for ; Mon, 27 Apr 2015 15:11:19 +0000 (UTC) Received: from mail-in-02-z2.arcor-online.net (mail-in-02-z2.arcor-online.net [151.189.8.14]) by mx.arcor.de (Postfix) with ESMTP id 3lb7zN20hQzY4Zr for ; Mon, 27 Apr 2015 16:39:28 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-02-z2.arcor-online.net (Postfix) with ESMTP id 37677718E7B for ; Mon, 27 Apr 2015 16:39:28 +0200 (CEST) X-Greylist: Passed host: 188.104.143.26 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3lb7zN0Vflz8Fc9 Received: from lorvorc.mips.inka.de (dslb-188-104-143-026.188.104.pools.vodafone-ip.de [188.104.143.26]) by mail-in-06.arcor-online.net (Postfix) with ESMTPS id 3lb7zN0Vflz8Fc9 for ; Mon, 27 Apr 2015 16:39:27 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3REdRXt001390 for ; Mon, 27 Apr 2015 16:39:27 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3REdRca001389 for freebsd-hackers@freebsd.org; Mon, 27 Apr 2015 16:39:27 +0200 (CEST) (envelope-from news) To: freebsd-hackers@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.hackers Subject: System clock always unsynced Date: Mon, 27 Apr 2015 14:39:27 +0000 (UTC) Lines: 32 Message-ID: X-Trace: lorvorc.mips.inka.de 1430145567 276 ::1 (27 Apr 2015 14:39:27 GMT) X-Complaints-To: usenet@mips.inka.de User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:11:20 -0000 I run OpenNTPD, from ports/net/openntpd, and I've noticed that after each reboot, the initial system time is further off. (This is quite noticeable with OpenNTPD, since by default it does *not* jump the clock on startup like the base ntpd does.) It's as if the RTC was never synchronized to the system clock. Some digging in sys/kern/kern_ntptime.c shows indeed that the RTC is only synced if STA_UNSYNC is not set, and dumping the value of the timex struct... offset: 0 freq: 2730304 maxerror: 84860000 esterror: 500000 status: UNSYNC constant: 0 precision: 0 tolerance: 32500000 state: ERROR ... reveals that the clock remains permanently unsynced. Clearly, OpenNTPD, which uses adjtime(2) to correct offsets and ntp_adjtime(2) with MOD_FREQUENCY to correct the frequency, doesn't handle this quite right. What *does* an ntpd daemon need to do to sync the clock? The ntp_adjtime(2) man page documents struct timex in detail, but is very vague on what all of this means. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 15:22:42 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C76A59ED for ; Mon, 27 Apr 2015 15:22:42 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 914B812FE for ; Mon, 27 Apr 2015 15:22:42 +0000 (UTC) Received: by igblo3 with SMTP id lo3so63949493igb.0 for ; Mon, 27 Apr 2015 08:22:42 -0700 (PDT) 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=ALbDk0TIha4KIu/IGdIfAZv92DXWH8OrrRG/uEhK4V4=; b=vcYfggI2L5iiJ/i4ppPwDTxEYXcgm7QU6RJ/tPkDtYJMLsPzFrowFPFn7opeVNvY+h h0pzrLUVPTfVV6M7lcUo20GP8lzs2xVywYDzVN08GqKMEoZ+GKo7cO6lyalQKkwj2N+p 7trHHUaNBOY49w904BPSqTfjRIAOOCxY7Y/pQhkmxkNqLoikf0sP/1ubCZMD27yriDyx a6ZNUWLttirCXl2QbBC+U0Xj0JvWwg738aomg4zAMnJOXu1xlV7mk+Q4pXOtqQW7pSbw dehyEYJv7+2AMGYTamF/OLkgWivmkCJW/JftPHniv0Mk+A/Bzmh5MzaCpzVh0uf7Tn2p FA0g== MIME-Version: 1.0 X-Received: by 10.50.109.138 with SMTP id hs10mr14128369igb.48.1430148162057; Mon, 27 Apr 2015 08:22:42 -0700 (PDT) Received: by 10.64.1.110 with HTTP; Mon, 27 Apr 2015 08:22:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Apr 2015 08:22:41 -0700 Message-ID: Subject: Re: System clock always unsynced From: Freddie Cash To: Christian Weisgerber Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:22:42 -0000 On Mon, Apr 27, 2015 at 7:39 AM, Christian Weisgerber wrote: > I run OpenNTPD, from ports/net/openntpd, and I've noticed that after > each reboot, the initial system time is further off. (This is quite > noticeable with OpenNTPD, since by default it does *not* jump the > clock on startup like the base ntpd does.) It's as if the RTC was > never synchronized to the system clock. > > Some digging in sys/kern/kern_ntptime.c shows indeed that the RTC is > only synced if STA_UNSYNC is not set, and dumping the value of the > timex struct... > > offset: 0 > freq: 2730304 > maxerror: 84860000 > esterror: 500000 > status: UNSYNC > constant: 0 > precision: 0 > tolerance: 32500000 > state: ERROR > > ... reveals that the clock remains permanently unsynced. Clearly, > OpenNTPD, which uses adjtime(2) to correct offsets and ntp_adjtime(2) > with MOD_FREQUENCY to correct the frequency, doesn't handle this > quite right. > > What *does* an ntpd daemon need to do to sync the clock? > > The ntp_adjtime(2) man page documents struct timex in detail, but > is very vague on what all of this means. > > =E2=80=8BIsn't this why there's a "-s" option for openntpd, which syncs t= he clocks when the daemon starts? And an "openntpd_flags" option in rc.conf =E2=80= =8B =E2=80=8Bfor enabling that option?=E2=80=8B --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 15:28:44 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ADC1DF8 for ; Mon, 27 Apr 2015 15:28:44 +0000 (UTC) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 077001378 for ; Mon, 27 Apr 2015 15:28:43 +0000 (UTC) Received: by obfe9 with SMTP id e9so85929876obf.1 for ; Mon, 27 Apr 2015 08:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WeEV2NGLyLWqzLkNXIZDADd2ZBUmhr/kNSwK7zTJSQk=; b=Q5QJb1WdPlOZ0mfVTA8ut3WtYK2AOdK60wnuonD3a36pkvsUUI9tI5wS1F+nEvWf9n iSKbrz0l3HdE1vymU6w27xpSmbo2oD1XPkowaihXZfINbFcwT/W23+vJuUts6QvHqegy WPSK4J98/INwdz+ioG3fiALGMfOxcGiFGHR+VdOwe5Yky+S/QyLNEvl4JMdDQhVpfpQI dvCgVDXPWl+nj9wuB/hK5Et1SfvsI34pR3C4jXfmXIfQy2oJ1ocPPk5loW825/LeQBEx v9PoHvc5MSnsmGGwH1ZjS3AJUsd1QQoZQLkBivW5l4SJ6orCkDH5qJ7oSUbO/d+SmrBL 6Ngg== X-Gm-Message-State: ALoCoQl2bShpHdr4Dc67FedUXaZO6rEaYrbEUXkhPh18sY5p3udM57SVfgvJvufxW0FYJP8bi6zf X-Received: by 10.202.74.71 with SMTP id x68mr9960179oia.93.1430148517356; Mon, 27 Apr 2015 08:28:37 -0700 (PDT) Received: from ?IPv6:2610:160:11:33:9924:8266:f1b9:4d7f? ([2610:160:11:33:9924:8266:f1b9:4d7f]) by mx.google.com with ESMTPSA id w81sm11432861oia.6.2015.04.27.08.28.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Apr 2015 08:28:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: System clock always unsynced From: Jim Thompson In-Reply-To: Date: Mon, 27 Apr 2015 10:28:35 -0500 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E68BBCF-5E21-4189-9358-F7BA3F5BECDC@netgate.com> References: To: Christian Weisgerber X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 15:28:44 -0000 You can prevent stepping of the clock with the -x option of ntpd. The = issue here is that "can take a long time to converge to an acceptable = offset, about 2,000 s for each second the clock is outside the = acceptable range. During this interval the local clock will not be = consistent with any other network clock and the system cannot be used = for distributed applications that require correctly synchronized network = time.=E2=80=9D http://doc.ntp.org/4.1.0/ntpd.htm Running openntpd is a poor substitute for a real ntpd. Answering, "What *does* an ntpd daemon need to do to sync the clock?=E2=80= =9D likely requires a thesis length posting, and it likely suffices to = state that you=E2=80=99re not the first to discover that openntpd is a = poor implementation of an NTP daemon. Jim > On Apr 27, 2015, at 9:39 AM, Christian Weisgerber = wrote: >=20 > I run OpenNTPD, from ports/net/openntpd, and I've noticed that after > each reboot, the initial system time is further off. (This is quite > noticeable with OpenNTPD, since by default it does *not* jump the > clock on startup like the base ntpd does.) It's as if the RTC was > never synchronized to the system clock. >=20 > Some digging in sys/kern/kern_ntptime.c shows indeed that the RTC is > only synced if STA_UNSYNC is not set, and dumping the value of the > timex struct... >=20 > offset: 0 > freq: 2730304 > maxerror: 84860000 > esterror: 500000 > status: UNSYNC > constant: 0 > precision: 0 > tolerance: 32500000 > state: ERROR >=20 > ... reveals that the clock remains permanently unsynced. Clearly, > OpenNTPD, which uses adjtime(2) to correct offsets and ntp_adjtime(2) > with MOD_FREQUENCY to correct the frequency, doesn't handle this > quite right. >=20 > What *does* an ntpd daemon need to do to sync the clock? >=20 > The ntp_adjtime(2) man page documents struct timex in detail, but > is very vague on what all of this means. >=20 > --=20 > Christian "naddy" Weisgerber = naddy@mips.inka.de > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 16:46:30 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B9E196F; Mon, 27 Apr 2015 16:46:30 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F1A01D42; Mon, 27 Apr 2015 16:46:29 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so88572037wic.1; Mon, 27 Apr 2015 09:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JQ4fiXMK1n5zg2UnADc22eGS0Ivoxz4D/HI3C3x5TPw=; b=RM0g6zMfDGyADBWpIzfe3nL76Aq0xDRH3DPvFYV/BIS8N7r/06CX556NJ4Isfs8fQG o5MtqqWU6t6ZYLh+FJAnmOpT0wSja+biulbwB31VwnSt0Nfso8eOQpSmiYOTqSsBSr0q 7zNw1VEHsFlLIr0O1cHRU+gEKOZOfBk7S2N71GSYVsHVmoF8UnnkJNh253lAqbQka9Yc bnMy1Umw+and6WDFcfugnrEdk9HBxp8RBa0/L8H1TWDVc5XXuHL+Q+/mH6uzJ16dGlhu 55yR1A5bMOIUGphyuTgwTWvYg7kYhjKKpHPd7IiUHprLoF9hMfymne3rBKhNEkFNAgMk 2u2Q== X-Received: by 10.194.75.168 with SMTP id d8mr24494230wjw.87.1430153188046; Mon, 27 Apr 2015 09:46:28 -0700 (PDT) Received: from [192.168.1.130] (ppp-88-217-61-4.dynamic.mnet-online.de. [88.217.61.4]) by mx.google.com with ESMTPSA id em18sm6470287wjd.19.2015.04.27.09.46.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2015 09:46:27 -0700 (PDT) Message-ID: <553E67E2.2050404@gmail.com> Date: Mon, 27 Apr 2015 18:46:26 +0200 From: Tobias Oberstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jim Harris CC: Adrian Chadd , Konstantin Belousov , "freebsd-hackers@freebsd.org" , Michael Fuckner , Alan Somers Subject: Re: NVMe performance 4x slower than expected References: <551BC57D.5070101@gmail.com> <551C5A82.2090306@gmail.com> <20150401212303.GB2379@kib.kiev.ua> <5526EA33.6090004@gmail.com> <5527F554.2030806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:46:30 -0000 Hi Jim, I have now done extensive tests under Linux (SLES12) at the block device level. 8kB Random IO results: http://tavendo.com.s3.amazonaws.com/scratch/fio_p3700_8kB_random.pdf All results: http://tavendo.com.s3.amazonaws.com/scratch/fio_p3700.pdf What becomes apparent is: 1) IOPS is scaling nicely "linear" for (software) RAID-0 It scales up to roughly 2.2 Mio. 8kB random reads, and 750k 8kB random writes. Extrapolating Intel's datasheet would give: 2.36 Mio / 720k Awesome! 2) It does not scale for RAID-1. In fact, the write performance fully collapses for more than 4 devices. Note: I don't know which NVMe is wired to which CPU socket, and which block device - IOW: I did not "handplace" the devices into RAID sets or anything. == I am currently running the same set of tests against 10 DC S3700 via SAS. This should reveal if it's a general mdadm thing, or NVMe related. == For now, we likely will use the NVMes in a RAID-0 setup to leverage the maximum performance. Cheers, /Tobias Am 10.04.2015 um 18:58 schrieb Jim Harris: > On Fri, Apr 10, 2015 at 9:07 AM, Tobias Oberstein < > tobias.oberstein@gmail.com> wrote: > >> Hi Adrian, >> >>> Dell has graciously loaned me a bunch of hardware to continue doing >> >> FWIW, Dell has a roughly comparable system: Dell R920. But they don't have >> Intel NVMe's on their menu, only Samsung (and FusionIO, but that's not >> NVMe). >> >> NUMA development on, but I have no NVMe hardware. I'm hoping people at >>> >> >> The 8 NVMe PCIe SSDs in the box we're deploying are a key feature of this >> system (will be a data-warehouse). A single NVMe probably won't have >> triggered (all) issues we experienced. >> >> We are using the largest model (2TB), and this amounts to 50k bucks for >> all eight. The smallest model (400GB) is 1.5k, so 12k in total. >> >> Intel can continue kicking along any desires for NUMA that they >>> require. (Which they have, fwiw.) >>> >> >> It's already awesome that Intel has senior engineers working on FreeBSD >> driver code! And it would underline Intel's Open-source commitment and tech >> leadership if they donated a couple of these beefy NVMes. >> > > Intel has agreed to send DC P3700 samples to the FreeBSD Foundation to put > in the cluster for this kind of work - we are working on getting these > through the internal sample distribution process at the moment. > > -Jim > From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 17:04:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04B75C8F for ; Mon, 27 Apr 2015 17:04:04 +0000 (UTC) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE111F82 for ; Mon, 27 Apr 2015 17:04:03 +0000 (UTC) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mx.arcor.de (Postfix) with ESMTP id 3lbBR13npxz2lrL for ; Mon, 27 Apr 2015 18:30:05 +0200 (CEST) Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 7E0F57DC99B for ; Mon, 27 Apr 2015 18:30:05 +0200 (CEST) X-Greylist: Passed host: 188.104.143.26 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-06.arcor-online.net 3lbBR11v9vz8FYQ Received: from lorvorc.mips.inka.de (dslb-188-104-143-026.188.104.pools.vodafone-ip.de [188.104.143.26]) by mail-in-06.arcor-online.net (Postfix) with ESMTPS id 3lbBR11v9vz8FYQ for ; Mon, 27 Apr 2015 18:30:05 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3RGU3be040740 for ; Mon, 27 Apr 2015 18:30:03 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3RGU2nE040739 for freebsd-hackers@freebsd.org; Mon, 27 Apr 2015 18:30:02 +0200 (CEST) (envelope-from news) To: freebsd-hackers@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.hackers Subject: Re: System clock always unsynced Date: Mon, 27 Apr 2015 16:30:02 +0000 (UTC) Lines: 12 Message-ID: References: X-Trace: lorvorc.mips.inka.de 1430152202 40559 ::1 (27 Apr 2015 16:30:02 GMT) X-Complaints-To: usenet@mips.inka.de User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 17:04:04 -0000 On 2015-04-27, Christian Weisgerber wrote: > What *does* an ntpd daemon need to do to sync the clock? Okay, let me rephrase this since the first two replies completely missed the point. This is an API programming question. How is the poorly documented ntp_adjtime() API to be used so the system clock will lose the STA_UNSYNC status and switch from TIME_ERROR to TIME_OK as clock state? -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 21:42:53 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 311F1393 for ; Mon, 27 Apr 2015 21:42:53 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6359911D7 for ; Mon, 27 Apr 2015 21:42:51 +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 AAA21039 for ; Tue, 28 Apr 2015 00:49:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ymqsz-000GlN-77 for freebsd-hackers@freebsd.org; Tue, 28 Apr 2015 00:48:17 +0300 Message-ID: <553EAD20.8010701@FreeBSD.org> Date: Tue, 28 Apr 2015 00:41:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-hackers Subject: gconv and kernel Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 21:42:53 -0000 I wonder if anyone used gcov or maybe some other tool for checking FreeBSD _kernel_ code coverage. I could find only some very old posts about kernbb... -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 27 23:24:09 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F8976FE for ; Mon, 27 Apr 2015 23:24:09 +0000 (UTC) Received: from relay.mailchannels.net (aso-006-i440.relay.mailchannels.net [23.91.64.121]) by mx1.freebsd.org (Postfix) with ESMTP id BD48E1E18 for ; Mon, 27 Apr 2015 23:24:08 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id C3E60609F5; Mon, 27 Apr 2015 23:23:59 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (smtp4.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 27 Apr 2015 23:24:00 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1430177039856:492293919 X-MC-Ingress-Time: 1430177039856 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YmsNb-0005ca-EA; Mon, 27 Apr 2015 23:23:59 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t3RNNv7G045407; Mon, 27 Apr 2015 17:23:58 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1+xPWQxT+ycAUeDNwMUYYgm Message-ID: <1430177037.1157.23.camel@freebsd.org> Subject: Re: System clock always unsynced From: Ian Lepore To: Christian Weisgerber Cc: freebsd-hackers@freebsd.org Date: Mon, 27 Apr 2015 17:23:57 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 23:24:09 -0000 On Mon, 2015-04-27 at 16:30 +0000, Christian Weisgerber wrote: > On 2015-04-27, Christian Weisgerber wrote: > > > What *does* an ntpd daemon need to do to sync the clock? > > Okay, let me rephrase this since the first two replies completely > missed the point. This is an API programming question. How is the > poorly documented ntp_adjtime() API to be used so the system clock > will lose the STA_UNSYNC status and switch from TIME_ERROR to TIME_OK > as clock state? > It requires a call to ntp_adjtime() with the MOD_STATUS bit set in ntv.modes and the STA_UNSYNC bit clear in ntv.status. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 11:57:47 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D16553F; Tue, 28 Apr 2015 11:57:47 +0000 (UTC) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43BAC11D9; Tue, 28 Apr 2015 11:57:46 +0000 (UTC) Received: from mail-in-13-z2.arcor-online.net (mail-in-13-z2.arcor-online.net [151.189.8.30]) by mx.arcor.de (Postfix) with ESMTP id 3lbhLG4n37z2m0H; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) Received: from mail-in-17.arcor-online.net (mail-in-17.arcor-online.net [151.189.21.57]) by mail-in-13-z2.arcor-online.net (Postfix) with ESMTP id A13243C9D66; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) X-Greylist: Passed host: 188.105.84.49 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-17.arcor-online.net 3lbhLG361Xz6HDl X-Greylist: Passed host: 188.105.84.49 Received: from lorvorc.mips.inka.de (dslb-188-105-084-049.188.105.pools.vodafone-ip.de [188.105.84.49]) by mail-in-17.arcor-online.net (Postfix) with ESMTPS id 3lbhLG361Xz6HDl; Tue, 28 Apr 2015 13:57:42 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3SBvfsE068535; Tue, 28 Apr 2015 13:57:41 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3SBvfQ2068534; Tue, 28 Apr 2015 13:57:41 +0200 (CEST) (envelope-from naddy) Date: Tue, 28 Apr 2015 13:57:41 +0200 From: Christian Weisgerber To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: System clock always unsynced Message-ID: <20150428115741.GA68174@lorvorc.mips.inka.de> References: <1430177037.1157.23.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430177037.1157.23.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 11:57:47 -0000 Ian Lepore: > > Okay, let me rephrase this since the first two replies completely > > missed the point. This is an API programming question. How is the > > poorly documented ntp_adjtime() API to be used so the system clock > > will lose the STA_UNSYNC status and switch from TIME_ERROR to TIME_OK > > as clock state? > > It requires a call to ntp_adjtime() with the MOD_STATUS bit set in > ntv.modes and the STA_UNSYNC bit clear in ntv.status. Well, yes. You omitted the crucial piece of information, but I think I have figured it out from reading kern_ntptime.c: The STA_UNSYNC value is _read_ by the kernel and (mostly) _set_ by userland. It is ntpd that is supposed to clear STA_UNSYNC to signal the kernel that the time is synchronized. The ntp_adjtime(2) man page doesn't say anything how STA_UNSYNC is used and I had naturally assumed that it was the kernel that cleared STA_UNSYNC to let ntpd know (that the offsets had been applied or whatever). -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 14:39:43 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3DD09D7E; Tue, 28 Apr 2015 14:39:43 +0000 (UTC) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 009BF163F; Tue, 28 Apr 2015 14:39:43 +0000 (UTC) Received: by oica37 with SMTP id a37so117785845oic.0; Tue, 28 Apr 2015 07:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pwvESAe+E1Jn31lNI21Uaae0r56So2NgFMf+PAC0/MQ=; b=V82XexYKm65vCi1O+LNeYYJmuG3m3fkNyRn3cGnPj9+qyrtaZpcWHDhjq4nCnqok/1 mJO32cJldNstIII+3jpo6cjAOOdWkjpzVFYB9r0Qgmvlr+2oqNc+hMARF4Mpk4dPp6+2 NC4EJXwTIcsAR8KhhBNG1Gkhm8GK+CFI1h9xisKFVlDGvjhsCdL/6zaPHmNMZnbb8azT I2jqFNLZUlTUDYoz7lPIhGYfAc8EaXEPVz0mVsEmPCgxvJxklG8p1ySonAGiXVWZOYYW Pw0+54/r5tNg0RkxJOXh7W7A218r9rRi2WjxWbfueTolQB24h1CbuofS7RYKenA4YrT3 CfxQ== MIME-Version: 1.0 X-Received: by 10.182.99.167 with SMTP id er7mr1562068obb.81.1430231982297; Tue, 28 Apr 2015 07:39:42 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.173.204 with HTTP; Tue, 28 Apr 2015 07:39:42 -0700 (PDT) In-Reply-To: <553EAD20.8010701@FreeBSD.org> References: <553EAD20.8010701@FreeBSD.org> Date: Tue, 28 Apr 2015 08:39:42 -0600 X-Google-Sender-Auth: aLcZ7AxshlWM1lTrYHMe3nUNaUI Message-ID: Subject: Re: gconv and kernel From: Alan Somers To: Andriy Gapon Cc: freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:39:43 -0000 On Mon, Apr 27, 2015 at 3:41 PM, Andriy Gapon wrote: > > I wonder if anyone used gcov or maybe some other tool for checking FreeBSD > _kernel_ code coverage. > I could find only some very old posts about kernbb... I was unable to find a way to use gcov. But a few years ago I did get a proprietary product called Bullseye to work. The results browser is a little cumbersome, but the results seemed accurate. http://www.bullseye.com/ -Alan > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 15:47:56 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89DBEA67 for ; Tue, 28 Apr 2015 15:47:56 +0000 (UTC) Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D33A1F16 for ; Tue, 28 Apr 2015 15:47:55 +0000 (UTC) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id 3lbmlH2jJczQPf5 for ; Tue, 28 Apr 2015 17:16:11 +0200 (CEST) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id 54A0E11B640 for ; Tue, 28 Apr 2015 17:16:11 +0200 (CEST) X-Greylist: Passed host: 188.105.84.49 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-12.arcor-online.net 3lbmlH1bhtz19N3 Received: from lorvorc.mips.inka.de (dslb-188-105-084-049.188.105.pools.vodafone-ip.de [188.105.84.49]) by mail-in-12.arcor-online.net (Postfix) with ESMTPS id 3lbmlH1bhtz19N3 for ; Tue, 28 Apr 2015 17:16:11 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3SFGAVu073247 for ; Tue, 28 Apr 2015 17:16:10 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3SFGAAn073246 for freebsd-hackers@freebsd.org; Tue, 28 Apr 2015 17:16:10 +0200 (CEST) (envelope-from news) To: freebsd-hackers@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.hackers Subject: Re: System clock always unsynced Date: Tue, 28 Apr 2015 15:16:10 +0000 (UTC) Lines: 14 Message-ID: References: <0E68BBCF-5E21-4189-9358-F7BA3F5BECDC@netgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: lorvorc.mips.inka.de 1430234170 72477 ::1 (28 Apr 2015 15:16:10 GMT) X-Complaints-To: usenet@mips.inka.de User-Agent: slrn/1.0.2 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 15:47:56 -0000 On 2015-04-27, Jim Thompson wrote: > Running openntpd is a poor substitute for a real ntpd. FUD. > Answering, "What *does* an ntpd daemon need to do to sync the > clock?” likely requires a thesis length posting, As it turns out, the answer to my question is a one-liner: "STA_UNSYNC is driven by ntpd, not the kernel. Just clear the bit." -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 17:23:46 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F395990C; Tue, 28 Apr 2015 17:23:45 +0000 (UTC) Received: from mail-in-07.arcor-online.net (mail-in-07.arcor-online.net [151.189.21.47]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx.arcor.de", Issuer "Thawte SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A98D01C2D; Tue, 28 Apr 2015 17:23:45 +0000 (UTC) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id 3lbptG4w4Jz87RT; Tue, 28 Apr 2015 18:52:22 +0200 (CEST) Received: from mail-in-14.arcor-online.net (mail-in-14.arcor-online.net [151.189.21.54]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id A55AC28B240; Tue, 28 Apr 2015 18:52:22 +0200 (CEST) X-Greylist: Passed host: 188.105.84.49 X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-14.arcor-online.net 3lbptG3cWyz4nSp X-Greylist: Passed host: 188.105.84.49 Received: from lorvorc.mips.inka.de (dslb-188-105-084-049.188.105.pools.vodafone-ip.de [188.105.84.49]) by mail-in-14.arcor-online.net (Postfix) with ESMTPS id 3lbptG3cWyz4nSp; Tue, 28 Apr 2015 18:52:22 +0200 (CEST) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.9/8.14.9) with ESMTP id t3SGqMW8075217; Tue, 28 Apr 2015 18:52:22 +0200 (CEST) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.14.9/8.14.9/Submit) id t3SGqLRH075216; Tue, 28 Apr 2015 18:52:22 +0200 (CEST) (envelope-from naddy) Date: Tue, 28 Apr 2015 18:52:21 +0200 From: Christian Weisgerber To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: System clock always unsynced Message-ID: <20150428165221.GA75198@lorvorc.mips.inka.de> References: <1430177037.1157.23.camel@freebsd.org> <20150428115741.GA68174@lorvorc.mips.inka.de> <1430235252.1157.37.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430235252.1157.37.camel@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:23:46 -0000 Ian Lepore: > The missing documentation you're looking for is probably RFC 1589. The > ntp_adjtime manpage probably should mention it. That looks useful, yes... Although it appears do describe an older version of the API: timex.status is described as having TIME_* clock state values and there is no trace of ORed STA_* flags. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 17:41:48 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B5E1FFD for ; Tue, 28 Apr 2015 17:41:48 +0000 (UTC) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBFC91E71 for ; Tue, 28 Apr 2015 17:41:47 +0000 (UTC) Received: by obfe9 with SMTP id e9so1814970obf.1 for ; Tue, 28 Apr 2015 10:41:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ltPojzhmqoMVf2t4XDZgHNBGKSY6RkDyr4Rra/q/G6E=; b=Jx3P+7o76b+14fsX5q2kwve6blYVVIfEbJ9WnghLuaOxB8cBEl/5f8+uR4xaESzCzL q18Q7xcXN+GyQhBpEW5DHoNDfDuus2dMGtU4Se3BJ4gtw+oyVEIHUmZi5/eXJqh7O2Q0 4qNtUllcjzxYZVSu9btzrsq2vsrhpVlgMWbTKUiiTosVvrtpWy2JxrubFBKq32j0/7MC g8UBclUjJph0Xv/YUd67SloGcnGIoXi+2V1E5VbvjLNgNtrTLgA19aUsYIv1fWJ66Rvu yaF2nnnfhimmt9Hyx9yaQdCqju5EiT+sBO3Jqb8q0eVqU8HRejHtRaDoG5omO3oVgjP2 9Erg== X-Gm-Message-State: ALoCoQm2GYEfWUciMTF73CYKZgKbAqtdlvZjOqXjat7rhXXHTdqvJChDxCxIPfusjvDAu5WE7wPx X-Received: by 10.182.243.228 with SMTP id xb4mr15538205obc.86.1430242899886; Tue, 28 Apr 2015 10:41:39 -0700 (PDT) Received: from jims-mbp.pfmechanics.com ([208.123.73.28]) by mx.google.com with ESMTPSA id qk9sm5822350obb.10.2015.04.28.10.41.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 10:41:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: System clock always unsynced From: Jim Thompson In-Reply-To: Date: Tue, 28 Apr 2015 12:41:37 -0500 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5ABA960D-BB67-4BE8-8C55-E1B3925584FB@netgate.com> References: <0E68BBCF-5E21-4189-9358-F7BA3F5BECDC@netgate.com> To: Christian Weisgerber X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:41:48 -0000 > On Apr 28, 2015, at 10:16 AM, Christian Weisgerber = wrote: >=20 > On 2015-04-27, Jim Thompson wrote: >=20 >> Running openntpd is a poor substitute for a real ntpd. >=20 > FUD. The issues encountered when running either are well-understood, = actually. So: not FUD >> Answering, "What *does* an ntpd daemon need to do to sync the >> clock?=E2=80=9D likely requires a thesis length posting, >=20 > As it turns out, the answer to my question is a one-liner: > "STA_UNSYNC is driven by ntpd, not the kernel. Just clear the bit." It goes far beyond this, but feel free to engage as you see best. My unsolicited advice: look at phk=E2=80=99s ntimed. Jim From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 17:56:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E27F1BE1 for ; Tue, 28 Apr 2015 17:56:04 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id D0B7F100E for ; Tue, 28 Apr 2015 17:56:03 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id 2A2C81D132B; Tue, 28 Apr 2015 15:34:18 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Tue, 28 Apr 2015 15:34:18 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1430235258232:3816386999 X-MC-Ingress-Time: 1430235258232 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Yn7WZ-0001Ji-B4; Tue, 28 Apr 2015 15:34:15 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t3SFYC7p047062; Tue, 28 Apr 2015 09:34:12 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/ckI7zVFHfy6qLo4qJLq+P Message-ID: <1430235252.1157.37.camel@freebsd.org> Subject: Re: System clock always unsynced From: Ian Lepore To: Christian Weisgerber Cc: freebsd-hackers@freebsd.org Date: Tue, 28 Apr 2015 09:34:12 -0600 In-Reply-To: <20150428115741.GA68174@lorvorc.mips.inka.de> References: <1430177037.1157.23.camel@freebsd.org> <20150428115741.GA68174@lorvorc.mips.inka.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 17:56:05 -0000 On Tue, 2015-04-28 at 13:57 +0200, Christian Weisgerber wrote: > Ian Lepore: > > > > Okay, let me rephrase this since the first two replies completely > > > missed the point. This is an API programming question. How is the > > > poorly documented ntp_adjtime() API to be used so the system clock > > > will lose the STA_UNSYNC status and switch from TIME_ERROR to TIME_OK > > > as clock state? > > > > It requires a call to ntp_adjtime() with the MOD_STATUS bit set in > > ntv.modes and the STA_UNSYNC bit clear in ntv.status. > > Well, yes. You omitted the crucial piece of information, but I > think I have figured it out from reading kern_ntptime.c: The > STA_UNSYNC value is _read_ by the kernel and (mostly) _set_ by > userland. It is ntpd that is supposed to clear STA_UNSYNC to signal > the kernel that the time is synchronized. > > The ntp_adjtime(2) man page doesn't say anything how STA_UNSYNC is > used and I had naturally assumed that it was the kernel that cleared > STA_UNSYNC to let ntpd know (that the offsets had been applied or > whatever). > I'm not sure why you "naturally" assumed it was the kernel's responsibility to clear that bit when all the kernel is doing is following ntpd's instructions on how to steer the clock. It's ntpd (or some other external entity) that knows the relationship between current system time and some other authorative source of time. The missing documentation you're looking for is probably RFC 1589. The ntp_adjtime manpage probably should mention it. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 21:55:01 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A2F7D26 for ; Tue, 28 Apr 2015 21:55:01 +0000 (UTC) Received: from mail-vn0-f51.google.com (mail-vn0-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D25B1C27 for ; Tue, 28 Apr 2015 21:55:00 +0000 (UTC) Received: by vnbf1 with SMTP id f1so1259591vnb.0 for ; Tue, 28 Apr 2015 14:54:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=Xm2ag863HfzsGK2ePAT1Spyfr8Ju9JeSr+R3HROrTBM=; b=lPHMAcvOHI7o6iY1aKVfPy9uGVxGvsqIxmvp/dOlxsJhxKTmibVRkrxneLGZmEbPaa Iqw02Ys7U+ZuqtimaBkXQ/s6wSRQ0GqfXj1S6B44aaogdI++0Js3nd65IPCILCPDpwVV rkri5PTBTVoGEumALWZFAte1VpR/UWV/fNpIroXngzPYO3OXyVPjiGmD6ToIuK4LYDgi GI5T8Z2c2sS06h2QXmj78HRfPF66bwY/s/UxyBHLjG20CI6NQRk9Cvxqhi+Wug8P5M9R +mbfKZ9e4CxZvYLatpUfCCY1FGwly/o2UEoJi2dUkQdahU1JivwtJn33frQC1F5jjmsk hkug== X-Gm-Message-State: ALoCoQk7iQ5toquGeiUtX+9Nt7lmL9YfipTmIUpC9bCS4oWrN4brsPknQIxnFGCaBlszCpIPhV5y X-Received: by 10.52.228.130 with SMTP id si2mr21532405vdc.13.1430258099368; Tue, 28 Apr 2015 14:54:59 -0700 (PDT) Received: from ?IPv6:2600:1001:b104:5446:54db:3930:2fb7:a2d0? ([2600:1001:b104:5446:54db:3930:2fb7:a2d0]) by mx.google.com with ESMTPSA id at6sm33342258vdc.7.2015.04.28.14.54.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 14:54:58 -0700 (PDT) From: Mark Saad Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Ringmap status Message-Id: Date: Tue, 28 Apr 2015 17:54:57 -0400 To: hackers@freebsd.org X-Mailer: iPhone Mail (12D508) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:55:01 -0000 All=20 I was wondering what the current state of ringmap was in 10 and head . I o= nly see the original work on 8-Stable on Google code . Is this still being w= orked on ? --- Mark Saad | nonesuch@longcount.org= From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 22:27:39 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D9194F9 for ; Tue, 28 Apr 2015 22:27:39 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7D171F34 for ; Tue, 28 Apr 2015 22:27:38 +0000 (UTC) Received: by lbbqq2 with SMTP id qq2so7139227lbb.3 for ; Tue, 28 Apr 2015 15:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6QWCSJZVsnm5LFwUObrIrL60qy8y5BcR2Ok1u3ZO44U=; b=k46eQRAb8+7qwBHpCJeVFk9kzdMqrplBGoCYZC/Ka1y5aq/WT/1HCASsH7AwM5L7sG tgyLzNm4n5ks+m55nlHv8nWBSTX//UuaGqTmNPZ7Q2fgh9APRGqWYW9bffS4lhJelkwv L+KrUfNZDp103hU/yqNkD+ilO2Gk3jJqrBEZUEf+Z+2fDgKCDxA8lpVuNh9MmtDBKBvN vzQH8V2gbOqPNE+JOfH/ZZahXwCGAmtZbWg7t8lKHwFsOt9PIbAdh9XZ+b75acZUX0kV mJRi0ObzFp8r64LPNkGWxMlMWueIXbSNVfc8QBrLRz/RY55kG7WKybpeaOPOImFO5FN9 dT4A== MIME-Version: 1.0 X-Received: by 10.112.16.196 with SMTP id i4mr5552502lbd.72.1430260056534; Tue, 28 Apr 2015 15:27:36 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.20.232 with HTTP; Tue, 28 Apr 2015 15:27:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Apr 2015 00:27:36 +0200 X-Google-Sender-Auth: EtKXyLdvPmP4aOHXzNL0a25S9_I Message-ID: Subject: Re: Ringmap status From: Luigi Rizzo To: Mark Saad Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 22:27:39 -0000 On Tue, Apr 28, 2015 at 11:54 PM, Mark Saad wrote: > All > I was wondering what the current state of ringmap was in 10 and head . I > only see the original work on 8-Stable on Google code . Is this still being > worked on ? > > don't think so. But for those applications you can now use netmap. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 28 23:38:48 2015 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5965E666 for ; Tue, 28 Apr 2015 23:38:48 +0000 (UTC) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1846616BE for ; Tue, 28 Apr 2015 23:38:47 +0000 (UTC) Received: by qgeb100 with SMTP id b100so4866343qge.3 for ; Tue, 28 Apr 2015 16:38:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OaYkFc2X0qc8lPdyai9vUQGTB6lH2pwAx5YjD4oqkKk=; b=EotJf9hm5vrENDmH0dE8O48IDlfEH5k6k5VVE+2ey/61jvy6Hqt0/DkKAlDMTLJQd3 mN5XZpV+29ddMnDdyUzulwSW2H1IiUT0A2J/yoL0a1E35qvJNCwpp1FL7whCCTBPgINx TEGNa9kIzrBjgLNeDybqkAgOK/dDjse8hgqUYEX1XZ7RsAVwa58n+F/beDvMEzeeydVJ +nk2t/khUg0HkhKO59GlNKsJZL1JY8La5SQa2UH1uWfB+5b+FM3ffd67FCj9rSRL8slL NJpGDi4dZD0/aOYzMGD20kwVJgugs33b18t1Y/LKdhhlV/mI7lHxXxJPHQAWbGOZFxyL cAsQ== X-Gm-Message-State: ALoCoQmfv7ezmGfG6xL7SHBShkaTieTfe29RT426U5PxSGA2XJPIr6gmA5h1SqIZVqnyO0k515at X-Received: by 10.140.147.213 with SMTP id 204mr15217887qht.58.1430264320909; Tue, 28 Apr 2015 16:38:40 -0700 (PDT) Received: from [192.168.2.53] (ool-182c6ffa.dyn.optonline.net. [24.44.111.250]) by mx.google.com with ESMTPSA id 28sm13682443qkw.13.2015.04.28.16.38.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Apr 2015 16:38:40 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: Ringmap status From: Mark Saad X-Mailer: iPhone Mail (12D508) In-Reply-To: Date: Tue, 28 Apr 2015 19:38:38 -0400 Cc: "freebsd-hackers@freebsd.org" Message-Id: References: To: Luigi Rizzo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 23:38:48 -0000 Luigi Thanks I had the names munged in my head . I'll read up and see if this w= orks for me . Off hand are there any issues with what nics work or is this g= eneric enough with sensible choices ? =20 --- Mark Saad | nonesuch@longcount.org > On Apr 28, 2015, at 6:27 PM, Luigi Rizzo wrote: >=20 >=20 >=20 >> On Tue, Apr 28, 2015 at 11:54 PM, Mark Saad wrot= e: >> All >> I was wondering what the current state of ringmap was in 10 and head . I= only see the original work on 8-Stable on Google code . Is this still being= worked on ? >=20 > don't think so. > But for those applications you can now use netmap.=20 >=20 > cheers > luigi >=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 07:39:45 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD491B63; Thu, 30 Apr 2015 07:39:45 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93D361CEF; Thu, 30 Apr 2015 07:39:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Ynj4L-0001HK-Dr; Thu, 30 Apr 2015 10:39:37 +0300 Date: Thu, 30 Apr 2015 10:39:37 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "freebsd-hackers@freebsd.org" Subject: Re: irq cpu binding Message-ID: <20150430073937.GY1394@zxy.spb.ru> References: <20150328183147.GC23643@zxy.spb.ru> <20150328192505.GD23643@zxy.spb.ru> <20150331225947.GC23643@zxy.spb.ru> <20150401062259.GD23643@zxy.spb.ru> <20150404202504.GG74532@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 07:39:46 -0000 On Sat, Apr 04, 2015 at 04:27:20PM -0700, Adrian Chadd wrote: > On 4 April 2015 at 13:25, Slawa Olhovchenkov wrote: > > On Tue, Mar 31, 2015 at 11:57:27PM -0700, Adrian Chadd wrote: > > > >> I'll go take a look over the weekend at the non-RSS case. It shouldn't > >> be scheduling on the wrong CPU(s) if you've pinned things. > > > > Did you find the time for look? > > Not yet; I've been validating things and adding prefetching/batching > to my testing setup, which uses ixgbe + netmap. > > I'll get to it soon. Did you have any news? From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 30 11:37:14 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CBABC76 for ; Thu, 30 Apr 2015 11:37:14 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 62CC81827 for ; Thu, 30 Apr 2015 11:37:12 +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 OAA02255 for ; Thu, 30 Apr 2015 14:37:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ynmm7-000JK1-OM for freebsd-hackers@freebsd.org; Thu, 30 Apr 2015 14:37:03 +0300 Message-ID: <554213A6.1090503@FreeBSD.org> Date: Thu, 30 Apr 2015 14:36:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-hackers Subject: Re: gconv and kernel References: <553EAD20.8010701@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 11:37:14 -0000 On 28/04/2015 17:39, Alan Somers wrote: > On Mon, Apr 27, 2015 at 3:41 PM, Andriy Gapon wrote: >> >> I wonder if anyone used gcov or maybe some other tool for checking FreeBSD >> _kernel_ code coverage. >> I could find only some very old posts about kernbb... > > > I was unable to find a way to use gcov. But a few years ago I did get > a proprietary product called Bullseye to work. The results browser is > a little cumbersome, but the results seemed accurate. > > http://www.bullseye.com/ Thanks to all who replied on-list (Alan) and off-list. Looks like this would require more effort than I can do now. gconv seems to work with Linux kernel almost out of the box, so perhaps I'll check my code (OpenZFS stuff) there. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri May 1 03:37:09 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F695C0A; Fri, 1 May 2015 03:37:09 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFACE1564; Fri, 1 May 2015 03:37:07 +0000 (UTC) X-AuditID: 1209190d-f79676d000000da0-d0-5542f3adbe5c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id FF.7F.03488.EA3F2455; Thu, 30 Apr 2015 23:31:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t413Vv1L019351; Thu, 30 Apr 2015 23:31:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t413VtG4025909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Apr 2015 23:31:56 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t413Vsv5011381; Thu, 30 Apr 2015 23:31:54 -0400 (EDT) Date: Thu, 30 Apr 2015 23:31:54 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: FreeBSD Quarterly Status Report - First Quarter 2015 Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1l332SnU4PpqFotd106zW8x584HJ Yvvmf4wOzB4zPs1nCWCM4rJJSc3JLEst0rdL4MrY0beUpeDPcZaKSU8bWRoYf5xg7mLk5JAQ MJGYMnEqlC0mceHeerYuRi4OIYHFTBLnt/5mhnA2MkpcvneGEcI5xCSx4vQLRpAWIYEGRomW PtkuRg4OFgFtib6zGiBhNgE1icd7m1khpipKbD41iRmkRERAXmLBeXuQMDOQ+f/KZSYQW1jA VmL7v1/sIDavgKPEks9rwGxRAR2J1funsEDEBSVOznzCAjKGWSBAYv4E0wmMArOQZGYhZGaB LdAB+mwFI4StLXH/ZhvbAkaWVYyyKblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGMHh K8m7g/HdQaVDjAIcjEo8vBuOOYUKsSaWFVfmHmKU5GBSEuWd8wAoxJeUn1KZkVicEV9UmpNa fIhRgoNZSYRX5jJQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgjfq E1CjYFFqempFWmZOCUKaiYMTZDgP0PDFIDW8xQWJucWZ6RD5U4yWHA3/fi5i4thx8zeQ7LsP JIVY8vLzUqXEeeeANAiANGSU5sHNhKWjV4ziQC8K814HqeIBpjK4qa+AFjIBLTx/ywFkYUki QkqqgVH9/0+fzymxuZqT9r//MOFg5zNxdn9T7mc/26dvWmCiff9b8/s1PM/Uc+LP9aznfz1D 28qpfX3ooZj7FepXJ7wPv9r7ZMXRhAU3qy7/krLZtvRqmAmr+UUvPbOZbK4q9vFSF1eebmB6 96igr4yj11x28+9Xpww/OUaeZ9u/zkDh5e5Nt17vkTNQYinOSDTUYi4qTgQAYEVVrCIDAAA= Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 03:37:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 FreeBSD Project Quarterly Status Report: January - March 2015 This report covers FreeBSD-related projects between January and March 2015. This is the first of four reports planned for 2015. The first quarter of 2015 was another productive quarter for the FreeBSD project and community. FreeBSD is being used in research projects, and those projects are making their way back into FreeBSD as new and exciting features, bringing improved network performance and security features to the system. Work continues to improve support for more architectures and architecture features, including progress towards the goal of making ARM (32- and 64-bit) a Tier 1 platform in FreeBSD 11. The toolchain is receiving updates, with new versions of clang/LLVM in place, migrations to ELF Tool Chain tools, and updates to the LLDB and gdb debuggers. Work by ports teams and kernel developers is maintaining and improving the state of FreeBSD as a desktop operating system. The pkg team is continuing to make binary packages easier to use and upgrade. Thanks to all the reporters for the excellent work! The deadline for submissions covering the period from April to June 2015 is July 7th, 2015. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Bugmeister * Ports Collection * The FreeBSD Core Team Projects * bhyve * CheriBSD * Clang, llvm and lldb updated to 3.6.0 * FreeBSD on POWER8 * Jenkins Continuous Integration for FreeBSD * Lua boot loader * Mellanox iSCSI Extensions for RDMA (iSER) Support * Multipath TCP for FreeBSD * New Automounter * Opaque ifnet * pkg * Secure Boot Kernel * Adding PCIe Hot-plug Support * Address Space Layout Randomization (ASLR) * Modern x86 platform support and VT-d * Nanosecond file timestamps Architectures * FreeBSD on newer ARM boards * FreeBSD/arm64 * Nested Kernel Userland Programs * libthr improvements * Migration to ELF Tool Chain tools * The LLDB Debugger * Updates to GDB Ports * FreeBSD Ada Ports * FreeBSD Python Ports * GNOME on FreeBSD * KDE on FreeBSD * The Graphics stack on FreeBSD * Wine/FreeBSD * Xfce on FreeBSD Documentation * More Michael Lucas FreeBSD books Miscellaneous * The FreeBSD Foundation __________________________________________________________________ FreeBSD Bugmeister Contact: FreeBSD Bugmeister Bugzilla replaced GNATS in June 2014 as the bug management tool of choice for FreeBSD, granting GNATS its well-deserved retirement after more than 20 years of operation. The following months were rough for Bugzilla: a lot of functionality was still missing and several uncertainties caused users and committers to adapt only slowly to the new system. Over the last six months, a lot of missing features were brought into place to allow users and committers to focus on getting bugs solved. Categories, the status model and many workflow-related knobs were continuously reworked and improved to provide the necessary information without getting in the way. An auto-assigner for ports issues was implemented, resembling what GNATS successfully did in the past. A dashboard page within Bugzilla provides users and committers with quick access to common queries and overall statistics; many other smaller tweaks, configurations, and extensions were implemented to improve the usability of the system. An improved reporting system is currently being implemented to provide graphs and statistics for users and committers. Handling MFCs and a better feedback mechanism for requests (flags in Bugzilla) will be the next things to do. Bugmeister is also working closely with the FreeBSD GitHub team to establish a workflow between GitHub's issue tracker and our Bugzilla system. The technical solution already exists as a proof of concept, but its usage in production will have to wait until Bugzilla 5.0 has been adopted. Open tasks: 1. Create a solid charting extension for FreeBSD Bugzilla. 2. Improve MFC handling. 3. Do you feel that something important is missing? Let us know! __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/po= rts-contributing.html URL: http://portsmon.freebsd.org/index.html URL: http://portscout.freebsd.org/ URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: Port Management Team As of the end of Q1 the ports tree holds almost 25,000 ports, and the PR count is just over 1,500. The tree saw more activity than during the previous quarter, with almost 7,000 commits performed by 163 active committers. The number of problem reports closed also increased by about 20%, with nearly 2,000 PRs closed! In Q1 two new developers were granted a ports commit bit (jbeich@ and brd@) and one bit was taken in for safekeeping (rafan@, on his request). On the management side, decke@ decided to step down from his portmgr duties in February. No other changes were made to the team during Q1. This quarter also saw the release of the first quarterly branch of the year, 2015Q1. On this branch, 140 changes were applied by 35 committers. On the QA side, 29 exp-runs were performed to validate sensitive updates or cleanups. Open tasks: 1. As during the previous quarter a tremendous amount of work was done on the tree to update major ports and to close even more PRs than in 2014Q4. However, we sometimes lag behind with regards to documentation, so volunteers are welcome to help on this important task. __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. January began with members of core dealing with the fallout from the accidental deletion of the Bugzilla database. This incident highlighted the fact that backup and recovery mechanisms in the cluster were not up to the task. Core has discussed what measures are appropriate with clusteradm and is reviewing their implementation. After a long process of consultation, plans for introducing the new support model with 11.0-RELEASE were finally agreed on and published in early February. This announcement puts the practical detail onto the motion that was adopted at BSDCan 2014, and clarifies the steps needed for implementation. Also in February core revisited discussions on making the blogs.freebsdish.org blog aggregator an official project service and also providing a blogging platform directly to developers. However, security and man-power are both major concerns. Given the track records of most freely available blogging platforms, core is rightly wary of introducing them into the cluster. Similarly, curating a blogging platform will take a substantial volunteer effort to ensure all posts are appropriate and to remove spam. March has seen two discussions about potentially divisive topics. Should the ZFS ARC Responsiveness patches be committed and MFC'd as a pragmatic fix to performance problems in 10.1-RELEASE, understanding that this is not an ideal solution to the problem and will need rework? Should we stop maintaining support for older (C89 or earlier) compilers in kernel code, and just code directly to the C11 standard? Broadening out from this last point: should we have a formal mechanism for deciding what has become obsolete in the system and when it should be removed? During this quarter five new src commit bits were granted and two were taken in for safe-keeping. __________________________________________________________________ bhyve URL: http://www.bhyve.org Contact: Peter Grehan Contact: Neel Natu Contact: John Baldwin Contact: Tycho Nightingale Contact: Allan Jude Contact: Alexander Motin bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors. Peter Grehan did a status update at bhyvecon 2015 in Tokyo. The slides are available at http://bhyvecon.org/bhyvecon2015-Peter.pdf. Mihai Carabas presented the results of his GSoC project on implementing instruction caching in bhyve at AsiaBSDCon 2015 in Tokyo. The slides are available at http://people.freebsd.org/~neel/bhyve/bhyve-cache-emul-slides.pdf. A number of improvements were made to bhyve this quarter: * The RTC device model can now be instructed to keep UTC time instead of localtime. This is useful for guests like OpenBSD that expect the RTC to keep UTC time. * The virtio-blk device now does I/O asynchronously without blocking the vcpu thread that initiated the I/O. * The virtio-blk and ahci-hd devices are now able to execute multiple I/O requests in parallel. This can significantly boost virtual disk throughput. * The ahci-hd device emulation advertises TRIM to the guest if the backend device supports it (e.g., ZVOL). * The virtio-blk and ahci-hd devices now advertise the proper logical and physical block size of the backend device or file. Open tasks: 1. Improve documentation. 2. bhyveucl is a tool for starting bhyve instances based on a UCL formatted config file. More information is at https://github.com/allanjude/bhyveucl 3. Add support for virtio-scsi. 4. Flexible networking backends such as wanproxy and vhost-net. 5. Move to a single process model, instead of bhyveload and bhyve. 6. Support running bhyve as non-root. 7. Add filters for popular VM file formats (VMDK, VHD, QCOW2). 8. Implement an abstraction layer for video (no X11 or SDL in the base system). 9. Suspend/resume support. 10. Live Migration. 11. Nested VT-x support (bhyve in bhyve). 12. Support for other architectures (ARM, MIPS, PPC). __________________________________________________________________ CheriBSD URL: http://cheri-cpu.org/ Contact: Robert Watson Contact: Brooks Davis Contact: David Chisnall Contact: Ruslan Bukin CheriBSD is a fork of FreeBSD to support the CHERI research CPU. We have extended the kernel to provide support for CHERI memory capabilities as well as modifying applications and libraries including tcpdump, libmagic, and libz to take advantage of these capabilities for improved memory safety and compartmentalization. We have also developed custom demo applications and deployment infrastructure for our table demo platform. As this goes to press, we are finalizing our first open source release of the CHERI CPU which will be available from the CHERI CPU website. We have been merging support for the BERI CPU platform to FreeBSD since 2012 and continue to do so as new features are developed. Most recently, Ruslan has added support for the Terasis SoCkit board which combines an ARM processor with an FPGA capable of running BERI (and soon CHERI) in a single package. This project is sponsored by DARPA/AFRL. __________________________________________________________________ Clang, llvm and lldb updated to 3.6.0 URL: http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html URL: http://llvm.org/releases/3.6.0/tools/clang/docs/ReleaseNotes.html Contact: Dimitry Andric Contact: Ed Maste Contact: Roman Divacky Contact: Davide Italiano Just before the end of the quarter, we updated clang, llvm and lldb in the base system to the 3.6.0 release. These all contain numerous improvements; please see the linked release notes for more detailed information. We have also imported a newer snapshot of compiler-rt, with better support for the Address Sanitizer and the Undefined Behavior Sanitizer, and arm64 runtime support routines. With the updated clang, llvm, and compiler-rt, we now support the Address and Undefined Behavior Sanitizers in the base system toolchain. As with the 3.5.0 release, these components require C++11 support to build. C++11 support is available in FreeBSD 10.0 and later on the x86 architectures. It is still unclear whether we will be able to MFC these updates to any of the stable branches, due to the difficulty it will introduce for upgrading from a system without C++11 support, either from older releases or from architectures still using gcc. In the lld-import branch, we have also imported a recent snapshot of lld, a linker produced by the LLVM project. This is a very preliminary effort of making it available as a system linker. Thanks to Ed Maste, Roman Divacky, Andrew Turner and Davide Italiano for their help with this import, and thanks to Antoine Brodin for performing a ports exp-run. Open tasks: 1. After the ports exp-run, a small number of ports turned out to have problems, and for almost all of these, PRs with fixes or workarounds were filed. While most of these PRs have been processed and closed, there are still a few left that need attention, from either the maintainer(s) or other volunteers. 2. Andrew Turner is working on bringing up the arm64 architecture, which is now fully supported in clang and llvm. This will be a very interesting new area for solving challenging problems. 3. There are still issues with the powerpc and sparc64 architectures, and any help in these areas is very much appreciated. __________________________________________________________________ FreeBSD on POWER8 URL: http://www.tyan.com/campaign/openpower/ Contact: Nathan Whitehorn Contact: Justin Hibbits Contact: Adrian Chadd IBM and the OpenPOWER Foundation are pushing for a wider software and hardware ecosystem for POWER8-based systems. Starting in January 2014, we have been doing bringup work on a Tyan GN70-BP010 POWER8 server, a quad-core 3 GHz system with a total of 32 hardware threads. Updates since the previous report: * FreeBSD now boots under a hypervisor with the virtual SCSI block device; the issue previously preventing this has been fixed. * The powerpc64 pmap code was rewritten to be more scalable, as the previous pmap code did not scale beyond a small number of CPUs. * Initial support for IBM's Vector-Scalar Extensions (VSX) was added. * The FreeBSD kernel was made completely position independent for powerpc64, and later powerpc32 as well. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Get FreeBSD booting natively, rather than under KVM. This requires writing OPAL drivers for the various hardware devices in the system. 2. Integrate loader(8) with petitboot. __________________________________________________________________ Jenkins Continuous Integration for FreeBSD URL: https://jenkins.freebsd.org URL: http://www.cloud9ers.com/ URL: https://wiki.ubuntu.com/AhmedKamal URL: https://github.com/saltstack/salt/pulls?q=3Dis%3Apr+author%3Akim0 URL: http://julipedia.meroh.net/2015/02/kyua-turns-parallel.html URL: https://github.com/jenkinsci/multiple-scms-plugin/commits?author=3D= rodrigc URL: https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/00= 1545.html URL: https://wiki.freebsd.org/ExternalToolchain Contact: Craig Rodrigues Contact: Jenkins Administrators Contact: FreeBSD Testing The Jenkins Continuous Integration and Testing project has been helping to improve the quality of FreeBSD. Since the last status report, we have quickly found commits which caused build breakage or test failures. FreeBSD developers saw these problems and quickly fixed them. Some of the highlights include: * Ahmed Kamal agreed to join the jenkins-admin team. Even though he is not a FreeBSD committer, he is subscribed to the jenkins-admin alias, and is contributing code via GitHub. Ahmed has contributed multiple SaltStack scripts which are in the freebsd-ci GitHub repository. Ahmed has also found multiple bugs in SaltStack's FreeBSD support. He has fixed these bugs and pushed them back to SaltStack via GitHub pull requests. Ahmed is a software developer who lives in Cairo, Egypt. He presently works for Cloud9ers, a cloud and devops consulting firm. In the past, he has worked for Canonical as the Ubuntu Cloud and Server community liaison. Ahmed found out about the Request for Help sent out by Craig Rodrigues for help with Jenkins in FreeBSD via a random web search. Ahmed found FreeBSD to be a very nice project, and was eager to volunteer and help out, and responded to the Request. Ahmed will attend BSDCan, where he will learn more about the BSD Community. * Julio Merino extended Kyua to support executing test cases in parallel. This should help the scaling of testing in environments with thousands of test cases. * Craig Rodrigues got a commit bit to the Jenkins Multiple SCM's plugin, and committed fixes to that plugin to help it work with Subversion 1.8 * Craig Rodrigues worked with Dimitry Andric in the freebsd-toolchain team to help identify and fix several compile problems in the FreeBSD src tree when using GCC 4.9. This work will help with the External Toolchain project. Open tasks: 1. Set up more builds based on different architectures. 2. Improve the maintenance of nodes in the Jenkins cluster using devops frameworks such as Saltstack. 3. People interested in helping out should join the freebsd-testing@FreeBSD.org list. __________________________________________________________________ Lua boot loader URL: https://svnweb.freebsd.org/base/projects/lua-bootloader/ Contact: Rui Paulo Contact: Pedro Souza Contact: Wojciech Koszek The Lua boot loader project is in its final stage and it can be used on x86 already. The aim of this project is to replace the Forth boot loader with a Lua boot loader. All the scripts were re-written in Lua and are available in sys/boot/lua. Once all the Forth features have been tested and the boot menus look exactly like in Forth, we will start merging this project to FreeBSD HEAD. Both loaders can co-exist in the source tree with no problems because a pluggable loader was introduced for this purpose. The project was initially started by Wojciech Koszek, and Pedro Souza wrote most of the Lua code last year in his Google Summer of Code project. To build a Lua boot loader just use: WITH_LUA=3Dy WITHOUT_FORTH=3Dy Open tasks: 1. Feature/appearance parity with Forth. 2. Investigate use of floating point by Lua. 3. Test the EFI Lua loader. 4. Test the U-Boot Lua loader. 5. Test the serial console. __________________________________________________________________ Mellanox iSCSI Extensions for RDMA (iSER) Support Contact: Max Gurtovoy Contact: Sagi Grimberg Building on the new in-kernel iSCSI initiator stack released in FreeBSD 10.0, and the recently added iSCSI offload interface, Mellanox Technologies has begun developing iSCSI extensions for RDMA (iSER) initiator support to enable efficient data movement using the hardware offload capabilities of Mellanox's 10, 40, 56, and 100 gigabit IB/Ethernet adapters. Remote Direct Memory Access (RDMA) has been shown to have a great value for storage applications. RDMA infrastructure provides benefits such as zero-copy, CPU offload, reliable transport, fabric consolidation and many more. The iSER protocol eliminates some of the bottlenecks in the traditional iSCSI/TCP stack, provides low latency and high throughput, and is well suited for latency-aware workloads. This work includes a new ICL module that implements the iSER initiator. The iSCSI stack is slightly modified to support some extra features such as asynchronous IO completions, unmapped data buffers, and data-transfer offloads. The user will be able to choose iSER as the iSCSI transport with iscsictl(8). The project is in its initial implementation phase. The code will be released under the BSD license and is expected to be completed later this year. This project is sponsored by Mellanox Technologies. __________________________________________________________________ Multipath TCP for FreeBSD URL: http://caia.swin.edu.au/urp/newtcp/mptcp/ Contact: Nigel Williams Multipath TCP (MPTCP) is an extension to TCP that allows for the use of multiple network interfaces on a standard TCP session. The addition of new addresses and scheduling of data across these occurs transparently from the perspective of the TCP application. The goal of this project is to deliver an MPTCP kernel patch that interoperates with the reference MPTCP implementation, along with additional enhancements to aid network research. After a major re-design of the earlier prototype implementation, the patch is again able to establish and carry out multi-path connections that incorporate multiple addresses. Improvements have also been made to path management and to the code handling the addition of subflows to a connection. Most recently data-level re-transmission support has been added and is being tested. Soon more extensive testing of the patch in different multi-path scenarios will begin, with plans for a public release of v0.5 in May. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Testing of data-level re-transmission. 2. Basic support for per-subflow congestion control algorithm selection. 3. Testing and release of v0.5 patch. __________________________________________________________________ New Automounter URL: https://wiki.freebsd.org/Automounter URL: http://people.freebsd.org/~trasz/autofs.pdf URL: http://freebsdfoundation.blogspot.com/2015/03/freebsd-from-trenches= -using-autofs5-to_13.html Contact: Edward Tomasz Napiera=B3a The new automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and integrates with the Lightweight Directory Access Protocol (LDAP) service. After shipping in 10.1-RELEASE, most of the work focused on bug fixing, improving documentation, and optimization. The biggest new feature was the addition of a "-media" map, designed to handle removable media, such as flash drives or DVDs, and the necessary elements of infrastructure to support it, namely fstyp(8) and GEOM devd notifications. Also, the "-noauto" map was added, for automatic mounting of filesystems marked "noauto" in fstab(5), instead of having to write an autofs map for them. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Opaque ifnet URL: https://wiki.freebsd.org/projects/ifnet Contact: Gleb Smirnoff This project aims to design a new KPI for network drivers that would allow the network stack to evolve without breaking compatibility with older drivers. The core idea is to hide struct ifnet from drivers, giving the project the name "opaque ifnet". However, the project will include more changes than just hiding the struct's definition. At present, the new KPI has been prototyped, most of the important parts of network stack have been modified appropriately, and several drivers have been converted to the new KPI. The project needs more manpower, since there are many network drivers in the tree, with a total of 245 sites where a struct ifnet is allocated. This project is sponsored by Netflix. Open tasks: 1. Convert more drivers. __________________________________________________________________ pkg URL: https://github.com/freebsd/pkg URL: https://lists.freebsd.org/mailman/listinfo/freebsd-pkg Contact: Baptiste Daroussin Contact: Vsevolod Stakhov Contact: Andrej Zverev Lots of work has been done on the pkg(8) front, which has brought pkg(8) to the 1.5.0 release. Special attention has been spent on the test suite; the number of tests went from around 20 to more than 70. They are mostly functional tests, each of which tests many different features, with less emphasis on unit tests. One of the main highlights is initial support for provides/requires. This is still simple but is good enough to allow fixing a lot of situations when dealing with php-related ports: PHP can now safely upgrade from one major version to another. This allows for the pecl/pear packages to be reinstalled each time a minor php upgrade is done. Some pkg internals have been reworked to allow cross installation of packages without the need for chroot(2) or jail(2) calls. The plist and keyword parser have been improved to keep simplifying creating new ports: * Keywords can now have arguments * A lazy mode is available for setting credentials via the plist * Flags (immutable and others) can now be specified in the plist pkg now supports resume for http/ftp downloads. Open tasks: 1. Populate the ports tree with provides/requires. 2. Make all scripts in the ports tree support cross installation. 3. Improve provides/requires. 4. Continue adding more tests. __________________________________________________________________ Secure Boot URL: https://wiki.freebsd.org/SecureBoot Contact: Edward Tomasz Napiera=B3a UEFI Secure Boot is a mechanism that requires boot drivers and operating system loaders to be cryptographically signed by an authorized key. It will refuse to execute any software that is not correctly signed, and is intended to secure boot drivers and operating system loaders from malicious tampering or replacement. The utility to add Authenticode signatures to EFI files, uefisign(8), was committed to 11-CURRENT and will ship in 10.2-RELEASE. Ports for other open source utilities were added to the Ports Collection, as sysutils/pesign, sysutils/sbsigntool, and sysutils/shim. There is a prototype patch that makes boot1 use the Secure Boot shim, and modifies the shim to provide the functionality necessary for a successful bootstrap. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Finalize the shim API extension and get it accepted upstream. 2. Commit boot1 changes. __________________________________________________________________ Adding PCIe Hot-plug Support URL: http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/&c=3DLQ6@//d= epot/projects/pciehotplug/?ac=3D83 Contact: John-Mark Gurney PCI Express (PCIe) hot-plug is used on both laptops and servers to allow peripheral devices to be added or removed while the system is running. Laptops commonly include hot-pluggable PCIe as either an ExpressCard slot or a Thunderbolt interface. ExpressCard has built-in USB support that is already supported by FreeBSD, but ExpressCard PCIe devices like Gigabit Ethernet adapters and eSATA cards are only supported when they are present at boot, and removal may cause a kernel panic. The goal of this project is to allow these devices to be inserted and removed while FreeBSD is running. The work will provide the basic infrastructure to support adding and removing devices, though it is expected that additional work will be needed to update individual drivers to support hot-plug. Current testing is focused on getting a simple UART device functional. Basic hot swap is functional. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Get suspend/resume functional by saving/restoring the necessary registers. 2. Make sure that upon suspend, devices are removed so that if they are replaced while the machine is suspended, the new devices will be detected. 3. Improve how state transitions are handled, possibly by using a proper state machine. __________________________________________________________________ Address Space Layout Randomization (ASLR) URL: https://hardenedbsd.org/ URL: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/0= 54669.html URL: https://reviews.freebsd.org/D473 Contact: Shawn Webb Contact: Oliver Pinter Address Space Layout Randomization (ASLR) is a computer security technique that aids in mitigating low-level vulnerabilities such as buffer overflows. ASLR randomizes the memory layout of running applications to prevent an attacker from knowing where a given exploitable vulnerability lies in memory. We have been working hard the last few months to ensure the robustness of our ASLR implementation. We have written a manpage and updated the patch on FreeBSD's code review system (Phabricator). Our ASLR implementation is in use by the HardenedBSD team in production environments and is performing robustly. The next task is to compile the base system applications as Position-Independent Executables (PIEs). For ASLR to be effective, applications must be compiled as PIEs to allow the main binary, as well as shared libraries, to be located at random addresses. It is likely that this part will take a long time to accomplish, given the complexity surrounding building the libraries in the base system. Even if applications are not compiled as PIEs, having ASLR available still helps those applications (like HardenedBSD's secadm) which force compilation as PIE for themselves. This project is sponsored by SoldierX. Open tasks: 1. Test our patch against 11-CURRENT. __________________________________________________________________ Modern x86 platform support and VT-d Contact: Konstantin Belousov Modern x86 platforms include a number of architectural enhancements. Work is ongoing to support these features in FreeBSD. Starting with SandyBridge CPUs, Intel introduced an enhanced local interrupt controller (APIC) mode, called x2APIC. Instead of using a mapped page, registers are now accessed using special Model-Specific Registers (MSR) read and write instructions. This is intended to support virtualization. The access overhead is also reduced by not requiring serialization, and by simplification of Inter-Process Interrupt (IPI) generation. The main commit introducing the feature was r278473, with fixes following on. End Of Interrupt (EOI) suppression is a mode of EOI delivery to Input/Output Interrupt Controllers (IO-APICs) where the EOI message for a level-triggered interrupt is not broadcast by an EOI write to the local APIC, but instead an explicit EOI command is sent to the source IO-APIC. The optimization reduces the number of APIC messages that must be broadcast; it should be used on all modern Intel systems. Support for EOI suppression was committed in r279319. VT-d Interrupt Remapping (IR) is provided by hardware with the VT-d feature. It translates interrupt messages on the way from the root complex to the north bridge and allows control of interrupt delivery without reprogramming MSI/MSI-X registers or IO-APICs. The original intent was to allow hypervisors to safely delegate interrupt programming for devices owned by guests to the guest OS. IR is also needed to avoid some limitations in IO-APICs and to make interrupt rebalancing atomic and transparent. Support has been committed as r280260. Both x2APIC mode and IR are required to send IPIs and device interrupts to processors with LAPIC ID greater then 254. It is believed that the only missing platform code to handle big machines is parsing the "Processor Local x2APIC Structure" and "Local x2APIC NMI Structure" from the ACPI Multiple APIC Description Table (MADT), which report LAPIC IDs > 255, and handling boot on such systems with the x2APIC mode enabled by firmware. The work to complete that is expected to be relatively trivial, and can be done with access to a real high-core-count machine. But an audit of the common machine-independent code must be finished to ensure that large CPU IDs are handled correctly, before such support can safely be enabled. Additional work remains in progress: split domains and contexts for DMA Remapper Unit (DMAR) driver. Right now, the DMAR driver is only used to implement busdma(9), which is done by assigning a dedicated domain to each translation context. Some devices could issue PCIe Transaction Layer Packets (TLPs) with several originators IDs, e.g., PCIe/PCI bridges, or phantom functions of PCIe devices, or such TLPs could occur just due to hardware bugs. To handle them, a single domain (which shares the translation page tables) must handle several contexts. Splitting domains and contexts is also required for the DMAR driver to start handling PCI pass-through in bhyve, instead of the less complete implementation which is currently provided by bhyve itself. All PCIe devices passed to the guest must share a domain. The splitting patch is written and is being tested, and external interfaces to manage domains are being formed. Stability work for the VT-d code is ongoing. In particular, nvme(4) and ixgbe(4)'s use of busdma interfaces was debugged and improved, and tested on a very large-memory machine. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Nanosecond file timestamps Contact: Jilles Tjoelker Contact: Sergey Kandaurov Two new system calls, futimens() and utimensat(), were added, making it possible to set file timestamps with nanosecond accuracy. Various utilities like cp, mv and touch were updated to use the new calls to preserve and set timestamps with full precision. The stat() and related system calls have returned file timestamps with nanosecond accuracy for a long time, but there was no way to set a timestamp more accurately than microseconds. With these changes, it will be possible to use more accurate timestamps (sysctl vfs.timestamp_precision=3D3) without anomalies such as a copy of a file (from cp -p) appearing older than the original. This is particularly useful for NFS servers, which use file timestamps for cache invalidation. Open tasks: 1. Where possible, fix code that still sets inaccurate timestamps on files, typically by calling futimes(), futimesat(), lutimes(), utime() or utimes() with a non-null times pointer. There may be a reason for this such as a limited network protocol or file format, but there is some code left that can be fixed. __________________________________________________________________ FreeBSD on newer ARM boards URL: https://wiki.freebsd.org/FreeBSD/arm/Odroid-C1 URL: https://svnweb.freebsd.org/changeset/base/280905 Contact: John Wehle Contact: Ganbold Tsagaankhuu We made the changes necessary to support various Amlogic SoC devices, specifically aml8726-m6 and aml8726-m8b SoC-based devices. The aml8726-m6 SoC is used in devices such as the Visson ATV-102, and the Hardkernel ODROID-C1 board uses the aml8726-m8b SoC. The following support is included: * Basic machdep code * SMP * Interrupt controller * Clock control driver (aka gate) * Pinctrl * Timer * Real time clock * UART * GPIO * I2C * SD controller * SDXC controller * USB * Watchdog * Random number generator * PLL/Clock frequency measurement * Frame buffer Open tasks: 1. Get the DWC driver working. __________________________________________________________________ FreeBSD/arm64 URL: https://wiki.freebsd.org/arm64 URL: https://github.com/FreeBSDFoundation/freebsd/tree/arm64-dev Contact: Andrew Turner Contact: Ed Maste Contact: Zbigniew Bodek The collaborative development on the FreeBSD arm64 port made significant progress over the last quarter. The FreeBSD Foundation is collaborating with ARM, Cavium, the Semihalf team, and Andrew Turner to port FreeBSD to the arm64 architecture, also known as ARMv8 and AArch64. After significant review and refinement, the initial set of changes are being delivered into FreeBSD-HEAD. This initial support targets the QEMU and ARM Foundation Model emulators, and boots to a usable multiuser environment. Cavium's ThunderX platform is the initial hardware reference target for the FreeBSD arm64 port. The platform currently boots to multiuser, with a root file system mounted over NFS via a PCIe 10 Gbps Ethernet NIC. Reference hardware is installed in the FreeBSD test lab hosted by Sentex Communications and in Semihalf's offices. This project is sponsored by The FreeBSD Foundation, ARM, and Cavium. Open tasks: 1. Merge kernel changes to HEAD. 2. Finish remaining userland and kernel support. 3. Produce installable images. __________________________________________________________________ Nested Kernel URL: http://nestedkernel.org URL: http://web.engr.illinois.edu/~dautenh1//downloads/publications/aspl= os200-dautenhahn.pdf URL: http://prezi.com/in6qr3l92ffc/?utm_campaign=3Dshare&utm_medium=3Dco= py URL: https://github.com/HardenedBSD/hardenedBSD/tree/hardened/9/kernsep Contact: Nathan Dautenhahn Contact: Theodoros Kasampalis Contact: Will Dietz This work on a nested kernel architecture is part of Nathan's doctoral thesis work at the University of Illinois at Urbana-Champaign. It attempts to improve upon the traditional monolithic operating system kernel, where a single exploit anywhere in the kernel grants the attacker full superuser privileges. The nested kernel operating system architecture addresses this problem by "nesting" a small, isolated kernel within a traditional monolithic kernel. This "nested kernel" interposes on all updates to virtual memory translations to assert protections on physical memory, thus significantly reducing the trusted computing base for memory access control enforcement. We incorporated the nested kernel architecture into FreeBSD on x86-64 hardware by write-protecting Memory-Management Unit (MMU) translations and de-privileging the untrusted part of the kernel, thereby enabling the entire operating system, trusted and untrusted components alike, to operate at the highest hardware privilege level. Our implementation inherently enforces kernel code integrity while still allowing dynamically loaded kernel modules, thus defending against code injection attacks. We also demonstrate, by introducing write-mediation and write-logging services, that the nested kernel architecture allows kernel developers to isolate memory in ways not possible in monolithic kernels, though gaining security benefits from this will require adding policies that have not yet been designed. The performance of the nested kernel prototype shows modest overheads: less than 1% average for Apache, 3.7% average for sshd, and 2.7% average for kernel compilation. Overall, our results and experience show that the nested kernel design can be retrofitted onto existing monolithic kernels, providing defense in depth. The basic idea is that the nested kernel initializes the system so that all page tables are mapped as read-only. Then all MMU-modifying operations are removed from the untrusted portion of the kernel; runtime code integrity is enforced by write-protecting all code pages, marking all non-code pages as non-executable (NX-bit), and preventing execution of privileged MMU operations located in userspace mappings (Supervisor Mode Execution Prevention, SMEP). Because the nested kernel has control of the page tables it can enforce these integrity properties, leading to virtualization of the MMU. The links include a recent conference publication that details the design, implementation, and evaluation of our prototype nested kernel architecture on top of FreeBSD 9.0. There is also a link to a presentation on the nested kernel, and a website with information about the project and instructions on how to get the source and build it. We are very interested in feedback on the design of the nested kernel, and having discussions about how it might get upstreamed. We are also hoping to gain additional contributors and interest in the project! The nested kernel has the potential to enhance commodity operating system design, and FreeBSD is a major operating system in use today which has high impact. The current implementation is merely a research prototype and requires significant effort to make production-ready (see the list of tasks). Finally, we have developed an interface to write-protect data structures in the kernel and are soliciting ideas for uses of this service. Section 2.4 in the paper details the interface, and section 4 presents some simple uses of the nested kernel services. We are interested in ways that the nested kernel could be used to protect critical kernel data structures from malware or even just buggy code. This project is sponsored by University of Illinois at Urbana-Champaign, and ONR via grant number N00014-12-1-0552. Open tasks: 1. Finish implementing core mechanisms: verify DMAP is properly protected and that we are not using superpages (I think we have this completed but need to fully verify), full NX support for all non-kernel code pages (we might need to specially consider the stack if it is used to execute code), protect IDT and SMM, and add IOMMU protections. We also need to do some optimizations where we batch calls into the nested kernel on process creation (fork) and mmap operations. The motivation for these implementation directives can be reviewed in the paper. 2. Implement SMP functionality and evaluate performance. 3. Port and refactor for FreeBSD-HEAD. The current implementation is a research prototype and requires some refactoring to make it clean and consistent, as well as make it relevant to modern versions of FreeBSD. 4. The nested kernel isolation depends upon certain hardware instructions to be completely removed from a subset of the kernel. Therefore, we need to utilize automated linker/loader techniques to identify and remove privileged MMU operations from untrusted kernel components to make it maintainable in practice. 5. Detailed review on the design and implementation with particular focus on a plan for upstreaming. __________________________________________________________________ libthr improvements Contact: Konstantin Belousov Historically, dynamic loading of the libthr.so thread library into a single-threaded process did not work in FreeBSD. The longstanding recommendation to work around the problem has been to always link the main binary with -lpthread if there was any chance of a need for threading functionality. This project converted libthr.so into a plugin for libc, which fixed the known issues preventing dynamic loading of libthr.so. After the fix, linking the main binary with -lpthread is no longer required, but is not harmful. I recommend thoroughly testing before removing libpthread from the library list in favor of dynamic loading, though. Note that potential problems will be subtle and their user-visible manifestations in the affected program even more surprising. The following issues were present in the old version of libthr with respect to dynamic loading, but are fixed as a result of this work: * Invalid errno value seen after failed syscalls. * Broken libthr internal locks and critical sections ignored by signals. * Hung attempts to lock mutexes. * Thread cancellation not occurring at guaranteed cancellation points. The main change was committed as r276630 to HEAD, with many follow ups. It was merged to stable/10 in r277317. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Migration to ELF Tool Chain tools URL: http://elftoolchain.sourceforge.net Contact: Ed Maste The ELF Tool Chain project provides BSD-licensed implementations of compilation tools and libraries for building and analyzing ELF objects. The project began as part of FreeBSD but later became an independent project to encourage wider participation from others in the open-source developer community. ELF Tool Chain provides a set of tools equivalent to the GNU Binutils suite. This project's goal is to import these tools into the FreeBSD base system so that we have a set of up-to-date and maintained tools that also provide support for new CPU architectures of interest, such as arm64. In addition to the libelf and libdwarf libraries, the following tools are now provided by the ELF Tool Chain project: * addr2line * nm * readelf * size * strings * strip (elfcopy) ELF Tool Chain's elfcopy provides equivalent functionality to Binutils' objcopy, and accepts the same command-line arguments. For it to be a viable replacement for all uses of objcopy in the base system, it must gain support for writing portable executable (PE) format binaries, which are used by UEFI boot code. The ELF Tool Chain project does not currently provide replacements for as, ld, or objdump. For FreeBSD, these tools will likely be obtained from the LLVM project. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Add missing functionality to elfcopy and migrate the base system build. 2. Fix issues found by fuzzing inputs to the tools. 3. Add automatic support for separate debug files. __________________________________________________________________ The LLDB Debugger URL: https://wiki.freebsd.org/lldb Contact: Ed Maste LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, FreeBSD and Windows platforms. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler. The LLDB in the base system was upgraded to version 3.6.0 as part of the Clang and LLVM upgrade. In the upstream repository, Justin Hibbits added support for live and core file debugging on PowerPC, and Ed Maste added core file support for FreeBSD/arm64. This project is sponsored by DARP/AFRL, SRI International, and University of Cambridge. Open tasks: 1. Rework the LLDB build to use LLVM and Clang shared libraries. 2. Port remote debug stub to FreeBSD. 3. Add support for local and core file kernel debugging. 4. Improve support on non-amd64 architectures. 5. Enable by default in the base system. __________________________________________________________________ Updates to GDB URL: https://github.com/bsdjhb/gdb/tree/freebsd-7.9.0-kgdb Contact: John Baldwin Several improvements to GDB have been merged upstream to GDB's master branch over the past few months, including fixes for unwinding across signal trampoline frames on x86, removing the procfs dependency from the gcore command, and support for XSAVE extensions (such as AVX registers) on x86. These fixes are already available in the existing devel/gdb port as patches relative to 7.8. In addition, progress has been made on porting kgdb to a newer gdb. Currently, only support for the amd64 backend has been ported, but it is functional both for remote debugging and against crash dumps. The current port generally has feature parity with the kgdb in the base system. The plan for kgdb is to fix it to always include all platform targets (so that it always supports cross debugging for remote targets out of the box). At some point it may also include cross debugging support for crash dumps as well (this would require changes to libkvm). Open tasks: 1. Tidy the amd64 port of kgdb and finish the i386 port. This includes fixing these platform-specific targets to work with cross-debugging for remote targets. 2. Add a KGDB option to the devel/gdb port to include kgdb support. 3. Port the rest of the platform-specific targets for kgdb. 4. Write a new 1:1-only thread target for FreeBSD that can be sent upstream. 5. Add support for debugging powerpc vector registers. __________________________________________________________________ FreeBSD Ada Ports URL: http://home.gna.org/ghdl/ URL: http://sourceforge.net/projects/ghdl-updates/ Contact: John Marino There are 51 Ada-related ports currently, but two of them are being retired: the GCC 4.7-based lang/gcc47-aux and the BSD->android cross-compiler for ARMv5 (lang/gnatdroid-armv5). The former has no advantage over the newer GCC 4.9-based lang/gcc-aux, and the latter has not built for over a year. Android enthusiasts can still use the the ARMv7 cross-compiler (lang/gnatdroid-armv7). A new port is lang/gcc5-aux, which includes GNAT from the upcoming release of gcc5. This compiler already builds all Ada ports except gtkada3 (which blocks devel/gps, the GNAT Programming Studio), and gtkada3 should be fixed soon. When GCC5 is released, the Ada framework will switch to using gcc5-aux as the default compiler. For those that cannot wait, it is possible to use it now by putting ADA_DEFAULT=3D5 in /etc/make.conf, but this requires rebuilding all Ada ports from source. Open tasks: 1. It is a near-term objective to bring the Ada-based GDHL (VHDL simulator) to ports. The upcoming 0.32 release will be based on GCC 4.9 and the port will be based on this release. __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team The FreeBSD Python team continued to improve the overall experience with Python-based software on FreeBSD. A lot of previously deprecated code and option knobs were removed to improve the maintainability of the Python Ports infrastructure. The CPython interpreters were updated to version 2.7.9 and 3.4.3 and Twisted was updated to version 15.0.0. Open tasks: 1. Retire the Python 3-specific port duplicates. 2. More tasks can be found on the team's wiki page (see the links). 3. To get involved, interested people can say hello on IRC in #freebsd-python on freenode and let us know their areas of interest! __________________________________________________________________ GNOME on FreeBSD URL: http://www.freebsd.org/gnome URL: https://github.com/freebsd/freebsd-ports-gnome URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD Contact: FreeBSD GNOME Team The FreeBSD GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel. At the end of this quarter we updated GNOME and CINNAMON to the latest versions on their branches, 3.14 and 2.4, respectively. GNOME 3.16 was released February 25th; we ported it to FreeBSD. There are still some showstopper problems that appeared. During testing of the current versions of the 3.16 ports a bug in pkg was uncovered in the multiple repository support, and swiftly fixed in pkg 1.4.99.15. For the GNOME 3.18 cycle we are going to work closely with the x11 team on porting libinput and testing Wayland. When that is done we need to see if we want to enable Wayland for our stable releases and we probably need XWayland from xorg-server 1.16+ to support X applications. The estimate is that Wayland arriving in ports will have to wait until 8.4-Release is EOL. Open tasks: 1. The GNOME website is stale. Work is underway, although slowly, on the development section. We could use some help here. 2. MATE 1.10 porting is under way; the latest 1.9 releases are available in the mate-1.10 branch. __________________________________________________________________ KDE on FreeBSD URL: https://freebsd.kde.org/ URL: https://freebsd.kde.org/area51.php URL: https://wiki.freebsd.org/KDE URL: https://mail.kde.org/mailman/listinfo/kde-freebsd URL: https://github.com/tcberner/kde5 Contact: KDE on FreeBSD team The KDE on FreeBSD team focuses on packaging and making sure that the experience of KDE and Qt on FreeBSD is as good as possible. First of all, we would like to welcome Tobias Berner to the ranks of the area51 (the KDE ports staging area) committers. He has been regularly mentioned in our recent status reports, and has finally received committer privileges to our experimental repository. Becoming an area51 committer is usually the first step towards becoming a kde@ ports committer. We hope that Tobias can fix and update our ports more easily, and start committing his KDE Frameworks 5 ports to area51. Additionally, this quarter Qt 5.4.1 was committed to the ports tree. This marks the first time ever since Qt 5 was released that we have the latest upstream stable release in our ports tree! This was made possible by all the work we had to put into cleaning up the Qt 5 ports infrastructure for the 5.3 update, mentioned in our previous status report. Last but not least, Alonso Schaich finally landed an update to our KDE4 ports that had been in our experimental repository for a while, bringing them to the latest 4.14 release, 4.14.3. Overall, we have updated the following ports in this quarter: * Calligra 2.9.1 (committed to area51) * CMake 3.1.0, 3.1.1, 3.1.3 (committed to ports) * DigiKam 4.2.0 (committed to ports), 4.8.0 (committed to area51) * PyQt 4.11.3 + QScintilla 2.8.4 + sip 4.16.5 (committed to ports), sip 4.16.7 (committed to area51) * Qt 5.4.1 (committed to ports) Open tasks: 1. Put more effort into Qt5-related ports: KDE Frameworks 5 (currently worked on by Tobias Berner) and PyQt 5. __________________________________________________________________ The Graphics stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://blogs.freebsdish.org/graphics/ URL: https://github.com/freebsd/freebsd-ports-graphics Contact: FreeBSD Graphics team In the official Ports tree, the Mesa ports (libglapi, libGL, libEGL, libglesv2, gbm, and dri) are kept close to the latest Mesa 10.4.x release. In the development tree (see the GitHub link), the update to Mesa 10.5 came, along with several improvements and cleanup to the ports themselves. Now all ports share the same configure flags and build dependencies. As Mesa is built from scratch for each port, this ensures that all libraries and drivers are consistent with each other. This fixes at least two problems: * A long standing bug: the drm EGL platform is now functional, meaning we will be able to enable Glamor (the 2D acceleration engine based on OpenGL) in the X.Org server. This is required to provide 2D acceleration for Radeon HD 7000 and later GPUs, for instance. * Clover, the Mesa OpenCL implementation, now works; see the next paragraph. The downside of this unification is that all ports will depend on LLVM. This work is happening in the mesa-10.5 branch. Progress has been made on OpenCL, thanks to help from Johannes Dieterich. Clover (Mesa's implementation) and Beignet (Intel's implementation) were added as ports to the development tree. They were tested successfully on Radeon and Intel GPUs, but see the wiki for an up-to-date status. Initially developed in the opencl branch, everything has now been merged into the mesa-10.5 branch. This cannot go into the official Ports tree yet because it requires the unification explained above. A new port, drm-kmod, was added to the official Ports tree. It provides updated drm2, i915kms and radeonkms kernel modules for FreeBSD 9.3-RELEASE and 9.3-STABLE. The only difference from the vanilla modules is the addition of hardware context support to the i915 driver. The xf86-video-radeon and xf86-video-intel drivers were patched to use the drm-kmod port on these versions of FreeBSD. This will allow us to remove the duality of the Mesa ports (libGL/libEGL/dri) and only support one version (as is already the case in the mesa-10.5 branch where Mesa 9.1.7 is gone). There is no ETA yet for when this last part will happen. In the development Ports tree, the xserver-next branch was updated from xorg-server 1.16 to be tracking 1.17. Again, this depends on the previous step: the removal of Mesa 9.1.7. Work is finishing up on an update of miscellaneous X.Org components. Apart from updates to several X.Org ports, this update also removes the use of .la files from the X.Org libraries that still have them. Also, the xf86-video-intel driver will receive patches to allow it to compile against a newer xorg-server than 1.14. Most of the X.Org component updates were submitted by Matthew Rezny. The location where fonts get installed was overhauled and the way to handle fonts from the plist has been simplified. Now all fonts are installed in /usr/local/share/fonts as required by the XDG rules. Furthermore, making a port for fonts should be easier: more aspects, such as calling fc-cache(1), are handled by the Ports framework. Therefore, the font ports' consistency was greatly improved. In the kernel, the DRM device-independent code was updated to match Linux 3.8. A merge to 10-STABLE is pending. The i915kms kernel driver received an update, too, which is already merged to 10-STABLE. Having both updates in place enables work on a second update of the i915 driver: this time it will be synchronized with Linux 3.8, like the rest of the DRM subsystem, and include Haswell support. This work was started recently. Our hope is that it will be ready in time for FreeBSD 10.2-RELEASE. During Q2, we are going to work with the GNOME team on porting libinput and testing Wayland. Currently we know that GTK+3 and GNOME 3 have full support for Wayland. We also need to test Xwayland from xorg-server 1.16+ to support X applications on Wayland desktops. If you know of more software that uses Wayland, we would like to hear about them. At this point there are no plans to port the Weston reference implementation of a Wayland compositor. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Wine/FreeBSD URL: http://wiki.FreeBSD.org/Wine URL: http://wiki.FreeBSD.org/i386-Wine URL: http://www.winehq.org Contact: Gerald Pfeifer Contact: David Naylor This quarter has seen five updates to the wine-devel port that closely tracks upstream development, as well as updates to helper ports (wine-gecko-devel and wine-mono-devel): * Stable releases: 1.6.2 (1 port revision) * Development releases: 1.7.34 through 1.7.39 A major development has been the introduction of Wine64 (i.e., the ability to run 64-bit Windows applications). This is currently available through the wine-devel port. At this stage it is currently mutually exclusive with the i386-wine-devel port, however, we have plans to integrate these ports to offer a full Wine experience on amd64. The i386-wine-devel port has packages built for amd64 for FreeBSD 8.4, 9.1+, 10.1+ and CURRENT. Accomplishments include: * Upstreaming 8 patches to fix Wine on FreeBSD -- many thanks to Gerald and David. * Optional support for V4L has been added to the stable emulators/wine port. * Optionally building wine with the X composite extension (if one selects the X11 option). * Support for alternative toolchains that require LD to be honoured. * Fixing and tidying up the pkg-plist. * Wine64 support * Updating the patch-nvidia.sh script to support arbitrary suffixes. * Removing support for the old pkg_ tools from patch-nvidia.sh. * Developing a patch to fix usage of getdirentries(2). This fixes Steam, EVE Online and other applications. We would like to thank all volunteers who contributed feedback and patches. Future development on Wine will focus on: * Rename wine-compholio to wine-staging (to match upstream development). * Add the getdirentries(2) patch to the wine-devel port. * Redevelop and upstream the getdirentries(2) patch. * Redevelop and upstream the kernel32 Makefile patch. * Add support to the i386-wine port for pkg 1.5 (conflicts with libraries currently prevent such support). * Add support for WoW64: + Reduce the i386-wine port to just the components required for WoW64. + Rename the i386-wine port to wow64. + Make the wine ports depend on the wow64 ports when built on amd64. + Investigate and verify the interactions between Wine64 and WoW64. + Investigate possible update approaches for the wow64 ports (that have to be pre-compiled) and how updating with the wine ports will work. Maintaining and improving Wine is a major undertaking that directly impacts end-users on FreeBSD (including many gamers). If you are interested in helping, please contact us. We will happily accept patches, suggest areas of focus or have a chat. Open tasks: 1. FreeBSD/amd64 integration (see the i386-Wine wiki). 2. Porting WoW64. __________________________________________________________________ Xfce on FreeBSD URL: https://wiki.freebsd.org/Xfce Contact: FreeBSD Xfce Team Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. This quarter was an exciting time for the Xfce Team. We imported version 4.12 of the Xfce desktop environment into the ports tree, after more than two years of development. Overall, we have updated the following ports: * Xfce core (4.12) * audio/xfce4-mpc-plugin (0.4.5) * deskutils/xfce4-tumbler (0.1.31 * deskutils/xfce4-xkb-plugin (0.7.1) * editors/mousepad (0.4.0) * graphics/ristretto (0.8.0) * multimedia/xfce4-parole (0.8.0) * sysutils/garcon (0.4.0) * sysutils/xfce4-diskperf-plugin (2.5.5) * sysutils/xfce4-fsguard-plugin (1.0.2) * sysutils/xfce4-power-manager (1.4.4) * sysutils/xfce4-wavelan-plugin (0.5.12) * textproc/xfce4-dict-plugin (0.7.1) * www/xfce4-smartbookmark-plugin (0.4.6) * x11/libexo (0.10.4) * x11-clocks/xfce4-timer-out-plugin (1.0.2) * x11-fm/thunar (1.6.6) * x11-themes/gtk-xfce-engine (3.2.0) At the same time we switched to the USES framework, and a new plugin has been added, called audio/xfce4-pulseaudio-plugin. We also follow the unstable releases (available in our experimental repository) of: * x11/xfce4-dashboard (0.3.91) * x11/xfce4-notes-plugin (1.8.0 beta) The following documentation patches are ready: * PR197878, Update Xfce section in Porter's Handbook * D1305, FAQ Open tasks: 1. Work on support for Compact Disc Digital Audio (CD-DA) in multimedia/xfce4-parole. 2. Add a new property (through xfconf-query) to allow users to change the greyscale value of quicklaunch icons in x11/xfce4-dashboard (this feature is only available in the unstable release). __________________________________________________________________ More Michael Lucas FreeBSD books URL: http://blather.michaelwlucas.com/archives/2352 Contact: Michael Lucas The FreeBSD storage books are proceeding slower than expected. This is a complex project. It appears that ZFS will be a two-book topic. The first book will cover basic ZFS, while the second will cover advanced cases like live and cold replication, sharing, performance, and using ZFS on top of less common GEOM providers. More details can be found in the links section. Allan Jude (allanjude@) is co-authoring the ZFS books. Little did he know of the magnitude of the task ahead of him when he signed up.... __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ URL: http://www.bsdnow.tv/episodes/2015_03_11-the_pcbsd_tour_ii URL: http://www.bsdnow.tv/episodes/2015_02_25-from_the_foundation_2 Contact: Deb Goodkin The Foundation turned 15 on March 15th! We kicked off our anniversary celebration by launching a spring fundraising campaign, to bring in 500 new community investors. In conjunction with our anniversary, BSDNow interviewed Justin Gibbs about our history and plans for the future as part of the PC-BSD tour. BSDNow also interviewed Ed Maste about FreeBSD projects and processes in a "From the Foundation" episode. We were a Platinum Sponsor of AsiaBSDCon and had five team members attend the conference. Kirk McKusick taught a two-day FreeBSD kernel tutorial and gave a talk on Journaled Soft Updates, and George Neville-Neil gave a talk on network performance in FreeBSD; George also taught a two day tutorial (A Look Inside FreeBSD with DTrace). This is from ongoing work with Robert Watson in support of both academic and practitioner educational material for FreeBSD. Dru gave a talk on Advanced OpenSource Storage with FreeNAS 9.3, and Ed Maste gave a talk on the LLDB Debugger in FreeBSD. We became a Platinum Sponsor for BSDCan, and have approved six travel grants to FreeBSD contributors. We also sponsored Michael Dexter to attend SCALE so he could give a talk on virtualization. In addition to the above conferences, we helped promote FreeBSD at the following conferences: * USENIX FAST '15 * FOSDEM * SCALE We received and published FreeBSD testimonials from Xinuos, Netgate, and Tarsnap. We launched the "From the Trenches" series to provide stories from FreeBSD contributors on what they are doing with FreeBSD. Glen Barber wrote an article called ZFS and How to Make a Foot Cannon. Glen also investigated a deadlock issue when rebooting after upgrades (PR 195458), and he released weekly 11-CURRENT and 10-STABLE snapshot builds. The FreeBSD Journal now has over 8300 subscribers and has a 98% renewal rate. We are now publishing a few free FreeBSD Journal articles. We also created landing pages for each Journal issue for easier promotion. We started work on the Ottawa Vendor and Developer Summits and another one that has not yet been officially announced on the East Coast in the fall. Our development staff and project grant recipients were responsible for a large number of feature improvements and bug fixes over this past quarter. We have nine individual reports in this quarterly update for Foundation-sponsored projects that demonstrate a number of different ways the Foundation supports the FreeBSD project. One project is the subject of a research master's project at Swinburne University in Melbourne: the Multipath TCP (MPTCP) implementation for FreeBSD. The PCIe hot plug project is an individual project grant. The FreeBSD/arm64 project represents a collaborative development effort, where the Foundation facilitates a broader project with multiple participants. There are also a number of projects undertaken directly by Foundation staff. In this quarterly report we have several reports in this category: Secure Boot, the autofs-based automount daemon, dynamically loadable libthr, Intel DMA remapping, and migration to the ELF Tool Chain project tools. Additionally, one of the benefits of having long-term permanent staff is the ability to continue to maintain projects and contribute improvements beyond a fixed timeline. Over the last quarter, Foundation staff contributed improvements to the UEFI boot process, vt(4) system console, in-kernel iSCSI stack, virtual memory subsystem, and many others. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAEBCgAGBQJVQvLjAAoJECjZpvNk63USJccMH3ysbDt3xkAcUjn2DM3LAsLy vONxPv1h0J3WujOQAXvBMLrfyiQNybOmEs28xRMhMdePhJOjNdUI/qeS6FvuUQ3D mgR2ZR5uv1Qni3zpA8H2F7e/EGptLDZrstUdo5lrleJ52CBukljyQxTOzfIsqg8j VNkM4qaUrloT19PRbWjSIY0+RKyFRClavjcXmpUNobNAfTgKyzraN1A9V6Rq+bZA Z1ET5EnaqMJlh6Qt9KIQu3WUFK6isqbXVBScScxhMhlr0e0bXi/isP1BpE7tOZkA Q2iFSwteCZVt161mOpQOl8o+fnlIkFdkLw4weSzuXXheYDXhQPnEgStJ36pSPJsU MhFtXviMsYP2olf5a1LAO9KmG5rpNM2IaHIPCUJffRROhVwLKjRkfQpwMq1ECoqc F3mm/a6wG2ca2qbrUDVOeL0WhX0Qd6Zr+c9mVwo0WCz2zH7J61Grm4Z1DEemfV30 OlVH7jmux0ue7xNsGeo4M72uj5jtUIan5zfEAMf9t1PBzrI=3D =3DQJWh -----END PGP SIGNATURE-----