From owner-freebsd-hackers@freebsd.org Sun May 1 16:46:25 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D937DB29990 for ; Sun, 1 May 2016 16:46:25 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from smtp21.mail.ru (smtp21.mail.ru [94.100.179.250]) (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 5A614108A for ; Sun, 1 May 2016 16:46:24 +0000 (UTC) (envelope-from trafdev@mail.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=s51i1oKboBPd6Q1ag+WpBgwZLiQ0D3Lns1fa/8I+j94=; b=TC8EopatuxKdouA/CxOoWvZs9C4lkJZtV+Rk+BSLjpNMmzhmLl44CSO2CR+mvBrSKHeHxv+K1/KoX/5Dniu6B6wnbxDMO3yYS9xnhvm2yQOaaEDwkSsyj+wqc5f2HQIezZj/v5daAILmlWYtLmGxzxoUwvgubJhsxO9tSL0DcXE=; Received: from c-50-156-112-176.hsd1.ca.comcast.net ([50.156.112.176]:44391 helo=[192.168.1.116]) by smtp21.mail.ru with esmtpa (envelope-from ) id 1awuVb-0006hE-9J for freebsd-hackers@freebsd.org; Sun, 01 May 2016 19:46:16 +0300 To: freebsd-hackers@freebsd.org From: trafdev Subject: corrupted stack (backtrace) from sigaction handler Message-ID: <94c8456c-a9b4-77a5-6622-418fc59d61d7@mail.ru> Date: Sun, 1 May 2016 09:46:10 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 X-Mras: OK Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 16:46:26 -0000 Hello! Could you launch attached code on your machine and respond with an output (and FreeBSD version). Here is mine (FreeBSD 10.2) output: stack dump [0] 0x40d4e5 <_Z9stackdumpPKc+0x85> at /ara/devel/sandbox/new/cpp/Release/cpp stack dump [1] 0x40dafd <_Z13signalHandleriP9__siginfoPv+0x3d> at /ara/devel/sandbox/new/cpp/Release/cpp stack dump [2] 0x801f30997 at /lib/libthr.so.3 stack dump [3] 0x801f301a8 at /lib/libthr.so.3 All info before signalHandler (foo/foo2 functions) is missed. From owner-freebsd-hackers@freebsd.org Sun May 1 20:51:31 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 248E2B29E2A for ; Sun, 1 May 2016 20:51:31 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B2D0F1707 for ; Sun, 1 May 2016 20:51:30 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id a17so115157226wme.0 for ; Sun, 01 May 2016 13:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=ERIg4HHuIsrdX9llKPCiZuj7h2taw5KiOFQQzcP69Mo=; b=MlMiD46KlJoFKAKgeRW8VfLOrN3Aehhr1uD5XSUSjZVA1wsQgNZ6E4TNLHb2y5WP9j I7dPjXuJfp42Qme55K17sJaGtP7Eqc+WemdL091k9eJjPbWoRmVirbeiBLunIU9dra+E WwHeDp2D8uM/m9sCeuPHMfnp28Ax+ET6Csq01INQLA0PX3firR5xFTtGHQWJaClnQlKn 8VSieUxAJ9TxpLPY8qbTM/gsf3kJfNOt2Qi/iVN9swJITU6cqJEHFJfWf2sB2ABBLOml takfpFroaV6ilLH3juKIXv7gyTunuLyqI0CnAR1PG8AidOfOnKVOCq7ViuIEu4Cdn1qb i0EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=ERIg4HHuIsrdX9llKPCiZuj7h2taw5KiOFQQzcP69Mo=; b=X3hda5Gj8RRgilAd8+VYwqtg81oT0aviKkMI4IF+aCfMcDWa64mnRzuEBCUWQ3Nt3T nDAo5ihhnV5LwSVZFUcY4FrMRDq7VJDQNa+LT+qb2Jb30ariHtQq2pgHFYErQRrIgUZF nh5WOPimy6p57Wz++oIYUPNhQ49upwGlekDi0ByihFa/H45ql3rHRBU0e9yi0cNP5u8P vcKK9CN/J0xCBsByffhUiVr/UWXHjGypAf9oT3bykKZmVC/b2zEXYs6vM3LHwagRlGsH ydDP1ZJuOACiAzqvRUgOOYeEA/siQf2waIQ9dnwEKCfFOEN8X2XMH4CSAW+BK6roTpPX U15g== X-Gm-Message-State: AOPr4FVqV/wR1Z8xY3d/MyFS5jR0SiAf1VhEvcmGXslbxYSlkb2MSN/dqdGC6qLBtoydsQ== X-Received: by 10.28.227.138 with SMTP id a132mr14791108wmh.35.1462135889279; Sun, 01 May 2016 13:51:29 -0700 (PDT) Received: from rimwks ([2001:470:1f15:8e:4056:a363:84fd:84d8]) by smtp.gmail.com with ESMTPSA id jd4sm26166159wjb.43.2016.05.01.13.51.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 13:51:28 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sun, 1 May 2016 23:51:27 +0300 To: , Rozhuk Ivan Subject: some clang AVX instricts looks broken Message-ID: <20160501235127.451d8812@rimwks> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 20:51:31 -0000 Hi! I try port some SSE code to AVX and found that clang instricts _mm256_extract* broken: _mm256_extract_epi8(__aymm0, 0) - BAD result _mm256_extract_epi8(__aymm0, 0) & 0xff - OK _mm_extract_epi8(_mm256_extractf128_si256(__aymm0, 0), 0) - OK Same time: _mm256_extract_epi8(__aymm0, 0) build with GCC - OK. CLANG: static __inline int __attribute__((__always_inline__, __nodebug__)) _mm256_extract_epi8(__m256i __a, int const __imm) { __v32qi __b = (__v32qi)__a; return __b[__imm & 31]; } GCC: extern __inline int __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm256_extract_epi8 (__m256i const __X, int const __N) { __m128i __Y = _mm256_extractf128_si256 (__X, __N >> 4); return _mm_extract_epi8 (__Y, __N % 16); } From owner-freebsd-hackers@freebsd.org Sun May 1 23:51:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB9DCB29B7F for ; Sun, 1 May 2016 23:51:21 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 99C1A1DD7 for ; Sun, 1 May 2016 23:51:21 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: by mail-pf0-x22e.google.com with SMTP id c189so73125591pfb.3 for ; Sun, 01 May 2016 16:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pathscale-com.20150623.gappssmtp.com; s=20150623; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=wfSG6R5S0pa6J2f2vL8mUBwMGzJVbmA8YHHdlVuv2lc=; b=cGa9Z2d/08tBILZZmP39aFdH1uYCv5ZZlaSg8oCeEyn7GMN8YUYToTBq5hZWbEftXB Ukf+ednaKi6ly6KeGqJzGY+DRGcSzOaUnvA87favtsJhyKi6hwuebQCI64EbHVdf+A9Z 5NLGcROvHW9uCc2/3nf5nltQeIrQ18lk8508ey0Z7xelg78t4UPLm/ylaAjGnuMQ9BMp GgHaOcGTVtBVIiIZuWQEOPD8FYwdlwmb657bPdbrJuIRS3qbIUT7C+EvfwG4otq+ml4n jxxa6wTZ8yGA+PQ9iLe4RrNqJLoc//16o15jAIXT0tYaeNOZ2AmY0Zh9bNMZI2p0CAel xACg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=wfSG6R5S0pa6J2f2vL8mUBwMGzJVbmA8YHHdlVuv2lc=; b=dqStB1e9huhGRNwlxy9T86dpVXVBqCILxdqpMhub+A7pkly3VYENm7EkOFA94h6rP6 WAHq898SwqmHmGcFB45o+zTxuEQ8q6sV7CI9ElEV2xgigkNd8cWedwy6RrgQFvwm0vLE omFaEjXiAki8asAqthK7VUCwoXUYYqzd6K/pPubFQgzGPTuqf8Bu6kqk6TvWogkAeiI1 6Xiel4LPP5kO6YBnqkfZdeELieSOkl2SS+CfPKh4aLHKgpjavGdX6hzjzOsaqlyPNlcO Bni/c4T4whXmE8zgAMhfmiAkVDrYgb6yhBCKSZYxNAB09yADZKFgP1hBocZEcZlLnG3f YN0A== X-Gm-Message-State: AOPr4FUrYmYycOvbgz2+go+SKO2//nexr9s/Y4+UhEsVScFqmqMePWXR3zpKOk2t23YwHQ== X-Received: by 10.98.18.195 with SMTP id 64mr47682152pfs.152.1462146680971; Sun, 01 May 2016 16:51:20 -0700 (PDT) Received: from [127.0.0.1] ([183.90.37.249]) by smtp.gmail.com with ESMTPSA id s26sm40030170pfa.0.2016.05.01.16.51.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 16:51:20 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160501235110.5480531.91284.93547@pathscale.com> Date: Mon, 02 May 2016 07:51:10 +0800 Subject: Re: some clang AVX instricts looks broken From: cbergstrom@pathscale.com In-Reply-To: <20160501235127.451d8812@rimwks> References: <20160501235127.451d8812@rimwks> To: Rozhuk Ivan , freebsd-hackers@freebsd.org, Rozhuk Ivan X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 23:51:21 -0000 I doubt this is fbsd specific? Wouldn't it be better to report this to clan= g upstream? =A0 Original Message =A0 From: Rozhuk Ivan Sent: Monday, May 2, 2016 04:51 To: freebsd-hackers@freebsd.org; Rozhuk Ivan Subject: some clang AVX instricts looks broken Hi! I try port some SSE code to AVX and found that clang instricts _mm256_extra= ct* broken: _mm256_extract_epi8(__aymm0, 0) - BAD result _mm256_extract_epi8(__aymm0, 0) & 0xff - OK _mm_extract_epi8(_mm256_extractf128_si256(__aymm0, 0), 0) - OK Same time: _mm256_extract_epi8(__aymm0, 0) build with GCC - OK. CLANG: static __inline int __attribute__((__always_inline__, __nodebug__)) _mm256_extract_epi8(__m256i __a, int const __imm) { __v32qi __b =3D (__v32qi)__a; return __b[__imm & 31]; } GCC: extern __inline int __attribute__((__gnu_inline__, __always_inline__, __art= ificial__))=20 _mm256_extract_epi8 (__m256i const __X, int const __N)=20 {=20 __m128i __Y =3D _mm256_extractf128_si256 (__X, __N >> 4);=20 return _mm_extract_epi8 (__Y, __N % 16);=20 } _______________________________________________ freebsd-hackers@freebsd.org mailing list https://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 May 2 00:00:58 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBFEEAD90B0 for ; Mon, 2 May 2016 00:00:58 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 7489811A3 for ; Mon, 2 May 2016 00:00:58 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id a17so118701055wme.0 for ; Sun, 01 May 2016 17:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7tlu72vZHYnukyyfi3Zj1fXF1HvQ2G4IyNtyN8uUiio=; b=MvApClHDuVi5g5/E8VrgTTrc2gjb56lUyScVQv2A/AcLGLVDZgJJTu8TcNSp/t/suI bI/vGFtrYFBSvYF80Tb/q6sXerOvWW6IpBp0R7pQ4usRTf4B1ku9pjZMHm6Hu0SIn2sl MUlYILhnu7//gErLVVO8p81DcMSk0XpHjXtETLcq+yUBHrcUNQ3UWaGX9HqtH/4j2000 fHdINrEo9n9Ji2RPOREHPofTYYDl50kuk8stim/1+SZtEaDQBKlqjQytuKHVeGpDPW2O JB36bkgfdrKrUbJG1ftPy+x+JmbXIoiuQQmMlZhEcZk8Gg0AVtqco9+9gKFqN4yUBv3u fN3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7tlu72vZHYnukyyfi3Zj1fXF1HvQ2G4IyNtyN8uUiio=; b=bDZfbYX+nbD46sf7KjABzPhBwDVKQppkfmLBPBPTbNBekuKnSkhv/1vkXcusnrIAnt +BHlsAmK6W5g+npZXZQwXMCs+nSG2ZsIXmD7qi8GM+qvTHQR/JhiARi98ymWJHmPQuNr xXWKCUSJfUGXRzB2KHDkXNvZvOLs6FwRsDxL95IrQqeCZjX2dwBdlf/F/5SKP7zhLfBs GjbaxdBsE8zZyqIgoBwD1gjevZbwuPtHJVBz0ZCSKV9J1MXbFGYh81oYsQlmyupk8CmH QLmAopFitwjycFpErL9i8oCZ8AVxSINaO4rpEhm/YBDxGdl4FRuUe3AqWxzRoIfJTyGW tLCg== X-Gm-Message-State: AOPr4FV3F0nTU/QHTb+ZgalVtzC+VqPkeZKkPZizaymyQ+Xmiyx2ACt2+90c/HZA8Ye72g== X-Received: by 10.28.21.75 with SMTP id 72mr15111681wmv.64.1462147256611; Sun, 01 May 2016 17:00:56 -0700 (PDT) Received: from rimwks ([2001:470:1f15:8e:dc71:160d:4ab2:39ad]) by smtp.gmail.com with ESMTPSA id us3sm27222695wjc.41.2016.05.01.17.00.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 17:00:55 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Mon, 2 May 2016 03:00:54 +0300 To: cbergstrom@pathscale.com Cc: freebsd-hackers@freebsd.org Subject: Re: some clang AVX instricts looks broken Message-ID: <20160502030054.3a9ac617@rimwks> In-Reply-To: <20160501235110.5480531.91284.93547@pathscale.com> References: <20160501235127.451d8812@rimwks> <20160501235110.5480531.91284.93547@pathscale.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 00:00:59 -0000 On Mon, 02 May 2016 07:51:10 +0800 cbergstrom@pathscale.com wrote: > I doubt this is fbsd specific? Wouldn't it be better to report this > to clang upstream? Done: https://llvm.org/bugs/show_bug.cgi?id=27594 From owner-freebsd-hackers@freebsd.org Mon May 2 00:49:09 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51201AD9CF9; Mon, 2 May 2016 00:49:09 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC8B1959; Mon, 2 May 2016 00:49:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u420n8mm088729 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 May 2016 18:49:08 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u420n83s088726; Sun, 1 May 2016 18:49:08 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 1 May 2016 18:49:08 -0600 (MDT) From: Warren Block To: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 01 May 2016 18:49:08 -0600 (MDT) Content-Type: text/plain; FORMAT=flowed; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 00:49:09 -0000 Introduction The first quarter of 2016 showed that FreeBSD retains a strong sense of ipseity. Improvements were pervasive, lending credence to the concept of meliorism. Panegyrics are relatively scarce, but not for lack of need. Perhaps this missive might serve that function in some infinitesimal way. There was propagation, reformation, randomization, accumulation, emulation, transmogrification, debuggenation, and metaphrasal during this quarter. In the financioartistic arena, pork snout futures narrowly edged out pointilism, while parietal art remained fixed. In all, a discomfiture of abundance. View the rubrics below, and marvel at their profusion and magnitude! Marvel! --Warren Block __________________________________________________________________ Please submit status reports for the second quarter of 2016 by July 7. A thesaurus will be provided for submitters who do not have one of their own. We will need them back afterwards, preferably with no new teeth marks on the covers. Thank you! __________________________________________________________________ FreeBSD Team Reports * Cluster Admin * The FreeBSD Core Team Projects * Address Space Layout Randomization * Ceph on FreeBSD * Process-Shared Locks for libthr * RCTL Disk IO Limits * The Graphics Stack on FreeBSD Kernel * ARM Allwinner SoC Support * CAM I/O Scheduler * FDT Overlay Support in UBLDR * Filemon Performance/Stability Improvements * FreeBSD Integration Services (BIS) * Infiniband * MMC Stack Under CAM Framework * NFS Server * Static Analysis of the FreeBSD Kernel with PVS Studio Architectures * AmigaOne X5000 Support * FreeBSD on Cavium ThunderX (arm64) * powerpcspe Target Userland Programs * ELF Tool Chain Tools * Native PCI-express HotPlug * Updates to GDB * Using lld, the LLVM Linker, to Link FreeBSD Ports * GitLab Port * GNOME on FreeBSD * KDE on FreeBSD * Obsoleting Rails 3 * Ports Collection Documentation * New FreeBSD Mastery Books * Spanish FAQ and Chinese Porter's Handbook Translations Miscellaneous * FreeBSD Build * Qt 5.6 on Raspberry Pi * The FreeBSD Foundation __________________________________________________________________ FreeBSD Team Reports Cluster Admin Contact: This quarter, we: * migrated services out of the hosting space in ISC (peter, sbruno) * began migration of services into the RootBSD hosting space (peter, sbruno) * collaborated with the phabricator admin team to migrate to a new and improved host in NYI. (allanjude, peter, sbruno) * installed a new and beefier Jenkins machine (gnn, lwshu, sbruno) * are still looking for more Asian mirrors for pkg, svn, and ftp (Japan, India). (sbruno) * completed the migration of the Taiwanese mirror to its new location. (lwshu) * started hosting a clang/llvm buildbbot in the FreeBSD cluster at NYI (sbruno, emaste) * resolved a UK mirror outage with Bytemark (gavin, peter) __________________________________________________________________ The FreeBSD Core Team Contact: FreeBSD Core Team During the first quarter of 2016, the most important business of the FreeBSD Core Team has been to respond to the harassment incident last year. Core's actions were to assemble a timeline of the events and in the light of that to review Core's actions at the time; and to make recommendations about how better to handle such cases in future. During this process, draft reports were reviewed by people concerned in the case and in addition a number of interested members of the FreeBSD community. Core would like to thank everyone involved for their contributions. The report was published to the FreeBSD developer community in mid-February, and contained six recommendations for the community to consider. Core is also coordinating with the committee headed by Anne Dickison who are reviewing the Code of Conduct. A corpus of case studies is being assembled, which will be re-examined to see what impact changes to the Code of Conduct would have had. Core, together with John Baldwin, are working on a plan to create a separate repository containing GPLv3 toolchain components. This will allow modernization of code within base beyond what the existing GPLv2 toolchain can handle, and permit support of certain new architectures where a copyfree licensed alternative (i.e., LLVM) is not yet available. A position paper will soon be circulated to developers for comment. During this quarter three new commit bits were issued, and one was returned for safekeeping. Please welcome Wojciech Macek, Jared McNeil and Stanislav Galabov, and bid farewell to Davide Italiano, who although too busy to work on FreeBSD directly, will still be contributing through his work upstream on lld and other parts of the toolchain. __________________________________________________________________ Projects Address Space Layout Randomization Links Patch Home URL: https://kib.kiev.ua/kib/aslr paxtest.log URL: https://www.kib.kiev.ua/kib/aslr/paxtest.log fedora.log URL: https://www.kib.kiev.ua/kib/aslr/fedora.log Contact: Konstantin Belousov Contact: Ed Maste I wrote a small and straightforward yet feature-packed patch to implement ASLR for FreeBSD which is now available for broader testing. With this change, randomization is applied to all non-fixed mappings. By randomization, I mean that the base address for the mapping is selected with a guaranteed amount of entropy (bits). If the mapping was requested to be superpage aligned, the randomization honors the superpage attributes. The randomization is done on a best-effort basis. That is, the allocator falls back to a first fit strategy if fragmentation prevents entropy injection. It is trivial to implement a strong mode where failure to guarantee the requested amount of entropy results in failure of the mapping request failure, but I do not consider that to be usable. I have not fine-tuned the amount of entropy injected right now, but that is only a quantitive change that will not change the implementation. The current amount is controlled by aslr_pages_rnd. To not spoil coalescing optimizations, to reduce the page table fragmentation inherent to ASLR, and to retain transient superpage promotion for malloced memory, locality is implemented for anonymous private mappings, which are automatically grouped until fragmentation kicks in. The initial location for the anon group range is, of course, randomized. After some additional tuning, the measures appeared to be quite effective. In particular, a very address-space-hungry build of PyPy 5.0 on i386 successfully finished with the most aggressive functionality of the patch activated. The default mode keeps the sbrk area unpopulated by other mappings, but this can be turned off, which gives much more breathing room on the small address-space architectures (it is funny that 32 bits is now considered small). This is tied with the question of following an application's hint about the mmap(2) base address. Testing shows that ignoring the hint does not affect the function of common applications, but I would expect that more demanding code could break. By default sbrk is preserved and mmap hints are satisfied, which can be changed by using the kern.elf{32,64}.aslr_care_sbrk sysctls (currently enabled by default for wider testing). Stack gap, W^X, shared page randomization, KASLR and other techniques are explicitly out of scope for this work. The paxtest results for the run with the previous version 5 of the patch applied and aggressively tuned can be seen at paxtest.log. For comparison, a run on Fedora 23 on the same machine is at fedora.log. ASLR is enabled on a per-ABI basis, and currently is only enabled on native i386 and amd64 (including compat 32-bit) and ARMv6 ABIs. I expect to test and enable ASLR for arm64 as well, later. A procctl(2) control for ASLR is implemented, but I have not provided a userspace wrapper around the syscall. In fact, the most reasonable control needed is per-image and not per-process, but we have no tradition to put the kernel-read attributes into the extattrs of a binary, so I am still pondering that part and this also explains the non-written tool. Thanks to Oliver Pinter and Shawn Webb of the HardenedBSD project for pursuing ASLR for FreeBSD. Although this work is not based on theirs, it was inspired by their efforts. Thanks to Ed Maste, Robert Watson, John Baldwin, and Alan Cox for some discussions about the patch, and for The FreeBSD Foundation for directing me. Bartek Rutkowski tested PyPy builds on i386, and David Naylor helped with the port which was at the point of turbulence and upgrade during the work. This project was sponsored by The FreeBSD Foundation. __________________________________________________________________ Ceph on FreeBSD Links Ceph Main Site URL: http://ceph.com Main Repository URL: https://github.com/ceph/ceph My Fork URL: https://github.com/wjwithagen/ceph The git pull with All Changes URL: https://github.com/ceph/ceph/pull/7573 Contact: Willem Jan Withagen Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface that is compatible with applications written for S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system that aims for high performance, large data storage, and maximum compatibility with legacy applications. I started looking into Ceph, because the HAST solution with CARP and ggate did not really do what I wanted. But I am aiming for running a Ceph storage cluster of storage nodes that are running ZFS. The end station would be running bhyve on RBD disk that are stored in Ceph. The FreeBSD build will build most of the tools in Ceph. Note that the RBD-dependent items will not work since FreeBSD does not have RBD yet. Compiling and building Ceph is tested on 11-CURRENT. It uses the Clang toolset that is available, which needs to be at least 3.7. Clang 3.4 (on 10.2-STABLE) does not have all the required capabilities to compile everything. This setup will get things running for FreeBSD: * Install bash and link it in /bin (requires root privileges): sudo pkg install bash sudo ln -s /usr/local/bin/bash /bin/bash * Building Ceph git clone https://github.com/wjwithagen/ceph.git cd ceph git checkout wip-wjw-freebsd-tests ./do_freebsd.sh Parts Not Yet Included: * RBD Rados Block Devices is implemented in the Linux kernel. It seems that there used to be a userspace implementation first. And perhaps ggated could be used as a template since it does some of the same functions, other than just between two disks. And it has a userspace counterpart. * BlueStore FreeBSD and Linux have a different AIO API, and that needs to be made compatible. Next to that is the discussion in FreeBSD about aio_cancel not working for all device types. * CephFS Cython tries to access an internal field in dirent which does not compile. Tests that verify the correct working of the above are also excluded from the test set. Tests Not Yet Included: * ceph-detect-init/run-tox.sh Because the current implementation does not know anything about FreeBSD's rc/init. * Tests that make use of nosestests Calling these does not really work since nosetests is not in /usr/bin, and calling through /usr/bin/env nosetests does not work on FreeBSD. * test/pybind/test_ceph_argparse.py * test/pybind/test_ceph_daemon.py Things To Investigate: * ceph-{osd,mon} need two signals before they actually terminate. * ceph_erasure_code --debug-osd 20 --plugin_exists jerasure crashes due to SIGSEGV. This is a pointer reference that gets modified outside the regular programflow. Probably due to a programming error but perhaps wrong mixing and matching of many libraries. Open tasks: 1. The current and foremost task is to get the test set to complete without errors. This includes fixing several coredumps. Run integration tests to see if the FreeBSD daemons will work with a Linux Ceph platform. 2. Get the Python tests that are currently excluded to work, and test OKE. 3. Compile and test the user space RBD (Rados Block Device). Investigate and see if an in-kernel RBD device could be developed akin to ggate. 4. Integrate the FreeBSD /etc/rc.d init scripts in the Ceph stack for testing and running Ceph on production machines. __________________________________________________________________ Process-Shared Locks for libthr Contact: Konstantin Belousov POSIX specifies several kinds of pthread locks. For this report, the private and process-shared variants are considered. Private locks can be used only by the threads of the same process, which share a single common address space. Process-shared locks can be used by threads from any process, assuming the process can map the lock memory into its address space. Our libthr, the library implementing the POSIX threads and locking operations, uses a pointer as the internal representation behind a lock. The pointer contains the address of the actual structure carrying the lock. This has unfortunate consequences for implementing the PTHREAD_PROCESS_SHARED attribute for locks, since really only the pointer is shared when a lock is mapped into distinct address spaces. A common opinion was that we have no choice but to break the libthr Application Binary Interface (ABI) by changing the lock types to be the actual lock structures (and padding for future ABI extension). This is very painful for users, as our previous experience with non-versioned libc and libc_r has shown. Instead, I proposed and implemented a scheme where process-shared locks can be implemented without breaking the ABI. The lock memory is used as a key into a system-global hash of shared memory objects (off-pages), which contain the actual lock structures. New umtx operations to create or look up a shared object by memory key were added. libthr is modified to look up the object and use it for shared locks, instead of using malloc() as for private locks. The pointer value in the user-visible lock type contains a canary for shared locks. libthr detects the canary and switches into the shared-lock mode. The proposal of inlining the lock structures, besides the drawbacks of breaking ABI, has its merits. Most important, the inlining avoids the need for indirection. Another important advantage over the off-page approach is that no off-page object needs to be maintained, and the lifecycle of the shared lock naturally finishes with the destruction of the shared memory, without need for explicit cleanup. Right now, off-pages hook into vm object termination to avoid leakage, but long-livedness of the vnode vm object prolongs the off-page's existence for shared locks backed by files, however unlikely they may be. libthr with inlined locks became informally known as the libthr2 project, since it is better to change the library name than just bumping the library version. rtld should ensure that libthr and libthr2 are not simultaneously loaded into a single address space. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Implement robust mutexes. 2. Evaluate and implement libthr2. __________________________________________________________________ RCTL Disk IO Limits Contact: Edward Tomasz Napierała An important missing piece of the RCTL resource limits framework was the ability to limit file system throughput. This project aims to fill that hole by making it possible to add RCTL rules for read bytes per second (BPS), write BPS, read I/O operations per second (IOPS), and write IOPS, and adding a new throttling mechanism to slow down offending processes when a limit gets hit. The code has been committed and will ship with FreeBSD 11.0-RELEASE. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Additional testing 2. Simplify locking, getting rid of rctl_lock altogether 3. Improve statistics gathering by making it possible for rctl -u to retrieve usage counters at a fixed point in time 4. Use the new throttling mechanism for %CPU limits __________________________________________________________________ The Graphics Stack on FreeBSD Links Graphics Stack Roadmap and Supported Hardware Matrix URL: https://wiki.freebsd.org/Graphics Ports Development Tree on GitHub URL: https://github.com/freebsd/freebsd-ports-graphics FreeBSD Graphics Team at FOSDEM 2016 URL: https://fosdem.org/2016/schedule/event/freebsd_graphic_stack/ GSoC 2016: link /dev Entries to sysctl Nodes URL: https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes GSoC 2016: Redesign libdevq URL: https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_redesign_and_rewrite_libdevq Graphics Team Blog URL: http://planet.freebsd.org/graphics/ Contact: FreeBSD Graphics team The major news for this quarter is the update of the i915 driver in the kernel! The driver now matches Linux 3.8.13, so it includes initial Haswell support. Linux 3.8 is already three years old, but work continues to upgrade DRM further. In particular, work commenced to move to using the linuxkpi compatibility. In the Ports tree, Mesa was updated to 11.1.2. The next minor release, 11.2.0, is ready for testing in our development tree. We also updated libclc to 0.2.0.20151006, a library used by Mesa to provide OpenCL support. Upstream patches were added to beignet so all these ports now use the same LLVM version. We attended FOSDEM 2016 in Brussels. Jean-Sébastien Pédron gave a talk to explain the work of the graphics team and show how people can contribute. It was well received and the presentation was followed by interesting discussions. FOSDEM was also a nice occasion to meet and talk again to the nice upstream developers of the graphics stack. For the first year, we added two ideas for GSoC 2016: one for a kernel task, one to redesign libdevq. Six students submitted proposals for those ideas; that was unexpected! We now need to decide which one we want to mentor and the choice is difficult. Our blog has moved to a new location (linked above). Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Kernel ARM Allwinner SoC Support Links Allwinner FreeBSD Wiki URL: https://wiki.freebsd.org/FreeBSD/arm/Allwinner Contact: Jared McNeill Contact: Emmanuel Vadot Allwinner SoCs are used in multiple hobbyist devboards and single-board computers. Recently, support for these SoCs has received a lot of updates Task done during first quarter: * I2C * HDMI output * Basic AXP209 support (Power Management Unit) * Switch to upstream DTS for most boards * Basic Support for A31/A31S SoC * RTC * Proper Pinmux/GPIO support * Audio Codec / Audio HDMI * A10/A20 DMA support * A20 now uses the GIC (General Interrupt Controller) * A20 now uses the ARM Generic Timer Ongoing tasks: * Switch to a new clock framework (In review) * Convert the A10 interrupt controller to INTRNG (In review) * OHCI support (In review) * Generic ALLWINNER kernel config file (In review) * A20/A31 NMI support (In review) * USB OTG * Finish the switch to using upstream DTS files * A83T SoC Support * H3 SoC Support Open tasks: 1. SPI driver 2. LCD Support 3. Any unsupported hardware device that might be of interest. __________________________________________________________________ CAM I/O Scheduler Links I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL: https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU Contact: Warner Losh An enhanced CAM I/O scheduler has been committed to the tree. By default, this scheduler implements the old behavior. In addition, an advanced adaptive scheduler is available. Along with the scheduler, SATA disks can now use Queued Trims with devices that support them. Details about the new scheduler are available in the I/O Scheduling in FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk. The adaptive I/O scheduler is disabled by default, but can be enabled with options CAM_ADAPTIVE_IOSCHED in the kernel config file. This scheduler allows favoring reads over writes (or vice versa), controlling the IOPs, bandwidth, or concurrent operations (read, write, trim), and permits the selection of static or dynamic control of these operations. In addition, a number of statistics are collected for drive operations that are published via sysctl. One advanced use for the adaptive I/O scheduler is to compensate for deficiencies in some consumer-grade SSDs. These SSDs exhibit a performance cliff if too much data is written to them too quickly due to internal garbage collection. Without the I/O scheduler, read and write performance drop substantially once garbage collection kicks in. The adaptive I/O scheduler can be configured to monitor read latency. As read latency climbs, the I/O scheduler reduces the allowed write throughput, within limits, to attempt to maximize read performance. A simple use of the adaptive I/O scheduler would be to limit write bandwidth, IOPs or concurrent operations statically. Future work on the I/O scheduler will be coupled with improvements to the upper layers. The upper layers will be enhanced to communicate how urgent I/O requests are. The I/O scheduler will inform the upper layers of how full the I/O queues are, so less urgent I/O can be submitted to the lower layers as quickly as possible without overwhelming the lower layers or starving other devices of requests. This project was sponsored by Netflix. __________________________________________________________________ FDT Overlay Support in UBLDR Links ubldr Patch URL: https://reviews.freebsd.org/D3180 Contact: Oleksandr Tymoshenko A flattened device tree is a way to keep the hardware description separated from code. During the boot process, the loader passes a pointer to the device-tree blob to the kernel and the kernel instantiates and attaches drivers according to the information in the blob. This approach does not work when the hardware is expandable. For example, the Raspberry Pi and Beaglebone Black have the concept of capes or shields: snap-on PCBs that are connected to IO headers on the main board and provide additional functionality like an LCD screen or GPS receiver. These shields can be described by their own device trees and these trees can be overlaid on the base tree by the boot loader, thus providing an accurate description to the kernel. The proposed patch adds this functionality to ubldr. The user can specify a comma-separated list of overlays to U-Boot or the loader fdt_overlays variable and ubldr will load them from the /boot/dtb/ directory and do the overlaying. __________________________________________________________________ Filemon Performance/Stability Improvements Contact: Bryan Drewery Contact: Mateusz Guzik Filemon is a kernel module for tracing which files a command creates, reads, writes, or executes. It allows tracking build dependencies in combination with bmake's meta mode. bmake stores filemon's output in a .meta file along with the build command and later uses this to trigger a rebuild of the target if any of the files referenced are missing or modified, or if the build command changes. It provides the same functionality as the compiler's -MF flag, but for everything. It will be critical for buildworld's WITH_META_MODE (which is the normal buildworld but only using filemon) to provide a reliable incremental build without even the need for .depend files or compiler -MF flags. This allows -DNO_CLEAN to work all of the time. Filemon on -HEAD was improved for stability and performance over this quarter. It no longer causes every syscall it hooks into to loop over processes looking for a matching filemon struct. It now just attaches directly to the struct proc with its own pointer. This improves performance by reducing lock contention during a build. Much other work went into improving error handling and other stability issues in the module as well. All of this work was done by Bryan Drewery, sponsored by EMC, but much help and identification of bugs was provided by Mateusz Guzik. This project was sponsored by EMC / Isilon Storage Division. Open tasks: 1. Improve credential handling. 2. Improve EVENTHANDLER performance. 3. Possibly provide a framework for syscallenter/syscallret hooking to avoid the need to hook syscalls as Filemon does. __________________________________________________________________ FreeBSD Integration Services (BIS) Links FreeBSD Virtual Machines on Microsoft Hyper-V URL: https://wiki.FreeBSD.org/HyperV Supported Linux and FreeBSD Virtual Machines for Hyper-V on Windows URL: https://technet.microsoft.com/en-us/library/dn531030.aspx Contact: Sepherosa Ziehau Contact: Howard Su Contact: Hongjiang Zhang Contact: Dexuan Cui When FreeBSD virtual machines (VMs) run on Hyper-V, using Hyper-V synthetic devices is recommended to get the best network and storage performance and make full use of all the benefits that Hyper-V provides. The collection of drivers that are required to use Hyper-V synthetic devices in FreeBSD are known as FreeBSD Integration Services (BIS). Some of the BIS drivers (like network and storage drivers) have existed in FreeBSD 9.x and 10.x for years, but there are still some performance and stability issues and bugs. Compared with Windows and Linux VMs, the current BIS lacks some useful features, e.g., live virtual machine backup, TRIM/Unmap, the support for UEFI VMs (boot from UEFI), etc. During the past quarter, we made a great progress on the performance tuning for Hyper-V network driver. We also refactored and cleaned up the VMBus driver, and fixed some important bugs. All the work makes FreeBSD VMs run even better on Hyper-V and the Hyper-V based cloud platform Azure! Our work during 2016Q1 is documented below: Optimizing the performance of Hyper-V network driver: * We added LRO (Large Receive Offloading) support to the driver and properly handle ACK packets. This effectively reduces the CPU cycles used in the TCP/IP stack and dramatically boosts network performance! * We enabled vRSS (virtual Receive Side Scaling) support for the driver. This greatly improved the network performance for SMP virtual machines. * We used a separate Tx kernel thread to relieve the Rx thread of transmitting packets (the Rx thread tried to transmit packets after receiving ACKs), so the Rx thread can receive packets and send ACKs faster. * Now we can reach a VM-to-VM throughput of 9.1Gbps on a host with a 10Gbps physical NIC, and over 20Gbps on a host with a 40Gbps NIC, all the while with plenty of CPU cycles left for applications. * We also enabled IP header checksum offloading, and Rx checksum offloading for UDP. * Further performance tuning is working in progress. Refactoring and cleaning up the VMBus driver code: * Instead of using swi threads directly, we now use per-CPU taskqueue_create_fast() threads for event and message handling, making the code more conventional for FreeBSD. * We did a lot of cleanup to the hv_utils code (HeartBeat, TimeSync and Shutdown) and we are further cleaning up the KVP code. * We used a new message/interrupt slot for the Hyper-V timer, so the handling of timer and non-timer messages can be distinguished, fixing a potential issue. * Instead of finding an available IDT vector by hacking, we are changing to use the normal method, lapic_ipi_alloc(). * We are modularizing the Hyper-V modules: 1. they will be loaded in the loader; 2. we are going to enhance devd(8) to improve the hot plug case. Bug Fixing: * Fixed the "spurious multiple disks" issue (PR 206630 -- FreeBSD 10.2 on Windows 10 and 2016 server may not boot due to multiple invalid disks) in the Hyper-V storage driver and now FreeBSD VMs can reliably boot on Win10 and 2016 hosts. * Fixed the OACTIVE issue (PR 207297 -- [Hyper-V] FreeBSD 10.2 on hyperv lost network under heavy load for OACTIVE). * Fixed a TSC calibration issue (PR 208238 -- [Hyper-V] TSC frequency is not correctly detected: "calcru: runtime went backwards") and we will not see the "runtime went backwards" messages any more! * Fixed the "very slow terminal" issue of 11-CURRENT by enabling text mode when we are running on hypervisors. * Fixed the "unknown dhcp option value 0xf5" issue in dhclient(8) by asking dhclient(8) to ignore the option, and FreeBSD VMs on Azure can now reliably get IP addresses. * Found a workaround for PR 20824 ([Hyper-V] VM network may not work over virtual switch based on wireless NIC): add "net.link.ether.inet.max_age=60" in /etc/sysctl.conf. We plan to add support for live virtual machine backup, TRIM/Unmap, and UEFI VMs (Hyper-V Generation-2 VMs). We published errata (FreeBSD-EN-16:04.hyperv, FreeBSD-EN-16:05.hv_netvsc) with the Release Engineering team, so 10.1 and 10.2 users can easily get the fixes for KVP and TCP checksums by upgrading the system. We published BIS test cases for Hyper-V on github: https://github.com/FreeBSDonHyper-V/Test-BIS and we are going to publish the test cases for Azure soon. This project was sponsored by Microsoft. __________________________________________________________________ Infiniband Links Call for Testing URL: https://lists.freebsd.org/pipermail/freebsd-infiniband/2016-March/000190.html Contact: Hans Petter Selasky Mellanox is working on a big infiniband update towards Mellanox OFED v3.2 of the infiniband stack in FreeBSD. The updates include both userland and kernel components. Infiniband patches for FreeBSD are available in the link above which can be downloaded and applied to a recent FreeBSD-head checkout. This project was sponsored by Mellanox Technologies. __________________________________________________________________ MMC Stack Under CAM Framework Links Project Information URL: https://bakulin.de/freebsd/mmccam.html Source Code URL: https://github.com/kibab/FreeBSD/tree/mmccam Patch for Review URL: https://reviews.FreeBSD.org/D4761 Contact: Ilya Bakulin The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debugging features. It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface. SDIO support is necessary for communicating with the WiFi/BT modules found on many development boards, like Wan Raspberry Pi 3. Another feature that the new stack will have is support for sending SD commands from userland applications using cam(3). This will allow for building device drivers in userland and make debugging much easier. The first version of the code was uploaded to Phabricator for review. The new stack is able to attach to the SD card and bring it to an operational state so it is possible to read and write to the card. Support for the imx_sdhci SD Host Controller (used on iMX-based boards, for example Wandboard) was added in 2016Q1, along with ti_sdhci, which is used on the BeagleBone Black. Modifying other SDHCI-compliant drivers should not be difficult. Open tasks: 1. Modify the SDHCI driver on at least one x86 platform. This will make development and collaboration easier. 2. Begin implementing SDIO-specific bits. __________________________________________________________________ NFS Server Contact: Rick Macklem A new -manage-gids option was added to the nfsuserd daemon. This option tells the NFS server to use the list of groups for a uid on the server and not the list of groups in the NFS RPC request. Use of this option avoids the 16 group limit for NFS RPCs using AUTH_SYS (the default). Work is ongoing with respect to development of pNFS support for the NFS server using GlusterFS as a back end. This will be a long-term project with the eventual goal of allowing the NFS server to scale beyond a single server system. Hopefully it will be available for testing in late Spring 2016. pNFS allows an NFSv4.1 client to do reads/writes directly to a data server and not the NFS server. Open tasks: 1. The pNFS server will be in need of testing during development or it will never progress to a near-production status. I hope to have code available in FreeBSD's Subversion project branch for testing in late spring 2016. __________________________________________________________________ Static Analysis of the FreeBSD Kernel with PVS Studio Links PVS-Studio Delved into the FreeBSD Kernel URL: http://www.viva64.com/en/b/0377/ PVS Static Analysis Phabricator Review URL: https://reviews.freebsd.org/D5245 Contact: Warren Block In February, Program Verification Systems used their PVS-Studio tool to run a static analysis of the FreeBSD kernel. A Phabricator review was created to allow developers to share comments on the results. A number of bugs ranging from trivial typos to redundant code to important logic errors were found and fixed. Some results were false positives. Several of these were addressed by changing code that misled the static analyzer and could also mislead a human reader. The cooperation that Program Verification Systems offers to open-source projects like FreeBSD benefits everyone. We thank them for sharing this analysis and their insights with us. __________________________________________________________________ Architectures AmigaOne X5000 Support Links URL: http://www.amigaos.net/hardware/133/amigaone-x5000 Contact: Justin Hibbits This project is a continuation of the Book-E QorIQ support enhancements by Semihalf dating back to 2012. The AmigaOne X5000 series of AmigaOS-compatible systems uses the Freescale QorIQ series of SoCs for a desktop-class form factor. The work here entails adding support for the e5500 core itself, in addition to support for the SoC peripherals. Currently, most of the code to enable basic support is checked in: dTSEC (ethernet), core support (e500mc, e5500). As part of this, rman, the kernel resource manager, was enhanced to use uintmax_t for resources. This allows devices to be physically above the 4GB boundary on 32-bit systems. With a statically compiled device tree, it boots to multiuser mode with nfsroot, and can be used as normal (serial and SSH logins once configured). This project was sponsored by Alex Perez (Inertial Computing). Open tasks: 1. eSDHC driver: Work has been started on this, hijacking the imx_sdhc.c from Ian Lepore, but there are still bugs: missing DMA from the iMX driver, and odd timeouts after the system starts up. 2. SATA support: There is a WIP driver for the SATA controller, but it is currently very slow, about 11MB/s on a SATA 2 link. It currently relies on a 10ms delay on every SATA transaction for it to be even somewhat stable. Without this delay, the disk scan never works and I have not yet figured out why. 3. Local console (VGA) support: It currently boots with a serial console. vgapci0 is seen if there is a PCIe graphics card, but vt(4) does not attach to it yet. 4. 64-bit support: The CPU on the board is a P5020, a 64-bit e5500 dual-core SoC. Currently, booke support in FreeBSD is 32-bit only. 5. SMP: SMP support on Book-E hardware is currently broken. 6. U-boot support: Currently this uses a compiled-in device tree, but it would be preferable to use the device tree provided by u-boot, or at least the Linux-compatible device tree. 7. More work is needed on the DPAA front (Datapath Acceleration Architecture) to improve the Ethernet driver and utilize the SEC engine for crypto, random(4), and IPSec. __________________________________________________________________ FreeBSD on Cavium ThunderX (arm64) Contact: Dominik Ermel Contact: Wojciech Macek Contact: Zbigniew Bodek Since the last report, FreeBSD support for ThunderX has been significantly improved and stabilized. Semihalf contributions include the following items: * Support for the newest ThunderX chip revisions (Pass 2.0) and current Cavium firmware. Backward compatibility is maintained. * Moved to using pci_host_generic.c as a main driver for the internal PCIe bridge. This involved a significant rework of PCIe code to support both generic and ThunderX based platforms. * Serious networking performance boost and bug fixes: * Fixed race condition on Rx path causing a very rare "use after free" issue * Hardware L3 and L4 checksums support * Hardware assisted TCP Segmentation Offloading (TSO) * Support for software Large Receive Offload (LRO) * Various improvements to Tx and Rx paths and configuration The driver supports all available Ethernet connections (1, 10, 30 Gbps) and the system can saturate a 10 Gbps link (on Tx) using 4 CPU cores. * Significantly improved overall I/O performance: * Complete rework of copyin/copyout and bzero functionalities Other improvements: * Support for interrupt to CPU binding (including GICv3/ITS backends) This work is integrated to FreeBSD HEAD on an on-going basis. This project was sponsored by Cavium, and Semihalf. Open tasks: 1. Add support for multi-Queue Set operation in VNIC. __________________________________________________________________ powerpcspe Target Links Source Tree URL: https://svnweb.freebsd.org/base/projects/powerpcspe/ Contact: Justin Hibbits This project aims to enable the use of the Signal Processing Engine found in the NXP/Freescale e500v2 SoC. The SPE uses opcodes overlapping with those of Altivec, so they are mutually exclusive. Additionally, the e500v2 does not have a traditional FPU, and instead uses the SPE for all floating point operations (or emulation, as is currently done). Combined with the fact that the SPE ABI is incompatible with the traditional ABI, a new MACHINE_ARCH has been created to address these incompatibilities. A project branch has been created for the work. A powerpcspe kernel boots on the RouterBoard RB800, and the base utilities run properly. Open tasks: 1. Potentially optimizing setjmp/longjmp to not use SPE unless it has already been enabled. This would save the kernel switch for processes that do not otherwise use the SPE. This is a low priority task which may not be completed. __________________________________________________________________ Userland Programs ELF Tool Chain Tools Links ELF Tool Chain Web Site 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. The ELF Tool Chain project released version 0.7.1 in February. We have been tracking snapshots of the upstream repository in FreeBSD. Having an official release brings the benefit of broader testing and visibility within other open source projects, even if we do not require it in order to update FreeBSD. In the first quarter of 2016, the ELF Tool Chain tools were updated to a snapshot of upstream Subversion revision 3400, which is close to the 0.7.1 release. Additional bug fixes were committed to FreeBSD and subsequently merged into the upstream repository. ELF Tool Chain's elfcopy(1) is now installed as objcopy(1) by default, as it is a viable replacement for the base system and ports tree. Significant improvements were made to the elfcopy(1), readelf(1), and elfdump(1) tools, including better MIPS, RISC-V, and AArch64 support. This project was sponsored by The FreeBSD Foundation. Open tasks: 1. Fix issues found by fuzzing inputs to the tools. 2. Add automatic support for separate debug files. 3. Investigate replacement objdump, ld and as implementations. __________________________________________________________________ Native PCI-express HotPlug Links Native PCI-express HotPlug Support URL: https://github.com/bsdjhb/freebsd/tree/pci_hp Contact: John Baldwin A new implementation of support for native PCI-express hotplug is present at the URL above. Much of the new code lives in the PCI-PCI bridge driver to handle hotplug events and manage the PCI-express slot registers. Additional changes in the branch include adding new rescan and delete commands to devctl(8), as well as support for rescanning PCI busses. The current implementation has been tested on systems with ExpressCard slots but could use additional testing, especially on systems with other PCI-express HotPlug features such as mechanical latches, attention buttons, indicators, and so on. Open tasks: 1. Split the branch into separate logical changes as commit candidates. 2. Additional testing. __________________________________________________________________ Updates to GDB Contact: John Baldwin The new thread target that directly uses ptrace(2) was committed upstream and included in GDB 7.11. The port was also updated to GDB 7.11. Open tasks: 1. Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. 2. Add support for more platforms (arm, mips, aarch64) to upstream gdb for both userland and kgdb. 3. Add support for debugging powerpc vector registers. 4. Add support for catching system calls. 5. Add support for $_siginfo. 6. Add support for ELF auxv data via info auxv. 7. Implement info os commands. 8. Implement gdbserver for FreeBSD. __________________________________________________________________ Using lld, the LLVM Linker, to Link FreeBSD Links FreeBSD lld Wiki Page URL: https://wiki.freebsd.org/LLD Status Report on Linking FreeBSD/amd64 with lld URL: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html Contact: Rafael Espíndola Contact: Davide Italiano Contact: Ed Maste lld is the linker in the LLVM family of projects. It is intended to be a high-performance linker and supports the ELF, COFF and Mach-O object formats. Where possible, lld maintains command-line and functional compatibility with existing linkers (GNU BFD ld and gold), but lld's authors are not constrained by strict compatibility where it would hamper performance or desired functionality. The upstream lld project made significant progress in adding new functionality to lld's ELF support over the first quarter of 2016. The lld ELF linker is capable of self-hosting on FreeBSD/amd64 and is capable of linking many test applications. Highlights of upstream development over the quarter include: * lld gained Link Time Optimization (LTO) support and is able to link Clang with LTO * The relocation code has been overhauled for better maintainability * Improvements to linker script support, including better diagnostics * Many bug fixes in x86_64, AArch64, and MIPS support lld currently lacks comprehensive linker script expression evaluation support, and therefore cannot yet be used to link the FreeBSD kernel. It also lacks versioned symbol support, and does not implement some options used in the FreeBSD boot loader components. Ed has been running experimental world builds of FreeBSD/amd64 with lld installed in place of ld.bfd as the linker. With workarounds for the current gaps in functionality (using the WITHOUT_SYMVER option to disable symbol versioning use, and linking the loader components with GNU ld), lld is now able to link a working FreeBSD userland. This project was sponsored in part by The FreeBSD Foundation. Open tasks: 1. Enable the lld option by default in the llvm-devel (and later llvm) ports for testing. 2. Develop symbol version support and linker script expression improvements in the upstream lld project. 3. Add or improve support for the remaining FreeBSD architectures. 4. Import a newer lld snapshot into the vendor area, add build infrastructure and connect it to the world build, installed as ld.lld. 5. Request a ports exp-run with /usr/bin/ld a symlink to ld.lld. 6. Extensive testing. __________________________________________________________________ Ports GitLab Port Contact: Torsten Zühlsdorff After nearly a year of work on this project, GitLab 8.5.5 was committed into the ports tree. A big thanks to the enormous number of people involved! Since GitLab is a fast-moving project, there is also ongoing work to stay in sync with upstream. Have fun! __________________________________________________________________ GNOME on FreeBSD Links FreeBSD GNOME Website URL: http://www.FreeBSD.org/gnome Development Repository URL: https://github.com/FreeBSD/freebsd-ports-gnome Upstream Build Bot URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD USE_GNOME Porter's Handbook Chapter URL: https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/using-gnome.html 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. This quarter, GNOME 3.18 and MATE 1.12 were committed to the ports tree. The bsd.gnome.mk and bsd.mate.mk frameworks were replaced by the simpler Uses/gnome.mk and Uses/mate.mk style. Open tasks: 1. Tracking MATE 1.13, the development version that will become MATE 1.14. 2. Work started on porting GNOME 3.20. 3. We have Cinnamon 2.8 in our development tree, but we do not have the time to properly test and fix the issues before this Cinnamon can be committed to ports. Interested in helping or taking maintainership of Cinnamon? Please let us know. __________________________________________________________________ KDE on FreeBSD Links KDE on FreeBSD Website URL: https://freebsd.kde.org/ Experimental KDE Ports Staging Area URL: https://freebsd.kde.org/area51.php KDE on FreeBSD Wiki URL: https://wiki.FreeBSD.org/KDE KDE/FreeBSD Mailing List URL: https://mail.kde.org/mailman/listinfo/kde-freebsd Development Repository for Integrating KDE Frameworks 5 and Plasma 5 URL: http://src.mouf.net/area51/log/branches/plasma5 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. While the list of updates is shorter than that for the previous quarter, the team remained busy and work on KDE Frameworks 5 and Plasma 5 continues. Tobias Berner, who has been driving our KDE Frameworks 5 and Plasma 5 efforts from the beginning, received a KDE commit bit, and has been putting it to good use by upstreaming FreeBSD across several KDE repositories. Another team highlight in the beginning of this year is the (re)addition of another committer to our experimental repository: Adriaan de Groot, a longtime KDE contributor who also used to work on KDE and FreeBSD almost a decade ago when our team was first formed. Welcome back, Ade! The following big updates were landed in the ports tree this quarter. In many cases, we have also contributed patches to the upstream projects. * CMake 3.4.2 and 3.5.0 * Calligra 2.9.11, the latest release of the integrated work applications suite. We have managed to keep in sync with the upstream releases since 2.9.10. * KDE Telepathy was updated to 0.9.0 and Telepathy-Qt4 was updated to 0.9.6.1, the latest upstream releases. * The Qt 5 ports were finally updated to 5.5.1, which were the latest stable version at the time. * The first commit preparing the groundwork for KDE Frameworks 5 and Plasma 5 was landed to the ports tree. Work on Qt 5.6.0 is under way in our experimental repositories. At the time of this writing, it also contains KDE Frameworks 5.20.0, Plasma 5.6.1, and KDE Applications 16.03.80. Users interested in testing those ports are encouraged to follow the instructions in our website and report their results to our mailing list. Qt5 5.6.0 is in our qt-5.6 branch, and Plasma 5 and the rest is in the plasma5 branch. Open tasks: 1. Land the KDE Frameworks 5 and Plasma 5 ports to the tree. 2. Commit the DigiKam 4.14.0 update currently being worked on in our experimental repository. __________________________________________________________________ Obsoleting Rails 3 Contact: Torsten Zühlsdorff Ruby on Rails is the base for most of the rubygems in the Ports Collection. Currently, versions 3.2 and 4.2 coexist, but since Rails 3.2 is running out of support, the time has come to switch. There is an ongoing progress to remove Rails 3.2 from the ports tree. While many gems already work with the new version, there are some exceptions. For example, www/redmine needs a big update (which is currently being tested) because it depends on gems that depends on Rails 3.2. If you want to help with porting or testing, feel free to contact me or the mailinglist ruby@FreeBSD.org. __________________________________________________________________ Ports Collection Links URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://www.facebook.com/portmgr Contact: Frederic Culot Contact: FreeBSD Ports Management Team As of the end of Q1, the ports tree holds a bit more than 25,000 ports, and the PR count is below 1,900. The activity on the ports tree remains steady, with almost 7,000 commits performed by around 120 active committers. On the problem reports front, the encouraging trend observed during the previous quarter is confirmed, with again a significant increase in the number of PRs fixed during Q1. Indeed, almost 2,400 reports were fixed, which allows us to go below the threshold value of 2,000 open PRs. In Q1, three commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (milki, brian), or on committer's request (mmoll). We had one returning committer (fluffy) who had his commit bit reinstated. Two new developers were granted a ports commit bit (Olivier Cochard-Labbe and Christoph Moench-Tegeder). On the management side, we had the pleasure to welcome miwi back to the portmgr team. On the QA side, 39 exp-runs were performed to validate sensitive updates or cleanups. The most noticeable change might be the removal of the now unneeded ${PORTSDIR} when specifying dependencies in Makefiles (see the /usr/ports/CHANGES entry dated 20160402). Amongst other noticeable changes are the update to ruby 2.3, ruby-gems to 2.5.1, CMake to 3.5.0, clang to 3.8.0-r258968, Qt5 to 5.5.1, Gnome to 3.18, boost to 1.60.0, the update of libc++ in base to 3.8.0 release, and the enabling of LLVM libunwind by default on x86. The CentOS ports were also updated. Some infrastructure changes included the switch from bsd.gnome.mk and bsd.mate.mk to the simpler Uses/gnome.mk and Uses/mate.mk. Some work was also done to improve poudriere builds by reducing dependency calculation and general overheads. Open tasks: 1. We would like to remind everyone that the ports tree is built and run by volunteers, and any help is greatly appreciated. A great amount of effort was spent on the ports front in Q1, which allowed us to decrease the number of pending problem reports significantly, as well as on the ports infrastructure. Many thanks to all who contributed! __________________________________________________________________ Documentation New FreeBSD Mastery Books Links FreeBSD Mastery: Specialty Filesystems URL: https://www.michaelwlucas.com/nonfiction/fmsf FreeBSD Mastery: Advanced ZFS URL: https://www.michaelwlucas.com/nonfiction/fmaz Tilted Windmill Press URL: https://www.tiltedwindmillpress.com/ Contact: Michael Lucas Contact: Allan Jude Two new FreeBSD Mastery books are out: FreeBSD Mastery: Specialty Filesystems by Michael W. Lucas, and the long-awaited FreeBSD Mastery: Advanced ZFS by Lucas and Allan Jude. Both books are available in print and ebook formats now. A bundle containing all the FreeBSD Mastery books is available at a discount from tiltedwindmillpress.com. Open tasks: 1. Write more books! __________________________________________________________________ Spanish FAQ and Chinese Porter's Handbook Translations Links Preguntas Frecuentes para FreeBSD 9.X y 10.X URL: https://www.freebsd.org/doc/es_ES.ISO8859-1/books/faq/ FreeBSD Porter 手冊 URL: https://www.freebsd.org/doc/zh_TW.UTF-8/books/porters-handbook/ FreeBSD Translators Mailing List URL: https://lists.freebsd.org/pipermail/freebsd-translators/ PO Translations URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/po-translations.html FreeBSD Documentation Project Primer for New Contributors URL: https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Contact: Federico Caminiti Contact: Carlos J Puga Medina Contact: Ruey-Cherng Yu Contact: Warren Block Federico Caminiti created an entirely new Spanish translation of the 31,000-word FAQ with editorial help from Carlos J Puga Medina. This landmark accomplishment marks the first use of the new PO translation system to translate an entire book! Ruey-Cherng Yu has begun an ambitious Traditional Chinese (zh_TW) translation of the 64,000-word Porter's Handbook. About half of the strings in the book have been translated so far. Open tasks: 1. Help add and improve translations of FreeBSD documents into Spanish: start of freebsd-translators thread. 2. Help add and improve translations of FreeBSD documents into Chinese or other languages. __________________________________________________________________ Miscellaneous FreeBSD Build Contact: Bryan Drewery Build improvements for buildworld on FreeBSD head continue. Some highlights include: * WITH_FAST_DEPEND was made the default in r296668, and later made the only option in r297434. The new depend code avoids a make depend tree walk and generates .depend files during the build as a side-effect of compilation. This is done by using the -MF flags of the compiler. This speeds up the build by 15-35%. * PR 196193: WITHOUT_CROSS_COMPILER was fixed to properly use --sysroot which allows the option to work in more cases. It is still unsafe when major compiler upgrades occur. Further work is planned to improve that still. * WITHOUT_TOOLCHAIN now properly builds. This project was sponsored by EMC / Isilon Storage Division. Open tasks: 1. Opportunistically skipping the bootstrap compiler phase of buildworld. 2. Skipping the make obj tree walk. 3. Enabling WITH_META_MODE in buildworld to provide a reliable incremental build using filemon(4) and bmake's .MAKE.MODE=meta. This should not be confused with WITH_DIRDEPS_BUILD which previously was named WITH_META_MODE and is a drastically different build system presented at BSDCan 2014 by Simon Gerraty. __________________________________________________________________ Qt 5.6 on Raspberry Pi Links Qt 5.6 on FreeBSD/Pi URL: http://kernelnomicon.org/?p=598 Contact: Oleksandr Tymoshenko Qt 5.6 is a great framework for building embedded GUI applications, so when Qt 5.6 was released it was natural to bring it up on the Raspberry Pi. The current Qt support in ports is very Xorg-centric, so as a proof of concept I created an experimental qt56-base and qt56-multimedia. qt56-base can be configured for a generic ARM device with the scfb video driver, and specifically for Raspberry Pi in which case it supports EGLFS mode with hardware OpenGL acceleration. Open tasks: 1. Check how embedded use cases can be fit into the current bsd.qt.mk or whether a new port should be introduced. __________________________________________________________________ The FreeBSD Foundation Links FreeBSD Foundation Site URL: https://www.freebsdfoundation.org/ Donors URL: https://www.freebsdfoundation.org/donors/ Education and Advocacy Materials URL: https://www.freebsdfoundation.org/what-we-do/education-advocacy/ Faces of FreeBSD: Scott Long URL: https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-scott-long/ Faces of FreeBSD: Sean Bruno URL: https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-sean-bruno/ The Longstanding Relationship Between FreeBSD and ZFS URL: https://www.freebsdfoundation.org/blog/freebsd-and-zfs/ FreeBSD RISC-V Work URL: https://www.freebsdfoundation.org/blog/initial-freebsd-risc-v-architecture-port-committed/ Mellanox's Work with NetFlix URL: http://www.mellanox.com/page/press_release_item?id=1688 FreeBSD - The Power to Serve a Community URL: https://chemnitzer.linux-tage.de/2016/de/programm/beitrag/194 The FreeBSD Foundation's New Look URL: https://www.freebsdfoundation.org/blog/introducing-a-new-look-for-the-foundation/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage development projects, conferences and developer summits, and provide travel grants to FreeBSD developers. The Foundation purchases hardware to improve and maintain FreeBSD infrastructure and publishes FreeBSD white papers and marketing material to promote, educate, and advocate for the FreeBSD Project. The Foundation also represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: Fundraising Efforts We raised $204,000 last quarter from individual and corporate donors. Thank you to everyone who made a donation this year! The list of donors is available. OS Improvements The Foundation improves FreeBSD by funding software development projects approved through our proposal submission process, and our three software developer staff members. Two Foundation-funded projects were started last quarter, the first to improve the stability of the vnet network stack virtualization infrastructure, and the second for phase two of the FreeBSD/arm64 port project. Foundation staff members were responsible for many changes over the quarter. Some notable items include process-shared pthread locks, address mapping randomization, disk I/O bandwidth limits, porting libunwind to FreeBSD/arm, bug fixes in the autofs automount daemon, an updated version of the ELF Tool Chain, investigation of the lld linker, improved x86 hardware support, and VM subsystem stability improvements. Several of these projects are described elsewhere in this quarterly report. Release Engineering Foundation employee and release engineer Glen Barber worked on packaging the base system with pkg(8), separating debug files from the default base system so they can be selected or deselected during an install, supporting preparations, testing for the on-time release of FreeBSD 10.3, and producing 11-CURRENT and 10-STABLE snapshot builds. FreeBSD Advocacy Anne Dickison, our Marketing Director, focused on creating and updating marketing material to promote and teach people about FreeBSD. This material is available for FreeBSD advocates to hand out at conferences and events to promote FreeBSD. She also worked on promoting FreeBSD work being done over social media, blog posts, and articles. Last quarter, we continued our Faces of FreeBSD series by publishing stories about Scott Long and Sean Bruno. This is an opportunity to put a face to a name in the FreeBSD community and get to know more about the people who contribute to FreeBSD. Work began on updating the FreeBSD 10.X brochure to include the new 10.3 features. We love getting stories from companies who are successfully using FreeBSD. Testimonials were received last quarter from Chelsio and Acceleration Systems. ZFS was making some headlines, so we wrote a blog entry on the longstanding relationship between FreeBSD and ZFS. We helped promote the FreeBSD RISC-V work being done. Assistance was provided to Mellanox for their press release highlighting their work with NetFlix. Conferences and Events The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We provide financial support to the major BSD conferences like BSDCan, AsiaBSDCon, and EuroBSDCon, and give financial and/or other support for smaller events like BSDDays, FreeBSD Summits, and FreeBSD workshops, camps, and hackathons. For open source conferences, we will attend when we can get a free non-profit booth. The year kicked off with sending Ed Maste, Benedict Reuschling, and George Neville-Neil to promote and give talks on FreeBSD at FOSDEM, the largest open source conference in Europe. Ed, our Project Development Director, had a chance to talk to developers from other projects based on FreeBSD, and various people about reproducible builds in FreeBSD. Dru Lavigne and Deb Goodkin promoted FreeBSD at SCALE in Pasadena, California. Dru gave a presentation called "Doc Like an Egyptian." We were a Gold Sponsor for AsiaBSDCon in Tokyo, and five Foundation members attended. Kirk McKusick taught a two-day FreeBSD Kernel tutorial and gave a talk on the history of the BSD filesystem. Dru Lavigne and Benedict Reuschling gave a documentation tutorial. Board members Hiroki Sato and George Neville-Neil helped organize the conference. BSDnow.tv interviewed Benedict at AsiaBSDCon about his role as a new Foundation board member and the Foundation's work. We planned and organized our first-ever FreeBSD Storage Summit in association with the USENIX FAST Conference. Led by our President and Founder, Justin Gibbs, we had over 50 attendees participating and working together on technically focused topics. Benedict was busy promoting FreeBSD in Europe, where he also attended Linuxtage in Chemnitz, Germany to give a talk on FreeBSD (in German): FreeBSD -- The Power to Serve a Community. The Foundation committed to being a Gold Sponsor for BSDCan and the upcoming Hackathon/DevSummit in Essen, Germany in April. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We continued to review requests for permission to use the trademarks. FreeBSD Community Engagement Code of Conduct -- Anne Dickison, our Marketing Director, has been overseeing the efforts to rewrite the Project's Code of Conduct to help make this a safe, inclusive, and welcoming community. We have been reaching out to other open source communities to get help with our efforts in making this a diverse community and help us achieve our goals mentioned above of making the FreeBSD community safe, inclusive, and welcoming. Continuing with our diversity efforts, we have been connecting with women in technology groups to work on how we can recruit more women to FreeBSD and offer Intro to FreeBSD workshops. Meetings were held with a number of commercial vendors to help facilitate collaboration with the Project. This included presenting how the Project is organized, and how companies can get help, contribute back to the Project, promote their use of FreeBSD, and for us to get their feedback on the work we are doing to help with our fundraising efforts. The new Foundation website and logo was launched, signaling the ongoing evolution of the Foundation identity and ability to better serve the FreeBSD Project and community. Find our more about our new look. __________________________________________________________________ From owner-freebsd-hackers@freebsd.org Mon May 2 01:12:20 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31FDDB22A2E for ; Mon, 2 May 2016 01:12:20 +0000 (UTC) (envelope-from grog@lemis.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8AE1ABE for ; Mon, 2 May 2016 01:12:20 +0000 (UTC) (envelope-from grog@lemis.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1DDACB22A2D; Mon, 2 May 2016 01:12:20 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D791B22A2C for ; Mon, 2 May 2016 01:12:20 +0000 (UTC) (envelope-from grog@lemis.com) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id F1A391ABC for ; Mon, 2 May 2016 01:12:19 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 7DA5E1B72800; Mon, 2 May 2016 01:12:13 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 28F0A44A5FE; Mon, 2 May 2016 11:12:12 +1000 (AEST) Date: Mon, 2 May 2016 11:12:12 +1000 From: Greg 'groggy' Lehey To: Warren Block Cc: FreeBSD Hackers Subject: Re: [FreeBSD-Announce] FreeBSD Quarterly Status Report - First Quarter 2016 Message-ID: <20160502011212.GA15924@eureka.lemis.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5346-1370, +61-3-5309-0418 Mobile: 0401 265 606. Use only as instructed. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:12:20 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 1 May 2016 at 18:47:19 -0600, Warren Block wrote: > Introduction > > The first quarter of 2016 showed that FreeBSD retains a strong sense of > ipseity. Improvements were pervasive, lending credence to the concept > of meliorism. So you got the Young Obfuscators Dictionary for Christmas too? Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcmqWwACgkQIubykFB6QiMUwQCfWm2jQ+OQqY4HMGA2QaBwNCTf zn4AnAy29xbmtUfmG9n58I5rF905YOJH =hdYf -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-hackers@freebsd.org Mon May 2 01:28:23 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F17F5B22D5E for ; Mon, 2 May 2016 01:28:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DD4E51043 for ; Mon, 2 May 2016 01:28:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: by mailman.ysv.freebsd.org (Postfix) id D9122B22D5C; Mon, 2 May 2016 01:28:23 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8C4DB22D5B for ; Mon, 2 May 2016 01:28:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB2B91041; Mon, 2 May 2016 01:28:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id u421SMLZ098732 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 May 2016 19:28:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id u421SMSl098729; Sun, 1 May 2016 19:28:22 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 1 May 2016 19:28:22 -0600 (MDT) From: Warren Block To: "Greg 'groggy' Lehey" cc: FreeBSD Hackers Subject: Re: [FreeBSD-Announce] FreeBSD Quarterly Status Report - First Quarter 2016 In-Reply-To: <20160502011212.GA15924@eureka.lemis.com> Message-ID: References: <20160502011212.GA15924@eureka.lemis.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 01 May 2016 19:28:22 -0600 (MDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:28:24 -0000 On Mon, 2 May 2016, Greg 'groggy' Lehey wrote: > On Sunday, 1 May 2016 at 18:47:19 -0600, Warren Block wrote: >> Introduction >> >> The first quarter of 2016 showed that FreeBSD retains a strong sense of >> ipseity. Improvements were pervasive, lending credence to the concept >> of meliorism. > > So you got the Young Obfuscators Dictionary for Christmas too? Mine is called "Stupefaction for Neophytes, the Unexpurgated Guide to "Bafflement for Beginners". It was remaindered at the folio emporium. From owner-freebsd-hackers@freebsd.org Mon May 2 01:39:11 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C853B290AC for ; Mon, 2 May 2016 01:39:11 +0000 (UTC) (envelope-from grog@lemis.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EBFC11795 for ; Mon, 2 May 2016 01:39:10 +0000 (UTC) (envelope-from grog@lemis.com) Received: by mailman.ysv.freebsd.org (Postfix) id E7A73B290AB; Mon, 2 May 2016 01:39:10 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E74FEB290AA for ; Mon, 2 May 2016 01:39:10 +0000 (UTC) (envelope-from grog@lemis.com) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id C5C7F1794 for ; Mon, 2 May 2016 01:39:10 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 8EA1E1B72800; Mon, 2 May 2016 01:39:09 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 82C8344A5FE; Mon, 2 May 2016 11:39:08 +1000 (AEST) Date: Mon, 2 May 2016 11:39:08 +1000 From: Greg 'groggy' Lehey To: Warren Block Cc: FreeBSD Hackers Subject: Re: [FreeBSD-Announce] FreeBSD Quarterly Status Report - First Quarter 2016 Message-ID: <20160502013908.GB15924@eureka.lemis.com> References: <20160502011212.GA15924@eureka.lemis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5346-1370, +61-3-5309-0418 Mobile: 0401 265 606. Use only as instructed. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:39:11 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sunday, 1 May 2016 at 19:28:22 -0600, Warren Block wrote: > On Mon, 2 May 2016, Greg 'groggy' Lehey wrote: > >> On Sunday, 1 May 2016 at 18:47:19 -0600, Warren Block wrote: >>> Introduction >>> >>> The first quarter of 2016 showed that FreeBSD retains a strong sense of >>> ipseity. Improvements were pervasive, lending credence to the concept >>> of meliorism. >> >> So you got the Young Obfuscators Dictionary for Christmas too? > > Mine is called "Stupefaction for Neophytes, the Unexpurgated Guide to > "Bafflement for Beginners". > > It was remaindered at the folio emporium. So when can we see a look-alike port? textproc/obfuscation, for example? Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcmr7wACgkQIubykFB6QiO4GACdFPHpVAppSt8rQLTpxl0WtBBJ 91UAnibYwQ3MHGrpI2xa7BHRJv7BjEZm =Pk8W -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-hackers@freebsd.org Mon May 2 01:37:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E66A6B22FA9; Mon, 2 May 2016 01:37:49 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id C9AA9166D; Mon, 2 May 2016 01:37:49 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0O6J001Y60UWIO00@hades.sorbs.net>; Sun, 01 May 2016 18:44:58 -0700 (PDT) Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) To: Warren Block , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: From: Michelle Sullivan Message-id: <5726AF64.4080709@sorbs.net> Date: Mon, 02 May 2016 03:37:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 In-reply-to: X-Mailman-Approved-At: Mon, 02 May 2016 03:06:59 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 01:37:50 -0000 Warren Block wrote: > Introduction > > The first quarter of 2016 showed that FreeBSD retains a strong > sense of > ipseity. Improvements were pervasive, lending credence to the concept > of meliorism. > > Panegyrics are relatively scarce, but not for lack of need. Perhaps > this missive might serve that function in some infinitesimal way. > > There was propagation, reformation, randomization, accumulation, > emulation, transmogrification, debuggenation, and metaphrasal during > this quarter. > > In the financioartistic arena, pork snout futures narrowly edged out > pointilism, while parietal art remained fixed. > > In all, a discomfiture of abundance. View the rubrics below, and > marvel > at their profusion and magnitude! Marvel! You're trolling right? -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-hackers@freebsd.org Mon May 2 02:25:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE1C1B29EA8; Mon, 2 May 2016 02:25:59 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [IPv6:2607:f8b0:4001:c05::242]) (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 98A7612A4; Mon, 2 May 2016 02:25:59 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-ig0-x242.google.com with SMTP id rc4so8131493igc.0; Sun, 01 May 2016 19:25:59 -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; bh=m+5UNePwOhtwUwXjDpjFAm217Nu3IKOwlBDIFmAHo9k=; b=AMbDYh/HsNim1QeyEv2Qi4QHZQ/azKZRDQuDRdbpCAqHcYDJXp5i8ydz3osG7PSVh4 ePvcqUdAT1lDz0DaDFOmj1ZRx2Mz3R7iteNyirMMK3+5wkoBUTEg0p7hxG8lnadTHFrs yc96i+CDrDNxDgT8Rvv6jkh9hAGeh9POXo/MJXt4P05Fmoj2ad506pr5hvtl90sfLSeD FyWjiZbBhbC7BiZJ/cegKVZSD4TW04eULvNKH866i9bIvLL3XSTlwWw3dyjZV7blruWX xUNuKG6Qd/SE1XGiznjX9Oh0Qgg13VJ9jNN50Af3VwN2SNF//Gv4BCYPGN1Xb05n0Yuo WQsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=m+5UNePwOhtwUwXjDpjFAm217Nu3IKOwlBDIFmAHo9k=; b=GsPQFpsqvSKtodLeK93YKlShy8e4hzvNl0Pqs215NdAHfARD7mge7Uok0O30xzvUI8 mwSdSaJaADHPe0G4giv60NeTK8PA1rORS1Fule8CYSz72i1zWLpOaWNl+1MEZPxtNRXl flzzE7M8S0CfOscjNA5RfAO891NAe20VlJCTlte9V2btIrqcnSk6BN+XcR5KgS/Avmyf n34YLRy61NYS05qaxauggE0VhgLzsoaSwcyN73ebQEriOYlCeRjdc3VrjuLyLApqcADl fxy/ESxPinYW0yHQLWlUkVB+rhQKKE2KIasjWeTBriRGzqgQMkA9JHRxqCpOLaQxnh7S 39lA== X-Gm-Message-State: AOPr4FXcdKc0YHQ//Hwo+8rA9lmphRR7606ssOZEfOGAohYEY34sq3TF4241ZuJXvWjGZIP/hbmoynSvW7ndJA== MIME-Version: 1.0 X-Received: by 10.50.55.34 with SMTP id o2mr17442427igp.18.1462155958893; Sun, 01 May 2016 19:25:58 -0700 (PDT) Received: by 10.79.11.193 with HTTP; Sun, 1 May 2016 19:25:58 -0700 (PDT) In-Reply-To: <5726AF64.4080709@sorbs.net> References: <5726AF64.4080709@sorbs.net> Date: Sun, 1 May 2016 19:25:58 -0700 Message-ID: Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) From: Kurt Buff To: Michelle Sullivan Cc: Warren Block , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 02 May 2016 03:17:15 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:26:00 -0000 Trolling? Oh heck no. That's just good old fun with words, and driving people to the thesaurus. After all, immediate following that was this: Please submit status reports for the second quarter of 2016 by July 7. A thesaurus will be provided for submitters who do not have one of their own. We will need them back afterwards, preferably with no new teeth marks on the covers. Thank you! Kurt On Sun, May 1, 2016 at 6:37 PM, Michelle Sullivan wrote: > Warren Block wrote: >> >> Introduction >> >> The first quarter of 2016 showed that FreeBSD retains a strong sense of >> ipseity. Improvements were pervasive, lending credence to the concept >> of meliorism. >> >> Panegyrics are relatively scarce, but not for lack of need. Perhaps >> this missive might serve that function in some infinitesimal way. >> >> There was propagation, reformation, randomization, accumulation, >> emulation, transmogrification, debuggenation, and metaphrasal during >> this quarter. >> >> In the financioartistic arena, pork snout futures narrowly edged out >> pointilism, while parietal art remained fixed. >> >> In all, a discomfiture of abundance. View the rubrics below, and marvel >> at their profusion and magnitude! Marvel! > > > You're trolling right? > > -- > Michelle Sullivan > http://www.mhix.org/ > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon May 2 03:18:08 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCE67B2ACA6; Mon, 2 May 2016 03:18:08 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ig0-x243.google.com (mail-ig0-x243.google.com [IPv6:2607:f8b0:4001:c05::243]) (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 852C1145E; Mon, 2 May 2016 03:18:08 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: by mail-ig0-x243.google.com with SMTP id c3so8160556igl.3; Sun, 01 May 2016 20:18:08 -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; bh=bUx220NVw4D92FyREHjmyu7YsdVuHPL1220HiNtOkrA=; b=EGt0++l/23vWvG+UBh71bc8pV0aAMIZeHMvzRVOeLb9uj1Hi4bMJGZ3g1+5CfeJUYi zUttrZGRKFV69HvIFG6Ckhx1d+Ln8+tqpO81I5MPl3h3/6pNLe0SGbUwQWhUBAbQWrHU W4vb5T7Q8lFQubzz9zTXRWJxKT31QdTezYDsjzgvIYWn6MKwzgdPe1S2wczRc3OprMok tzOB0KYZmxgr6MlLqfUB7/JzhGkpixazqCap9OaBPbMnoge3cYTGVMm5qPH/AsMfc44m 1nipcu0egZmqZg/VxPewvSJNcgbsYwGXnLiSW3bTkzYU8rCbjCXL+azGulW9B8RgBAaz QAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bUx220NVw4D92FyREHjmyu7YsdVuHPL1220HiNtOkrA=; b=G4yZX84r7Fnv77akJdi3Z0yp0skIRab5NjxUk8xnfsKD0qrMSVZ1cjmz1vw2Tkxjt5 jVt6QD3yxA92TB9Mnok6gXRSvWV3i5MVdTAvJh/YZzrY4oKWqePFzrfIgKjdEuFc2s9r rwe59IGRiek27EJHV9oy+z3Waa6IKWLrNcJLMYtU0mgkWfza4bpP4mRMwZ3IvZAlxvv0 BEcUf0hBBow3v0pBvnWLb1rqznEAzDKVi1q5/XcvbwWEcf0m3Em+r0VdjHIe/jKZX4GQ hxZwS4yUbrbqkeFggsx9NlXa+jEhNmmC6Y/qQI4H/NmYYVylwhSzeOn3tT5GV0mwWjmn SeCg== X-Gm-Message-State: AOPr4FVYD5j9nN5So6obLwJUyIrCuseEMOnwbYqxJTc4lhGCBLNk7/ILSQnXmj8A8g+XMJ4cfS0Hzu87kce4GA== MIME-Version: 1.0 X-Received: by 10.50.55.34 with SMTP id o2mr17607109igp.18.1462159087876; Sun, 01 May 2016 20:18:07 -0700 (PDT) Received: by 10.79.11.193 with HTTP; Sun, 1 May 2016 20:18:07 -0700 (PDT) In-Reply-To: References: <5726AF64.4080709@sorbs.net> Date: Sun, 1 May 2016 20:18:07 -0700 Message-ID: Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) From: Kurt Buff To: Brandon Allbery Cc: Michelle Sullivan , Warren Block , "freebsd-hackers@freebsd.org" , freebsd current , "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 02 May 2016 04:12:26 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 03:18:08 -0000 Further deponent sayeth not... Kurt On Sun, May 1, 2016 at 8:14 PM, Brandon Allbery wrote: > On Sun, May 1, 2016 at 10:25 PM, Kurt Buff wrote: >> >> That's just good old fun with words, and driving people to the >> thesaurus > > > So what's it say about those of us who didn't need one? > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-hackers@freebsd.org Mon May 2 04:16:48 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E4E1B29AF4; Mon, 2 May 2016 04:16:48 +0000 (UTC) (envelope-from jordanhubbard@me.com) Received: from pv33p03im-asmtp002.me.com (pv33p03im-asmtp002.me.com [17.143.180.11]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F21041FFD; Mon, 2 May 2016 04:16:47 +0000 (UTC) (envelope-from jordanhubbard@me.com) Received: from process-dkim-sign-daemon.pv33p03im-asmtp002.me.com by pv33p03im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) id <0O6J00N0053D8K00@pv33p03im-asmtp002.me.com>; Mon, 02 May 2016 03:16:41 +0000 (GMT) Received: from [10.11.111.213] (50-250-239-90-static.hfc.comcastbusiness.net [50.250.239.90]) by pv33p03im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O6J00NRB53RFO20@pv33p03im-asmtp002.me.com>; Mon, 02 May 2016 03:16:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-05-02_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1605020051 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) From: Jordan Hubbard In-reply-to: Date: Sun, 01 May 2016 20:16:38 -0700 Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Content-transfer-encoding: quoted-printable Message-id: <3AED0DA0-5980-426F-A93E-0EC726A07AAE@me.com> References: To: Warren Block X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1462159001; bh=N7wh4sDnGtbScjZ/WtQrylJGvdNJX/wqqZbtwaQhYNI=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=llTdoJQy3l0qN1baZxzPOOjlt7Sc1fAqJxuVty4D3tmeB+Q2qWIUs+7xJ1PtFrklg MbBnt9BQOFFMn/UiS0m1jkZ0gPCjjnMJeW2gzx6e0xWD87ScmQuLOMa3ngcLBwrcfj ijMp1CEqg4iZaHkYEvRSesLkElhujVaf8J8a8kFXgP+4jPGMcpAm5gWgo1s+f+8vQJ sI8WlUe+h4x5aO60AcmrNv15+f/XO7I11+3UZn+ivfwvv5yzmh3MMzqG2Az5LN8Njq mwzjIZHtafd30Ex4njbchG7MMrGtPgRX7cOSUmlwSsxVeAdV7igO/4vdwJI//rJAhQ pR/TVtV2hfLpA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 04:16:48 -0000 > On May 1, 2016, at 5:49 PM, Warren Block wrote: >=20 > The first quarter of 2016 showed that FreeBSD retains a strong sense = of > ipseity. Improvements were pervasive, lending credence to the = concept > of meliorism. [ =E2=80=A6 ] I, for one, learned at least 4 new words in that announcement, 3 of = which were actually real. May we all strive for greater meloristic = ipseity! I also applaud both your recent acquisition of a thesaurus and your keen = appreciation of when to discard it and simply rely on your imagination. = it made an otherwise prosaic status report more provocative! Plaudits. - Jordan From owner-freebsd-hackers@freebsd.org Mon May 2 04:23:27 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67AD0B29D92; Mon, 2 May 2016 04:23:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5880614C5; Mon, 2 May 2016 04:23:27 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id EF5581B89; Mon, 2 May 2016 04:23:26 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Mon, 2 May 2016 04:23:26 +0000 From: Glen Barber To: Jordan Hubbard Cc: Warren Block , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) Message-ID: <20160502042326.GG1804@FreeBSD.org> References: <3AED0DA0-5980-426F-A93E-0EC726A07AAE@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0blXd8FRAMeUaMgT" Content-Disposition: inline In-Reply-To: <3AED0DA0-5980-426F-A93E-0EC726A07AAE@me.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 04:23:27 -0000 --0blXd8FRAMeUaMgT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Despite my dissatisfaction with this status update, I'll reply to an email in public... On Sun, May 01, 2016 at 08:16:38PM -0700, Jordan Hubbard wrote: >=20 > > On May 1, 2016, at 5:49 PM, Warren Block wrote: > >=20 > > The first quarter of 2016 showed that FreeBSD retains a strong sense = of > > ipseity. Improvements were pervasive, lending credence to the concept > > of meliorism. [ =E2=80=A6 ] >=20 > I, for one, learned at least 4 new words in that announcement, 3 > of which were actually real. May we all strive for greater meloristic > ipseity! >=20 > I also applaud both your recent acquisition of a thesaurus and > your keen appreciation of when to discard it and simply rely on > your imagination. it made an otherwise prosaic status report more ^^ Should be capitalized, as start of sentence. > provocative! Plaudits. >=20 Glen --0blXd8FRAMeUaMgT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXJtY+AAoJEAMUWKVHj+KTeFMP/iQ4cACXmRAx+fMST4eQx8LT XXdtkauTpufsefaWjHORQ+yCxG9A1uU7IwUWyuVRQZMXoM3s/x1TCTykdvV5i+wf w9c+RGQnS08OsIJo1S8V73jwj54LmNlvgJbpryCDOTS8ScKDyv8wutjJLazXYhUI BoDTMJUgq5xIzcdVcFVKNcz0lSpx2rQav3x3IwUyrKsDFVDsIokQuaGLPLif+lIc HbvON2k4sD8b4ex/JtNewMs1Pjz0Mp2iA4Vq4F9LWXxdLvf8yJ78AAsnD03aVNg7 qeFz3frui6uItJG6k4oiNcBxttUKLqWiPACPk63Qip1zyACizMEin6QU26+qe125 RfXCnLsoSM6R4lgl9wNKk7l/x1daPnaS26xX9Wbyhmq143nhK1o5R3GbteaqKwj9 QK75Dh1/sbyTMHLvOaut1tV1hbNIr2X67ErpUOswTlzPBIuRc1wuUnxY9LzH0LEY yPh4PY/BlfwqGdVdI4aSN3kw5+wyrKbH6IVCBnUdr2TcvzKX3G5BIGuG4/DJSEIe 0vxiBqfqv1pBknPjeNFWV2xpzBs8orUT18OgIQ9i6zUoCh2GL550bkNn69zfCY7i PiJNL20lYc5qXOSCJzA0c2uzN55cEp7WbmQXIaC5zF2Da1AgiwCm7o2cobeGIjSQ zXbjaTlR1FZgSJMxAOGs =sAsz -----END PGP SIGNATURE----- --0blXd8FRAMeUaMgT-- From owner-freebsd-hackers@freebsd.org Mon May 2 03:14:12 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2944B2AAC0; Mon, 2 May 2016 03:14:12 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 6330B106F; Mon, 2 May 2016 03:14:12 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: by mail-yw0-x22a.google.com with SMTP id o66so262408702ywc.3; Sun, 01 May 2016 20:14:12 -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; bh=vGlWIgslJdvTkJnn0anDFxoLMccWTM9sOzEfgIhWzSk=; b=L9YN2CtIGnNzy+tiFEK7NzycqMYCEBU6ezvd4UB8ry5YB6UOlWGwXn10oyax0ps3MQ utlgZEXoM9H3J7LfVkU93yVgIhLt1qbalZVpyC2ntTPy25vhPlGo60Mw7BTPrUaa8mKn s5V0G43iQPO+n5oW64JL/Pk+LlyqBDxwMPnD3Bx2V0DlgMRxYrB02sXMfTZj7axi5EWI hS0a55JybwFYmbMfQgpErP16sAKnfZt0oT+DHNwA+2gn4rKWQKfSdWxE41vwzPi1B02B t6WjvjFqoW3MmDSQfz0Tgg2xdUMy33LfRe8pFpzJ6Xj7JzC7D/zfyO3QHpQPxu75db7O 87sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vGlWIgslJdvTkJnn0anDFxoLMccWTM9sOzEfgIhWzSk=; b=HSNIiLW3Mskr0+KOA3D27K5Zlhb6Iyp71lp8R5nyLGWdkpD7QBYDOiBeB2GVfusYrI MeARzPULLEi8QJHlklBwmSiDAOCFMJpXV6r3z50CqZZ7A/8Bez0HFK5RQ3zZbI78UCp3 K/EmAA1Wh+mrdfFLCdgivnM8ZjJTrhH8ZBWVanqk3vRp70i5r/s6en7XoAz1zu+EycDX ynvuDHj5TIpSqIsAmVGFZfBdD67wQCiC54DRYOMPYVAIRh0pcIu4mUb2KbSlcutpFiyV FqdRZsak/zpy0ROs+5jOylPPPmV480obXQxrr1R5dtisplzPKOy47/+MBXNwCzoFZ8Og /ikw== X-Gm-Message-State: AOPr4FUqv6Y5f+OF5ElzAD25yKuGqHVD2/ZkbdHjFXPtteu8iYSxXhpdaHdx/5XAN+Qv/NZpxEZMNcnSDKIzqA== MIME-Version: 1.0 X-Received: by 10.159.38.48 with SMTP id 45mr19953643uag.7.1462158851377; Sun, 01 May 2016 20:14:11 -0700 (PDT) Received: by 10.159.35.104 with HTTP; Sun, 1 May 2016 20:14:11 -0700 (PDT) In-Reply-To: References: <5726AF64.4080709@sorbs.net> Date: Sun, 1 May 2016 23:14:11 -0400 Message-ID: Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) From: Brandon Allbery To: Kurt Buff Cc: Michelle Sullivan , Warren Block , "freebsd-hackers@freebsd.org" , freebsd current , "freebsd-stable@freebsd.org" X-Mailman-Approved-At: Mon, 02 May 2016 10:56:34 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 03:14:12 -0000 On Sun, May 1, 2016 at 10:25 PM, Kurt Buff wrote: > > That's just good old fun with words, and driving people to the > thesaurus So what's it say about those of us who didn't need one? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From owner-freebsd-hackers@freebsd.org Mon May 2 22:25:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5331AB2B8BA for ; Mon, 2 May 2016 22:25:21 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 30DB119F9 for ; Mon, 2 May 2016 22:25:21 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.206.88.37] (mobile-166-172-060-147.mycingular.net [166.172.60.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 765361FE3 for ; Mon, 2 May 2016 22:25:20 +0000 (UTC) User-Agent: K-9 Mail for Android MIME-Version: 1.0 Subject: Problem with objcopy corrupting section names From: Eric McCorkle Date: Mon, 02 May 2016 18:25:18 -0400 To: freebsd-hackers@freebsd.org Message-ID: <65BAB92F-271C-489F-A804-6496B4953599@metricspace.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:25:21 -0000 Hello everyone, I've been doing quite a bit of work in the efi boot1 and loader codebases. In particular, I've been trying to get both boot1 and loader using the same backend filesystem drivers. As background, both the boot1 and loader build processes use objcopy to convert the elf format executable produced by the platform build tools to the PE+ format used by EFI. I've run into a weird problem where the section names are seemingly being corrupted for boot1. The process to reproduce this should be simple: just build boot1 and then do objdump -x boot1.efi and you should see that the section names are corrupted. The code can be found here. https://github.com/emc2/freebsd/tree/efize Before I report this, can someone please do a sanity check and make sure the problem is reproducible and has doesn't have an easy solution that I've overlooked? Thanks, Eric -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-hackers@freebsd.org Tue May 3 03:41:01 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F340B2BEC6; Tue, 3 May 2016 03:41:01 +0000 (UTC) (envelope-from grog@lemis.com) Received: from www.lemis.com (www.lemis.com [208.86.226.86]) by mx1.freebsd.org (Postfix) with ESMTP id 2035B181C; Tue, 3 May 2016 03:41:00 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (www.lemis.com [208.86.226.86]) by www.lemis.com (Postfix) with ESMTP id 0D0BB1B72800; Tue, 3 May 2016 03:40:54 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id B5E1844A5FE; Tue, 3 May 2016 13:40:52 +1000 (AEST) Date: Tue, 3 May 2016 13:40:52 +1000 From: Greg 'groggy' Lehey To: Jordan Hubbard Cc: Warren Block , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd) Message-ID: <20160503034052.GE15924@eureka.lemis.com> References: <3AED0DA0-5980-426F-A93E-0EC726A07AAE@me.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ep0oHQY+/Gbo/zt0" Content-Disposition: inline In-Reply-To: <3AED0DA0-5980-426F-A93E-0EC726A07AAE@me.com> Organization: The FreeBSD Project Phone: +61-3-5346-1370, +61-3-5309-0418 Mobile: 0401 265 606. Use only as instructed. WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 03:41:01 -0000 --ep0oHQY+/Gbo/zt0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [line lengths recovered] On Sunday, 1 May 2016 at 20:16:38 -0700, Jordan Hubbard wrote: > >> On May 1, 2016, at 5:49 PM, Warren Block wrote: >> >> The first quarter of 2016 showed that FreeBSD retains a strong sense of >> ipseity. Improvements were pervasive, lending credence to the concept >> of meliorism. [ ??? ] > > > I, for one, learned at least 4 new words in that announcement, 3 of > which were actually real. And the other is int? OK, I'll bite. Which one is unreal? Greg -- Sent from my desktop computer. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA --ep0oHQY+/Gbo/zt0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlcoHcQACgkQIubykFB6QiPAuACdEa8GtTb9Kt6lc2fUw7wRGqb3 QTIAn3vVQIiocbDvRmXbbz2w59+00O7Y =MlmG -----END PGP SIGNATURE----- --ep0oHQY+/Gbo/zt0-- From owner-freebsd-hackers@freebsd.org Tue May 3 15:11:26 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B264B2B6C6 for ; Tue, 3 May 2016 15:11:26 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 0FE6B1E74; Tue, 3 May 2016 15:11:25 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.206] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id A441E192928; Tue, 3 May 2016 15:11:24 +0000 (UTC) Subject: Re: Phabricator Badges To: Devin Teske , "phabric-admin@FreeBSD.org" References: <8AC02865-DB49-4250-9D69-40BBC686F2B1@freebsd.org> From: Sean Bruno Message-ID: <5728BF9B.7030505@freebsd.org> Date: Tue, 3 May 2016 08:11:23 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <8AC02865-DB49-4250-9D69-40BBC686F2B1@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 03 May 2016 15:43:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:11:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/26/16 14:51, Devin Teske wrote: > Once upon a time (circa July 2015) we had badges in Phabricator. > E.g., > > https://reviews.freebsd.org/badges/recipients/4/ > > > However, they seem to be gone. Was there any particular reason > why? > > I was recently going to use us as an example to show why Phab may > be better than what we use at $work (ReviewBoard). > It appears to still be there, but the URLs may have changed to protect the innocent? https://reviews.freebsd.org/badges/ sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJXKL+XXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kcPoH+gJNga6jdk7q/D1pumuSQx2+ AmnvVoam35fLhjH0+4Mubtkc/PynsyVFHQSGBp8T6qrveEM4R843bJYZA1+jwc+s r2v5L5LT8pjW4Een+0RxNysOneftIqR9HGb4qPT77XAYsP3s1g27h3YqZmFfJK6J KbI7nBu4/usjwpjNKK5QodaYi+PJw5ZsfURphQZMJijry8NNtLmCr+1Sg1hOHJtd amAdga/wXXY5TALVxNJCM+F2eWgmTf0G0vn2kM1SGT+i9exx1iyJyr4XwYocAYhJ tGpm6wREp4vdpZ/Wcg6SbHTyRNBHyWv0L3plBhmjSBdKCRQ7gMkaRDVrIL/p/D4= =LqpT -----END PGP SIGNATURE----- From owner-freebsd-hackers@freebsd.org Tue May 3 22:41:38 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 507B9B2CC4D for ; Tue, 3 May 2016 22:41:38 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 200ED1A18 for ; Tue, 3 May 2016 22:41:38 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x22d.google.com with SMTP id f89so37642531ioi.0 for ; Tue, 03 May 2016 15:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=dCD+sL1aEHCV4tb1dGReOwJ5vC6yJegoF/W6ZQXB8Ro=; b=xsPRgBAjpb+QoAvJ9LWe5XnedxDi42OQyNoHXYvNHcg88GxlkndZKGGc34Bi/fuxJR qkqncL03kJmuGp+5Aofyzfsx3grlJoZV6Z7ogXofwqjptBNEqCaBD0Z/pa4n/kpjeCDd EmhhGYZognOfoAknbB1Mm7JrTXzsXSA74hJ0qkGnG/d2x/j8wt33gWdeianPDOWqNWtt xsr6cuikxDxQQnnB3eOrXjncGuhu9uHCBXwpFO+rhBQ0LKpoPY28e3dHBl+EIdsUMPvD IURkoLexz5gUjq6Fs65nuBhqIvg6EQAhqNaAm2pjDOQr9AMiiR9IXT8g4sBKVaCmAqRx 5E8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=dCD+sL1aEHCV4tb1dGReOwJ5vC6yJegoF/W6ZQXB8Ro=; b=Il1v1w1yKHFs6lRwSngKLtpR32NAz1QKbtXsPWwCoIKkC2DUohJlZdV63DTf1Sugis XLrxEpXojEHQqYONtidwX3h4Cxaw9JWDrclwIuby/KOpCTLzp16UZMREwzwS7ndhMtHE fq+BG89Gv4Eos4OTfOEEPcVlPHAfzT0P6Zyc/f7NJM4QuNInUVUo7VjLDSYLFsuQhz26 hcYkhmTY9ZeCPgrTEgvaBZcvBb2BMmBaUHoMYvjqWLHqXE5fR+4Y93z1KAFmRt52Jcl3 4v2oJKqbeRYz2heoj74OkJFpObpsE3Ahgd6dMg627Ea80vWr8Tc9IbeN6etlBbPSstUF Nn/Q== X-Gm-Message-State: AOPr4FWd7kBJoS4UNVmfwfPE1LNMzjIHe40y9ITd+KMZK7lkBY/5nmMdgyP2DIfm2DZ6ZL8FytIDDA85EhqExQ== MIME-Version: 1.0 X-Received: by 10.107.190.131 with SMTP id o125mr6065431iof.68.1462315297148; Tue, 03 May 2016 15:41:37 -0700 (PDT) Received: by 10.64.89.101 with HTTP; Tue, 3 May 2016 15:41:37 -0700 (PDT) Date: Tue, 3 May 2016 15:41:37 -0700 Message-ID: Subject: TCP problems From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 22:41:38 -0000 I have suddenly started seeing TCP problems on a machine "G": running FreeBSD 10.1 Gigabyte UD5 amd64 2 Ethernet controllers, re0 and ue0: re0: port 0xb000-0xb0ff mem 0xfe600000-0xfe600fff,0xd0000000-0xd0003fff irq 16 at device 0.0 on pci6 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: Chip rev. 0x4c000000 re0: MAC rev. 0x00000000 rgephy0: PHY 1 on miibus0 ue0 is Siig USB-to-Ethernet Chipset: AX88179 Problem 1: bind(2) fails Problem 2: copying large files via Ethernet results in data corruption 1) Bind: C program containing: bzero(&server, sizeof(struct sockaddr_in)); server.sin_family=AF_INET; server.sin_port=htons((unsigned short)port_number); (void) memcpy((char*)&server.sin_addr, (char*)host->h_addr, sizeof(server.sin_addr)); return_code = socket(PF_INET, SOCK_STREAM, 0); if (return_code == -1) { fprintf(stderr, "%s: ERROR ", argv[0]); perror("socket() failed"); fflush(stderr); exit(-1); } fd = return_code; return_code = bind(fd, (struct sockaddr*)&server, sizeof(server)); if (return_code == -1) { fprintf(stderr, "%s: ERROR ", argv[0]); perror("bind() failed"); fflush(stderr); exit(-1); } gives: ERROR bind() failed: Can't assign requested address The same binary has been working perfectly on another machine (running 8.2) for years. A UDP version of the program is working ok. Rebooting didn't help. 2) Data corruption: rcp large file from machine T (running 8.2) to machine G (10.1) rcp the file back from G to T compare the two copies of the file on machine T to verify integrity This worked fine until yesterday. Now suddenly most large files have data corruption, thus cmp(1) fails. The first difference occurs at various places in the file. Both machine have 2 gigabit Ethernet controllers (2 seperate networks). Both networks have the problem. I have also tried different sata disks on different disk controllers. Both machines are amd64 and have ECC memory. Cables are factory made cat6 or cat7 25 foot or shorter. Netgear gigabit switches. I tried using ftp instead of rcp. Rebooting didn't help. machine T: nfe0: flags=8843 metric 0 mtu 1500 options=8210b media: Ethernet autoselect (1000baseT ) bge0: flags=8843 metric 0 mtu 1500 options=8009b media: Ethernet autoselect (1000baseT ) machine G: re0: flags=8843 metric 0 mtu 1500 options=8209b media: Ethernet autoselect (1000baseT ) ue0: flags=8843 metric 0 mtu 1500 options=8000b media: Ethernet autoselect (1000baseT ) I tried ifconfig -rxcsum -txcsum. Machine T seems happy, but networking on machine G stopped working so I had to turn them back on. (problem #3?) Small files (2-4 KB) and things like telnet/rsh seem to work fine. It appears that *something* broke yesterday, probably something in machine G. But what? hardware? software? From owner-freebsd-hackers@freebsd.org Tue May 3 23:18:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8697B2C4B3 for ; Tue, 3 May 2016 23:18:49 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 9751A1DCC for ; Tue, 3 May 2016 23:18:49 +0000 (UTC) (envelope-from larry.maloney@hackerdojo.com) Received: by mail-pa0-x231.google.com with SMTP id iv1so16188237pac.2 for ; Tue, 03 May 2016 16:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackerdojo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sBN1hi3dGPW/6W6ZyWmM3l75vETQNKY3ynNgi+nnCKc=; b=kaCvmd3BWnJiyjg8KTEz9n2n8XpZrymoF2U+rkJQ8IXao3pcNqkTCbNNw+50BsA7M5 2y92+6/sfvO5HtyxoNCvA//FlVGKkCykTYc8Dra7v/WnH3z/1xJ9Dqfnf4KSSCEf+bS8 MiPadsk9fp5VjRf6vSURHJGSsiqmWod9CYBYEaGGormN1HA9cvdsenvZnVOIJyWye+IX PHw5ROb7WOMTGb+0ke/VDDxCGE8iYgeecsvkF0epLJS47Ys4hilUpN/IX5+y4kEzyZCK h0VdksgdlZQLvJMqby9u3x6gEjQY0W12qOMyWpuVr2FYuBGN5AtFaewLNa8W5fp29MHZ +o4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sBN1hi3dGPW/6W6ZyWmM3l75vETQNKY3ynNgi+nnCKc=; b=EE88I5UNg/mNIRxmzi+yNMGh2RBKRXi7d/Herubiizp21y9ukS6k4hmXvc6GVcUQBW Vyykv2zawVHRrMLfTwLTA55UmiVLA94g0/m6Fu+qOFpU91RUtGhF1OexonWCPYzEATbA pQgpEyF5qVSBc69/3cOqRsm2ugWynzxBI/O4VmN4/cWxkQwaAkcxWrqAqqFdeHpsvCBB GO//5oukqJnJEmHJIQisEQaLX6kPwDAFEf2z3cQshMinJQybH/qHuYjSn3bDsLPIgCZL U1Msb/P30SI0iX7kzgcC1T7gLxL2ZDjbGwILm+9i0Wnmn5630XqQgah1i2wyT50Z2plT pOHg== X-Gm-Message-State: AOPr4FXv9WSFPjYAz2oG8fBvAJ2JUGJt7xagnn67kATOJ1mclb1HwgvYXdxIFNUAh4thRvKi X-Received: by 10.66.52.112 with SMTP id s16mr7583492pao.35.1462317529137; Tue, 03 May 2016 16:18:49 -0700 (PDT) Received: from ?IPv6:2601:647:4204:2b00:6511:f6a4:8202:79b9? ([2601:647:4204:2b00:6511:f6a4:8202:79b9]) by smtp.gmail.com with ESMTPSA id m184sm688217pfb.22.2016.05.03.16.18.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 16:18:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: TCP problems From: Larry Maloney In-Reply-To: Date: Tue, 3 May 2016 16:18:46 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <02935669-D102-4F95-B0AE-779E58DBB67D@hackerdojo.com> References: To: Dieter BSD X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:18:49 -0000 Have you tried bumping the MTU on the interfaces to JUMBO frames? 9000 = or whatever max is? /Larry > On May 3, 2016, at 3:41 PM, Dieter BSD wrote: >=20 > I have suddenly started seeing TCP problems on a machine "G": > running FreeBSD 10.1 > Gigabyte UD5 amd64 > 2 Ethernet controllers, re0 and ue0: >=20 > re0: port > 0xb000-0xb0ff mem 0xfe600000-0xfe600fff,0xd0000000-0xd0003fff irq 16 > at device 0.0 on pci6 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: Chip rev. 0x4c000000 > re0: MAC rev. 0x00000000 > rgephy0: PHY 1 on miibus0 >=20 > ue0 is Siig USB-to-Ethernet Chipset: AX88179 >=20 > Problem 1: bind(2) fails > Problem 2: copying large files via Ethernet results in data corruption >=20 > 1) Bind: >=20 > C program containing: >=20 > bzero(&server, sizeof(struct sockaddr_in)); > server.sin_family=3DAF_INET; > server.sin_port=3Dhtons((unsigned short)port_number); > (void) memcpy((char*)&server.sin_addr, (char*)host->h_addr, > sizeof(server.sin_addr)); >=20 > return_code =3D socket(PF_INET, SOCK_STREAM, 0); > if (return_code =3D=3D -1) { fprintf(stderr, "%s: ERROR ", argv[0]); > perror("socket() failed"); fflush(stderr); exit(-1); } > fd =3D return_code; >=20 > return_code =3D bind(fd, (struct sockaddr*)&server, sizeof(server)); > if (return_code =3D=3D -1) { fprintf(stderr, "%s: ERROR ", argv[0]); > perror("bind() failed"); fflush(stderr); exit(-1); } >=20 > gives: ERROR bind() failed: Can't assign requested address >=20 > The same binary has been working perfectly on another machine (running = 8.2) > for years. A UDP version of the program is working ok. Rebooting = didn't help. >=20 > 2) Data corruption: >=20 > rcp large file from machine T (running 8.2) to machine G (10.1) > rcp the file back from G to T > compare the two copies of the file on machine T to verify integrity >=20 > This worked fine until yesterday. Now suddenly most large files have = data > corruption, thus cmp(1) fails. The first difference occurs at various > places in the file. >=20 > Both machine have 2 gigabit Ethernet controllers (2 seperate = networks). > Both networks have the problem. I have also tried different sata = disks > on different disk controllers. Both machines are amd64 and have ECC = memory. > Cables are factory made cat6 or cat7 25 foot or shorter. Netgear = gigabit > switches. I tried using ftp instead of rcp. Rebooting didn't help. >=20 > machine T: > nfe0: flags=3D8843 metric 0 = mtu 1500 > options=3D8210b > media: Ethernet autoselect (1000baseT > ) > bge0: flags=3D8843 metric 0 = mtu 1500 > = options=3D8009b > media: Ethernet autoselect (1000baseT > ) >=20 > machine G: > re0: flags=3D8843 metric 0 mtu = 1500 > = options=3D8209b > media: Ethernet autoselect (1000baseT ) > ue0: flags=3D8843 metric 0 mtu = 1500 > options=3D8000b > media: Ethernet autoselect (1000baseT ) >=20 > I tried ifconfig -rxcsum -txcsum. Machine T seems happy, but > networking on machine G stopped working so I had to turn them back on. > (problem #3?) >=20 > Small files (2-4 KB) and things like telnet/rsh seem to work fine. >=20 > It appears that *something* broke yesterday, probably something in > machine G. But what? hardware? software? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://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 May 3 23:24:40 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71989B2C7C0 for ; Tue, 3 May 2016 23:24:40 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 2F6A01348 for ; Tue, 3 May 2016 23:24:40 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qg0-x234.google.com with SMTP id f92so15725983qgf.0 for ; Tue, 03 May 2016 16:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0/OvbDEr20x9dQ4Ja4zkYiGnn8RlCpaJ04ubITfLgR8=; b=BJIyKW/pzAzeS/CBJqbmY4iCYbPAdN/DgPKJdCC8aSoqPfq0hfThiJUV6Qu+OaLSKa 73KxM5rmOrmXgwBj/UccR/2JwrmBhC2Cxaf8NPCTI56KQhG/nGe9OWhdJPaxAX71BcNV PI4+C9WWfRxbF7Y/6OeS/Ru2jOH2c8t3woBnQtEmivHUIGa6iOaVA9DH7kTA9hFmEk2w mdrJfmkN5uvZOHGGjjf9vagRLd1CGIXSxXGThILJciQWLHWFefMCMw6YpgAlHh408oxQ 9s9pXvAn2eyUnS0ecUoZp2riYsfJTVCUEKbdA4C8wMPfCKYK3QARvS8RgFZmNB2mF4G2 jElw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0/OvbDEr20x9dQ4Ja4zkYiGnn8RlCpaJ04ubITfLgR8=; b=k7YhoYd85/MCSsqLN01zV6zj05GGTHT6nhklXLAMf9/91meGJqE8S72NuITVIbwpxe 22Jra4Xse/CIqBSmJWKSyQzyQZbsPYHOajACB+oXX3oztaOWX8ptRRdrNCQAIURGCJeJ Jr18yCCu/K2gbxbeZJIuwaMjbAYMUjlH+wGZczfA32S1ZOD0Gu6XOQjIis/nh1BPIvBV Yq6PhQve25z0CpbSLK6lHll2V3aOM9MsjnaiFu9PNagKJAf1cRo16GhSxghtbG1sjD58 zsooXAPkC/EeqI9MEIkiGmN6niR/exPf5XTKD/5alvYenc/mfJ61jivtE/fOWQE9DWaG PN3Q== X-Gm-Message-State: AOPr4FXGLFSYTbY01O0kOPUecJ8Vemldc6vmNig0+Hjg2RUC2qxY2IXSOkMY3zFsDo+MmQ== X-Received: by 10.140.23.37 with SMTP id 34mr5521473qgo.14.1462317879205; Tue, 03 May 2016 16:24:39 -0700 (PDT) Received: from [192.168.1.54] (ool-4351ff55.dyn.optonline.net. [67.81.255.85]) by smtp.gmail.com with ESMTPSA id c206sm264462qha.45.2016.05.03.16.24.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2016 16:24:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TCP problems From: Mark Saad X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Tue, 3 May 2016 19:24:38 -0400 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8AD66D4F-F6E8-47E7-B7CE-F3CC9C6BDE75@longcount.org> References: To: Dieter BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 23:24:40 -0000 Dieter Sounds like you may have fired the nic on the G box . I had a supermicro e= 5-2620 board (x9d something) do something similar last week and nothing fixe= s it except replacement .=20 --- Mark Saad | nonesuch@longcount.org > On May 3, 2016, at 6:41 PM, Dieter BSD wrote: >=20 > I have suddenly started seeing TCP problems on a machine "G": > running FreeBSD 10.1 > Gigabyte UD5 amd64 > 2 Ethernet controllers, re0 and ue0: >=20 > re0: port > 0xb000-0xb0ff mem 0xfe600000-0xfe600fff,0xd0000000-0xd0003fff irq 16 > at device 0.0 on pci6 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: Chip rev. 0x4c000000 > re0: MAC rev. 0x00000000 > rgephy0: PHY 1 on miibus0 >=20 > ue0 is Siig USB-to-Ethernet Chipset: AX88179 >=20 > Problem 1: bind(2) fails > Problem 2: copying large files via Ethernet results in data corruption >=20 > 1) Bind: >=20 > C program containing: >=20 > bzero(&server, sizeof(struct sockaddr_in)); > server.sin_family=3DAF_INET; > server.sin_port=3Dhtons((unsigned short)port_number); > (void) memcpy((char*)&server.sin_addr, (char*)host->h_addr, > sizeof(server.sin_addr)); >=20 > return_code =3D socket(PF_INET, SOCK_STREAM, 0); > if (return_code =3D=3D -1) { fprintf(stderr, "%s: ERROR ", argv[0]); > perror("socket() failed"); fflush(stderr); exit(-1); } > fd =3D return_code; >=20 > return_code =3D bind(fd, (struct sockaddr*)&server, sizeof(server)); > if (return_code =3D=3D -1) { fprintf(stderr, "%s: ERROR ", argv[0]); > perror("bind() failed"); fflush(stderr); exit(-1); } >=20 > gives: ERROR bind() failed: Can't assign requested address >=20 > The same binary has been working perfectly on another machine (running 8.2= ) > for years. A UDP version of the program is working ok. Rebooting didn't h= elp. >=20 > 2) Data corruption: >=20 > rcp large file from machine T (running 8.2) to machine G (10.1) > rcp the file back from G to T > compare the two copies of the file on machine T to verify integrity >=20 > This worked fine until yesterday. Now suddenly most large files have data= > corruption, thus cmp(1) fails. The first difference occurs at various > places in the file. >=20 > Both machine have 2 gigabit Ethernet controllers (2 seperate networks). > Both networks have the problem. I have also tried different sata disks > on different disk controllers. Both machines are amd64 and have ECC memor= y. > Cables are factory made cat6 or cat7 25 foot or shorter. Netgear gigabit > switches. I tried using ftp instead of rcp. Rebooting didn't help. >=20 > machine T: > nfe0: flags=3D8843 metric 0 mtu 15= 00 > options=3D8210b > media: Ethernet autoselect (1000baseT > ) > bge0: flags=3D8843 metric 0 mtu 15= 00 > options=3D8009b > media: Ethernet autoselect (1000baseT > ) >=20 > machine G: > re0: flags=3D8843 metric 0 mtu 150= 0 > options=3D8209b > media: Ethernet autoselect (1000baseT ) > ue0: flags=3D8843 metric 0 mtu 150= 0 > options=3D8000b > media: Ethernet autoselect (1000baseT ) >=20 > I tried ifconfig -rxcsum -txcsum. Machine T seems happy, but > networking on machine G stopped working so I had to turn them back on. > (problem #3?) >=20 > Small files (2-4 KB) and things like telnet/rsh seem to work fine. >=20 > It appears that *something* broke yesterday, probably something in > machine G. But what? hardware? software? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Wed May 4 13:23:22 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A8A0B2BB7C for ; Wed, 4 May 2016 13:23:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 EB04F1E10 for ; Wed, 4 May 2016 13:23:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x244.google.com with SMTP id u185so6685591iod.2 for ; Wed, 04 May 2016 06:23:21 -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:from:date:message-id :subject:to:cc; bh=1PIu0k+10Bgjlk7vk4iyW/E6/PHJp9kqI5FYjinrzAE=; b=izMOYa8/5ffTohL+2NL+Ms7289S2+Yh+UfLHENtLISnc+ns7ZfSjmTZ3VQQfQzzaeO liWpf4xvXgNWk3Cn+lSnQXFbIzkOPgmtelTGs/3tqH8V3j0vvaia8I/u5l8vhoJGJqV1 UTWvbRM9itGgNYwcLt0gJaHi6iEaYdl2tySdOrfd7jl++gs6upW5P9liRd8hZyNY588D OBWTTzdtKMAKO0fnL6bReixI9zi7zT7h++AKPIPsanDtxUC/kX+UWBci/l5en76u11Oz g8XX6NO4FPAMVqKCJTGCFBg13U4DpF7bZ5YmiQbqeCXjiGFNQ4li9KjbY9BLlwzmlWgP r2CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1PIu0k+10Bgjlk7vk4iyW/E6/PHJp9kqI5FYjinrzAE=; b=VaRUgAAJTA8Uaqrtfjxbda/Y1nKUK29H8+G1zHHC51o96xfOWDGhBF71Xq/xGN41Lz 8/HiiCT8Oujtr+3NznkyjI009kd+qfbxOaqBvSQRB9nZlRzOf+y8QIGWhp2EMS+aAI/S Dt4d0C8GIeSF/iCOdjgpHEVRF6+Pqqa1NNkRo/GUCukPeNkyCj51xiDG0aqyX7WnmSNU YxTEGVuyvtzc9LKf2GGs/mQ4r/bCEYry9NbkrZzuRNfuAztzS7LZJxjULXHt5Pf7yv03 gmxl+fBatD//LIl8OBYjgYcUHakrB4aM6bPwB/byfBmryAiFG6UPaFwckjfHyLrebXmD hnrg== X-Gm-Message-State: AOPr4FX6gt1p2jecG3dljS7ZOzRxbAb127sbPeGBGFuoHbq5aP/+5AEZbHgK2XFpYgAyCb8iwH1PQuaCOzlevw== X-Received: by 10.107.147.138 with SMTP id v132mr9900506iod.38.1462368201343; Wed, 04 May 2016 06:23:21 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.27.197 with HTTP; Wed, 4 May 2016 06:23:01 -0700 (PDT) In-Reply-To: <65BAB92F-271C-489F-A804-6496B4953599@metricspace.net> References: <65BAB92F-271C-489F-A804-6496B4953599@metricspace.net> From: Ed Maste Date: Wed, 4 May 2016 09:23:01 -0400 X-Google-Sender-Auth: wGLLERBzOZ661E7_XCkGudpvE3I Message-ID: Subject: Re: Problem with objcopy corrupting section names To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 13:23:22 -0000 On 2 May 2016 at 18:25, Eric McCorkle wrote: > > I've run into a weird problem where the section names are seemingly being corrupted for boot1. The process to reproduce this should be simple: just build boot1 and then do objdump -x boot1.efi and you should see that the section names are corrupted. This could well be a bug in elfcopy's libpe - it's a new addition to the ELF Tool Chain project, and I have not tested it extensively outside of the plain boot1.efi and loader.efi. To confirm my understanding, this happens with your patched tree, but not stock FreeBSD? Also, in what way are they corrupted? It's expected that section will be truncated, as the COFF format only supports char[8] for the name. If you mail me (off-list) a copy of boot1.sym I'll take a look. From owner-freebsd-hackers@freebsd.org Thu May 5 06:20:59 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B59B2E59F for ; Thu, 5 May 2016 06:20:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A464A1CE4 for ; Thu, 5 May 2016 06:20:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u456KrKo098900 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 23:20:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Best option to process packet ACL To: =?UTF-8?Q?Z=c3=a9_Claudio_Pastore?= , freebsd-hackers@freebsd.org References: From: Julian Elischer Message-ID: Date: Thu, 5 May 2016 14:20:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 06:20:59 -0000 On 28/04/2016 3:21 AM, Z Claudio Pastore wrote: > Hello everyone, > > I would like to hear your suggestion regarding the best approach to process > IP packets for filtering, in such a way I can avoid lowering my pps rate. > > Today a have a simple application proxies http application. It's dual > threaded on a 4 core system with low CPU power. The current application > uses two threads, one for control and one for data flow processing. > > I need to implement a simple set of stateless filtering, I will process > only: > > - src-ip > - dst-ip > - src-port > - dst-port > - iplen > - proto (tcp/udp/other) why does a simple firewall not suffice? you say in another email, that you are more like a proxy.. then why not use the proxy support? (ipfw fwd) you are being a little secretive about this so it's hard to tell you what to do except that there are SO MANY ways of doing things with networking in FreeBSD that there will probably be several answers. > > My current rate of requests per second is high, around 200K. I have no idea > how I can leverage the IDLE CPUs the best way to implement this ACL > filtering trying not to impact on the pps rate I have today. 200k is not that high unless you are running on a Raspberry-pi. > I have implemented it serial today (not threaded) and I get 40% performance > loss. I will handle max 128 filter rules, this is a decision which is made. > This is going to be first match wins. so what's wrong with a firewall? > > My current plans are to test: > > 1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip, > etc) the first thread that returns false to parent thread I stop processing > that rule and go to the next, and tell all other threads to die/exit since > they don't matter anymore. > > 2) Create one thread to process a batch of rules, say, 8 rules per thread > per request. Don't know if I would limit total number of threads and lock > requests while threads ar e busy. > > 3) Someone suggested "do as pf/ipfw do" but I have no idea how it's done, > how multithreaded it is and what is done on each thread. you could do prepossessing with ipfw and the 'divert' facility feeding to a user process. you could use netgraph in about a dozen ways (writing your own module would be trivial, there are already about 50 to chose from as examples (not to mention the "sample" module). you could do preprocessing with pcap and use that interface. you could use netmap and have the packets turn up in your memory for examination. will you be looking at a subset of packets through an interface or everything on an interface? > > 4) Other suggestion? > > This is going to run FreeBSD 11, I use libevent2 on the current application > so far. need more information. also probably better in freebsd-net@ > > Thanks. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu May 5 06:27:33 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86FC2B2E85C for ; Thu, 5 May 2016 06:27:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FAE2110B; Thu, 5 May 2016 06:27:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u456RQr1098933 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 23:27:30 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Best option to process packet ACL To: Ze Claudio Pastore , Alan Somers References: Cc: "freebsd-hackers@freebsd.org" From: Julian Elischer Message-ID: Date: Thu, 5 May 2016 14:27:21 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 06:27:33 -0000 On 29/04/2016 5:21 AM, Ze Claudio Pastore wrote: > 2016-04-28 14:46 GMT-03:00 Jim Thompson : > >> If your application is already using DPDK then: >> >> 1) it’s not “mostly bypassing the kernel”, it *is* bypassing the kernel. >> >> 2) ACLs are already a thing in DPDK: >> http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html >> >> 200Kpps is not a lot of load for even ‘pf’ on slow hardware. >> >>> On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >>> >>> Even if your application is not a traditional firewall, using pf or ipfw >>> would save much development time compared to writing your own packet >>> filter. They can be configured to do things like redirect packets to >>> different ports. You can use that to offload packet filtering from your >>> application to the firewall, and open multiple sockets in your >> application >>> to receive prefiltered packets. >>> >>> Of course, pf/ipfw can't be used in combination with DPDK, as you >>> discovered. Doesn't DPDK provide access to each queue of a multiqueue >>> NIC? If so, you can create multiple filtering threads, and associate >> each >>> thread to a single queue of your NIC. >>> >>> Good luck, you've got a lot of work ahead of you. > ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information but on > a request basis not per packet, depending on other previous criteria I will > them split the processing, I am running a proxy so I am not looking to > replace my ACL needs by something else, only want to discuss how to better > process it, I have previous information from L7 affinity, headers, request > which helps me split some load, now I happen to need to filter it, it's not > a firewall, it's much like a squid based ACL need where you look for L3 > info on a different moment, ipfw/pf won't do it for me, ordinary firewall > fits somethwere else in the topology not in this application. ok so you have a bunch of options. If DPDK works for you, have you looked at netmap? If you are only interested in examining the first packet and then passing everything to a proxy, then use ipfw fwd, with a stateful rule. use a table with that rule if you have a number of filtering criteria. use multiple table and multiple fwd destinations. since we don't know what criteria, for how many rules it's hard to say.. you could feed everything into a netgraph module attached to your interface and write special purpose code. > > back on focus, I need to understand how to better split this load among > IDLE CPUs > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Thu May 5 15:32:37 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 971CFB2DC5C for ; Thu, 5 May 2016 15:32:37 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.181.253]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4F6126C for ; Thu, 5 May 2016 15:32:36 +0000 (UTC) (envelope-from trafdev@mail.ru) Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id D8331AF7B81A for ; Thu, 5 May 2016 18:32:32 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=1TGwwr/9pdwuTZekibT2NOxIwoMpxwtl4USNOyEZ4rk=; b=Nu+DNXYkZ6BAuAC4tpKYA6b8kaDDt0CfhU9SBBkrFw0Ufxj5jaKFMsmYl1ukR6yGg0hYzzfcRiip1aHng2Sf54VSIwKkOuDbOiu71sXlpxBsEkfIUNKzfLOQWt0LHyWnrZRhp+ocEuTOLCUs21gFKhM6+BssP3m60rHTFnesLuE=; Received: from c-50-156-112-176.hsd1.ca.comcast.net ([50.156.112.176]:12243 helo=[192.168.1.116]) by smtp41.i.mail.ru with esmtpa (envelope-from ) id 1ayLGJ-0007sx-5Y for freebsd-hackers@freebsd.org; Thu, 05 May 2016 18:32:23 +0300 Subject: Re: corrupted stack (backtrace) from sigaction handler To: freebsd-hackers@freebsd.org References: <94c8456c-a9b4-77a5-6622-418fc59d61d7@mail.ru> From: trafdev Message-ID: <6e191ad8-eb6e-769a-9a5c-f2bbe899971a@mail.ru> Date: Thu, 5 May 2016 08:32:19 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <94c8456c-a9b4-77a5-6622-418fc59d61d7@mail.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mras: OK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 15:32:37 -0000 Looks like it's a bug of FreeBSD - wherever an error occurs, user will see only 4 mentioned rows on a stack (using backtrace from a sigaction handler). In any Linux stack unwinds up to the place where error actually occurred. More outputs appreciated before creating a bug for a FreeBSD kernel. On 05/01/16 09:46, trafdev wrote: > Hello! > > Could you launch attached code on your machine and respond with an > output (and FreeBSD version). > > Here is mine (FreeBSD 10.2) output: > > stack dump [0] 0x40d4e5 <_Z9stackdumpPKc+0x85> at > /ara/devel/sandbox/new/cpp/Release/cpp > stack dump [1] 0x40dafd <_Z13signalHandleriP9__siginfoPv+0x3d> at > /ara/devel/sandbox/new/cpp/Release/cpp > stack dump [2] 0x801f30997 at /lib/libthr.so.3 > stack dump [3] 0x801f301a8 at > /lib/libthr.so.3 > > All info before signalHandler (foo/foo2 functions) is missed. From owner-freebsd-hackers@freebsd.org Fri May 6 16:33:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69B32B2F11E for ; Fri, 6 May 2016 16:33:43 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 462A0144D for ; Fri, 6 May 2016 16:33:42 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u46GXg5g028044 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 6 May 2016 09:33:42 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190] claimed to be yuri.doctorlan.com Subject: Re: Brief and intermittent system freezes To: freebsd-hackers@freebsd.org References: <57212CEC.6050105@rawbw.com> From: Yuri Message-ID: <572CC765.5090003@rawbw.com> Date: Fri, 6 May 2016 09:33:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <57212CEC.6050105@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:33:43 -0000 On 04/27/2016 14:19, Yuri wrote: > I changed the motherboard on the 10.3 desktop system and now I am > getting the "sticky mouse" effect: mouse briefly freezes every few > seconds. I think USB mouse events aren't propagated to the Xorg > process in a timely fashion. This also possibly makes the system > impaired in some other ways too. One thing I can think of is that the > network driver changed from re(4) to msk(4). For the record, I identified the problem: Marvell Yukon network card driver is faulty. I reported it on net@ Yuri From owner-freebsd-hackers@freebsd.org Fri May 6 23:20:26 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3132B318AF for ; Fri, 6 May 2016 23:20:26 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-9.server.virginmedia.net (know-smtprelay-omc-9.server.virginmedia.net [80.0.253.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1724A1B21 for ; Fri, 6 May 2016 23:20:25 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.10.211.13]) by know-smtprelay-9-imp with bizsmtp id rBKE1s0040HtmFq01BKEBw; Sat, 07 May 2016 00:19:14 +0100 X-Originating-IP: [86.10.211.13] X-Spam: 0 X-Authority: v=2.1 cv=OPvapnuB c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=NLZqzBF-AAAA:8 a=6I5d2MoRAAAA:8 a=9LI6vxruiO7Rz6e08TsA:9 a=4eBpnnOqY41wMC0C:21 a=xWWP1DFJarGCcUXG:21 a=QEXdDO2ut3YA:10 a=XdyKOaxJwVsA:10 a=ZUGwP7LCt9cA:10 a=YXNy2nbAtK8A:10 a=FSu5OgGmP5kA:10 a=wW_WBVUImv98JQXhvVPZ:22 a=IjZwj45LgO3ly-622nXo:22 Subject: nosh version 1.27 To: "supervision@list.skarnet.org" , FreeBSD Hackers , debian-user@lists.debian.org References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> <556BA130.50708@NTLWorld.com> <55902328.8080602@NTLWorld.com> <55D5CFA2.5010402@NTLWorld.com> <55D8B9AC.6010209@NTLWorld.com> <56089268.6080007@NTLWorld.com> <56120D11.4080506@NTLWorld.com> <5636C75B.70000@NTLWorld.com> <5672BD8C.50303@NTLWorld.com> <569617F3.8000101@NTLWorld.com> <56AEAED5.4010606@NTLWorld.com> From: Jonathan de Boyne Pollard Message-ID: <572D266D.6080807@NTLWorld.com> Date: Sat, 7 May 2016 00:19:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56AEAED5.4010606@NTLWorld.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:20:26 -0000 The nosh package is now up to version 1.27 . * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html * https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project In fact, it is soon to be version 1.28. This is a somewhat delayed notice for 1.27, because I forgot to send out the notices for versions 1.27 and 1.26 after updating the WWW site. As can be seen from the roadmap, we are at the point in rc.d conversion for FreeBSD/PC-BSD where it's actually easier to count the things that remain unconverted. Discounting the PC-BSD Active Directory services and a handful of suspect FreeBSD services (such as growfs, which doesn't apply to ZFS in the first place) the remaining things to be converted can be counted on the fingers of one hand. The external configuration import mechanism has gained the ability to handle stf, atabridge, mdconfig, and a few others. There are also a whole bunch more service bundles: cross-platform, for Linux, and for BSD. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/roadmap.html#FreeBSDrc.d The OOM Killer avoidance measures from version 1.25 are now employed in the PostgreSQL service bundle as well. The systemd service unit conversion tool has gained a whole load of NUMA-related extensions: NUMAInterleave, NUMAMemBind, NUMACPUNodeBind, NUMAPhysCPUBind, NUMALocalAlloc, and NUMAPreferred. These it translates into the equivalent invocations of the numactl chain-loading utility. It has also gained a couple of minor fixes and tweaks. The %m substitution now works, and service bundles comprising FIFOs or AF_LOCAL sockets are now created so that they are ordered after any relevant filesystem mount services. By request, the nosh Guide has gained a whole chapter of cheatsheets, giving quick one-liner pointers to some common tasks. The chapter is divided into three sections: chain loading, logging, and service management. The service management division is subdivided into daemontools-style commands, systemd-style commands, OpenBSD-style commands, SMF-style commands, and common commands. The chain loading division gives a number of the more common commands used in chain-loading run scripts (and whereever else one might want to use them). There have been improvements in static network setup, including fixes for some bugs in static_arp and static_ndp and a more cross-platform replacement for the static-networking service. The nosh-bundles package now supplies several aliases for services, which are just plain old symbolic links. So (for example) one can address the CUPS service as either org.cups.cupsd or just plain cupsd. Things to look forward to in version 1.28 already include: more service bundles; another chain-loading utility; a major revision to MySQL and MariaDB service bundling, to reflect the pushes by their own developers to obviate their rc scripts and the mysql-safe command and just run mysqld directly under service management using the tools provided by the service management system; and a change relevant to the all-important linux_logo command. (-: From owner-freebsd-hackers@freebsd.org Fri May 6 23:49:23 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14AC0B31140 for ; Fri, 6 May 2016 23:49:23 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) 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 DA581109F for ; Fri, 6 May 2016 23:49:22 +0000 (UTC) (envelope-from zclaudio@bsd.com.br) Received: by mail-ig0-x233.google.com with SMTP id m9so53418097ige.1 for ; Fri, 06 May 2016 16:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FySnS+iQ0aOQZvk/6yuvQywQ3Os/BKIVQ5wXZff23Dw=; b=aBiLW2ofs+RdOjUjhNduwxuWvUuGgI6WHE3Q5ws00THdwm5VQedNq+wqAEigBfcDbO GIao27sIxE2y5sVnnb3Ds4PvyRmrgGW9ftlyqV/TbikIoQw0MGfrrQQT+jUAiH4Lg7k6 ZHE8klorqItq6JxAR08VsqTdtBY6ofPT7VFI8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FySnS+iQ0aOQZvk/6yuvQywQ3Os/BKIVQ5wXZff23Dw=; b=Lx3NuyQU71EheBy73nScdaQUUNc8ZsH2lUBb1TZd3ssmNP+3btQbPvTJd9qAU9y3ZP WrQw5VSIZKq1M3f/OiRQeWdZZ32/5eqEsXUVazEe7Z/8jgwIIKOooOdvNpkL44hDTKXh kKuNUw9oEBYflSxzmQyRwXHVU2axUz4gNUTpDRnQ2LjFTbNhtgD/uQlTdDSxN9hGZTxe OWp80gVcwJsu5zVAdoktYnaJyPQdV4kEIt41SUzKtWTG4uJbQ56zMGaBT/9SMNW46XQO 80tPt/ZXT4ICQJK6UF+bpyc4XAmNJRFGcVsupXlodS3VJIsF2WLhAH7QnhfBJbuVjpsy RJ9w== X-Gm-Message-State: AOPr4FWtzbSz0cSQ2vPw5ipewFK7+El729AhfKUAoCL6AkeLb1/d7KuwMidOyjOPvRnOlHTAzgWafcDaEisryA== MIME-Version: 1.0 X-Received: by 10.50.143.1 with SMTP id sa1mr280218igb.20.1462578561812; Fri, 06 May 2016 16:49:21 -0700 (PDT) Received: by 10.107.29.16 with HTTP; Fri, 6 May 2016 16:49:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 May 2016 20:49:21 -0300 Message-ID: Subject: Re: Best option to process packet ACL From: Ze Claudio Pastore To: Julian Elischer Cc: Alan Somers , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:49:23 -0000 2016-05-05 3:27 GMT-03:00 Julian Elischer : > On 29/04/2016 5:21 AM, Ze Claudio Pastore wrote: > >> 2016-04-28 14:46 GMT-03:00 Jim Thompson : >> >> If your application is already using DPDK then: >>> >>> 1) it=E2=80=99s not =E2=80=9Cmostly bypassing the kernel=E2=80=9D, it *= is* bypassing the kernel. >>> >>> 2) ACLs are already a thing in DPDK: >>> http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html >>> >>> 200Kpps is not a lot of load for even =E2=80=98pf=E2=80=99 on slow hard= ware. >>> >>> On Apr 28, 2016, at 12:35 PM, Alan Somers wrote: >>>> >>>> Even if your application is not a traditional firewall, using pf or ip= fw >>>> would save much development time compared to writing your own packet >>>> filter. They can be configured to do things like redirect packets to >>>> different ports. You can use that to offload packet filtering from yo= ur >>>> application to the firewall, and open multiple sockets in your >>>> >>> application >>> >>>> to receive prefiltered packets. >>>> >>>> Of course, pf/ipfw can't be used in combination with DPDK, as you >>>> discovered. Doesn't DPDK provide access to each queue of a multiqueue >>>> NIC? If so, you can create multiple filtering threads, and associate >>>> >>> each >>> >>>> thread to a single queue of your NIC. >>>> >>>> Good luck, you've got a lot of work ahead of you. >>>> >>> ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information bu= t >> on >> a request basis not per packet, depending on other previous criteria I >> will >> them split the processing, I am running a proxy so I am not looking to >> replace my ACL needs by something else, only want to discuss how to bett= er >> process it, I have previous information from L7 affinity, headers, reque= st >> which helps me split some load, now I happen to need to filter it, it's >> not >> a firewall, it's much like a squid based ACL need where you look for L3 >> info on a different moment, ipfw/pf won't do it for me, ordinary firewal= l >> fits somethwere else in the topology not in this application. >> > ok so you have a bunch of options. > If DPDK works for you, have you looked at netmap? > > If you are only interested in examining the first packet and then passing > everything to a proxy, then use ipfw fwd, with a stateful rule. > use a table with that rule if you have a number of filtering criteria. > use multiple table and multiple fwd destinations. > since we don't know what criteria, for how many rules it's hard to say.. > > > you could feed everything into a netgraph module attached to your > interface and write special purpose code. hello mr elischer I was generally looking to discuss the best generic approach to test the acl match criterias taking best benefit on more CPUs as I mentioned I am looking for tipical L3 information but on a L7 payload, per request before I apply other application based criterias like headers, x-forwarded-for, etc, I know it looks like I need a firewall but it's in a different moment, a different application, that's why I'm interested on a discussion on how to best match ACL criterias and how to share the load among cpus denis suggested some stuff I am trying and measuring the performance benefits vs workload added, i'm still working on some numbers i'll share later i already have a typical networking firewall with ipfw in front of the environment, in a different box, but know i really need to match acls based on application needs not simple/plain network needs anymore, pretty much like a squid L3 based acl, but squid does not bring multithreaded suggestions for acl, I found several discussions on how people use external acl hooks to benefit performance so no good code examples there too i think if we keep the conversation in the usual firewall subject, my question would be what if I wanted ipfw to be multithreaded, how to do this? is the current approach the best one? does ipfw/pf/iptables works like mr denis mentioned it looks like, based on interrupt on multithreaded network drivers? say, like, if I run a monothreaded network NIC like rl(4) or vr(4) no matter if I have 1 or 36 CPUs, kernel based firewall will only benefit from 1, that's correct? what if I wanted to make it multithreaded, would I thread batches of rules? thread per packet? thread per match criteria? thread somehow else? not to thread? thread by other criteria? that is the discussion i tried to promote :)