From owner-freebsd-stable@freebsd.org Sun Aug 19 00:29:13 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91281107A701 for ; Sun, 19 Aug 2018 00:29:13 +0000 (UTC) (envelope-from SRS0=u+Y1=LC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 2C72F7E0D9 for ; Sun, 19 Aug 2018 00:29:12 +0000 (UTC) (envelope-from SRS0=u+Y1=LC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A95DA28416 for ; Sun, 19 Aug 2018 02:29:03 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C11EE28412 for ; Sun, 19 Aug 2018 02:29:02 +0200 (CEST) To: freebsd-stable@freebsd.org From: Miroslav Lachman <000.fbsd@quip.cz> Subject: changes in iostat output in 11.x vs 10.x Message-ID: <906cc905-5d1f-6792-e998-4bbd77d4f043@quip.cz> Date: Sun, 19 Aug 2018 02:29:01 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 00:29:13 -0000 I upgraded one of our servers from 10.4 to 11.2 and scripts using output of "iostat -x" are not working anymore. A checked the output of iostat and it is different. # on 10.4 # iostat -w 5 -c 2 -x ada0 ada1 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 51.5 28.3 1381.4 539.7 0 9.7 33 ada1 51.4 28.2 1381.5 539.7 0 10.1 34 extended device statistics device r/s w/s kr/s kw/s qlen svc_t %b ada0 0.2 6.4 2.4 136.5 0 2.9 2 ada1 0.0 5.8 0.0 136.5 0 3.4 2 # on 11.2 # iostat -w 5 -c 2 -x ada0 ada1 extended device statistics device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b ada0 6 24 35.9 697.9 2 1 77 3 0 6 ada1 6 23 34.9 697.9 2 1 77 3 0 6 extended device statistics device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b ada0 0 21 0.0 776.6 0 0 96 2 0 5 ada1 0 21 0.0 776.6 0 0 100 2 0 5 But I cannot find the explanation of new columns. The manpage seems the same for 10.4 and 11.2 The extended iostat device display, with the -x flag specified, shows the following statistics: r/s read operations per second w/s write operations per second kr/s kilobytes read per second kw/s kilobytes write per second qlen transactions queue length svc_t average duration of transactions, in milliseconds %b % of time the device had one or more outstanding transac- tions But there is no svc_t column anymore and there are ms/r ms/w ms/o and ms/t columns not mentioned in man page. Is it a documentation bug? Is ms/t the same what was previously known as svc_t? Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Sun Aug 19 14:30:48 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0F9106A3F7 for ; Sun, 19 Aug 2018 14:30:48 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A2C978FDF; Sun, 19 Aug 2018 14:30:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w7JEUeZO042417 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Aug 2018 07:30:40 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7JEUdIE042415; Sun, 19 Aug 2018 07:30:39 -0700 (PDT) (envelope-from jmg) Date: Sun, 19 Aug 2018 07:30:39 -0700 From: John-Mark Gurney To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org, will@FreeBSD.org Subject: Re: changes in iostat output in 11.x vs 10.x Message-ID: <20180819143039.GD97145@funkthat.com> Mail-Followup-To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable@freebsd.org, will@FreeBSD.org References: <906cc905-5d1f-6792-e998-4bbd77d4f043@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <906cc905-5d1f-6792-e998-4bbd77d4f043@quip.cz> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 19 Aug 2018 07:30:40 -0700 (PDT) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 14:30:48 -0000 Miroslav Lachman wrote this message on Sun, Aug 19, 2018 at 02:29 +0200: > I upgraded one of our servers from 10.4 to 11.2 and scripts using output > of "iostat -x" are not working anymore. > A checked the output of iostat and it is different. Looks like this was changed in r277566[1] by will. I've cc'd him. There is no documentation change associated w/ this change. [1] https://svnweb.freebsd.org/base?view=revision&revision=277566 > # on 10.4 > > # iostat -w 5 -c 2 -x ada0 ada1 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 51.5 28.3 1381.4 539.7 0 9.7 33 > ada1 51.4 28.2 1381.5 539.7 0 10.1 34 > extended device statistics > device r/s w/s kr/s kw/s qlen svc_t %b > ada0 0.2 6.4 2.4 136.5 0 2.9 2 > ada1 0.0 5.8 0.0 136.5 0 3.4 2 > > > # on 11.2 > > # iostat -w 5 -c 2 -x ada0 ada1 > extended device statistics > device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b > ada0 6 24 35.9 697.9 2 1 77 3 0 6 > ada1 6 23 34.9 697.9 2 1 77 3 0 6 > extended device statistics > device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b > ada0 0 21 0.0 776.6 0 0 96 2 0 5 > ada1 0 21 0.0 776.6 0 0 100 2 0 5 > > But I cannot find the explanation of new columns. The manpage seems the > same for 10.4 and 11.2 > > The extended iostat device display, with the -x flag specified, > shows the following statistics: > > r/s read operations per second > w/s write operations per second > kr/s kilobytes read per second > kw/s kilobytes write per second > qlen transactions queue length > svc_t average duration of transactions, in milliseconds > %b % of time the device had one or more outstanding transac- > tions > > But there is no svc_t column anymore and there are ms/r ms/w ms/o and > ms/t columns not mentioned in man page. > > Is it a documentation bug? > > Is ms/t the same what was previously known as svc_t? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@freebsd.org Sun Aug 19 21:01:36 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 502011077ECE for ; Sun, 19 Aug 2018 21:01:36 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 E4AB78AE8A for ; Sun, 19 Aug 2018 21:01:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A9BB71077EC8; Sun, 19 Aug 2018 21:01:35 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 989E61077EC5 for ; Sun, 19 Aug 2018 21:01:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF388AE84 for ; Sun, 19 Aug 2018 21:01:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 8B9231B8EF for ; Sun, 19 Aug 2018 21:01:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w7JL1YWW071544 for ; Sun, 19 Aug 2018 21:01:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7JL1Yvd071531 for stable@FreeBSD.org; Sun, 19 Aug 2018 21:01:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201808192101.w7JL1Yvd071531@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: stable@FreeBSD.org Subject: Problem reports for stable@FreeBSD.org that need special attention Date: Sun, 19 Aug 2018 21:01:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 21:01:36 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 227213 | FreeBSD 10.4 kernel deadlocks on sysctlmemlock 1 problems total for which you should take action. From owner-freebsd-stable@freebsd.org Mon Aug 20 13:33:02 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DDCC106DDFD for ; Mon, 20 Aug 2018 13:33:02 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E595A8D269 for ; Mon, 20 Aug 2018 13:33:01 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-qt0-x234.google.com with SMTP id b15-v6so16095516qtp.11 for ; Mon, 20 Aug 2018 06:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firepipe-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=3tvTIpTiAiFIE7YTulxoixd/ybATCzEpY7p6hIB9+fo=; b=X2/lRK+TSBJg3TfFP8ExHduxoz6pMu6dPc5OPsICFjZ0cD6xlcwGa8HSKy1U8L4CEZ LkH8C5GN1PvdS4vqSliAH3Z5AOP/CWHe4sdmSzImo2TnDr+Jjj7JnldRbJuJDscOLpSM XmVuj3IQBe7V2jUwCDKbsqlHqkg8rSBVzQ+70QQn7wslMYR80os/K46Ftpq+LG/mO6LZ XOzPXA6yt6LBKojRRhBPkJQp7RvvatYG116nqPg7ipyM6eu2HRn2t0Ys1T1fDYif1IQL 0jzc/UZupwCzb2tmAuDXtIeUBWJt064/1V+y6+c0je1coMc8aRRg+Y4IdqjJR+2XyVFZ Z31Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=3tvTIpTiAiFIE7YTulxoixd/ybATCzEpY7p6hIB9+fo=; b=tUJkwrUvAumhflmYZ/TireidReD4+IkkeGgm3v9+9ChXB4klHi69qzjUDG276lpLG3 gDnMst3NqIAqs+Jc9+CCiz51/dbZ9oBAAtXs6UcMriKG/zYT5t3F3njoQyOVYzN7r5nl xc0Ro8670YgFUEfjC/J9b04v0ppJPtTEy4UV/qC3u8SRbZPW8fvmlGfpwuT4I50hPx7I jzD4W5SdxDalurJ9k2njp/pz/EgfVIbK3VIMgFiiG0yk2XYHyCzqwAa+DVRvA9X4Sh6z UHPjLynthoVE8+56JaMgg5klxlpiwQYYAuEjmI2UuO4/eP2uC9SoTdkd37WihCxjB+ou kNZA== X-Gm-Message-State: APzg51CYY5RdLr+lMqXXPdy83YWTvlu1nhcIVh4M4Ar8kSQu+tIVodW7 xT4/E+8HnNlc5PJCedsXEygQaOM+n6f8hvF2idSMmQ== X-Google-Smtp-Source: ANB0VdZrhVoJxSewJP8WMVyn+y9fupKtoPYIM4ftpxX9p0QUFjIz6yR+TNsA1vgUa7pP+AR3p893Qxp0rVxADN6EMVo= X-Received: by 2002:a0c:d2d5:: with SMTP id x21-v6mr9750037qvh.214.1534771981046; Mon, 20 Aug 2018 06:33:01 -0700 (PDT) MIME-Version: 1.0 Sender: will@firepipe.net Received: by 2002:aed:3809:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 06:33:00 -0700 (PDT) In-Reply-To: <20180819143039.GD97145@funkthat.com> References: <906cc905-5d1f-6792-e998-4bbd77d4f043@quip.cz> <20180819143039.GD97145@funkthat.com> From: Will Andrews Date: Mon, 20 Aug 2018 08:33:00 -0500 X-Google-Sender-Auth: FZ4XvFJ85EPEmSbOyuwcgv9Id8c Message-ID: Subject: Re: changes in iostat output in 11.x vs 10.x To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-stable Stable , Will Andrews Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 13:33:02 -0000 On Sun, Aug 19, 2018 at 9:30 AM, John-Mark Gurney wrote: > Miroslav Lachman wrote this message on Sun, Aug 19, 2018 at 02:29 +0200: > > I upgraded one of our servers from 10.4 to 11.2 and scripts using output > > of "iostat -x" are not working anymore. > > A checked the output of iostat and it is different. > > Looks like this was changed in r277566[1] by will. I've cc'd him. There > is no documentation change associated w/ this change. > > [1] https://svnweb.freebsd.org/base?view=revision&revision=277566 Ah, yes, that should have been accompanied by a man page update. My bad, I'll fix it. ms/t is indeed what used to be svc_t. --Will. From owner-freebsd-stable@freebsd.org Mon Aug 20 14:25:44 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAE2E106F8F5 for ; Mon, 20 Aug 2018 14:25:44 +0000 (UTC) (envelope-from ddaniels@switchways.com) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5BDB28F528 for ; Mon, 20 Aug 2018 14:25:44 +0000 (UTC) (envelope-from ddaniels@switchways.com) Received: by mail-pl0-x241.google.com with SMTP id e11-v6so7223084plb.3 for ; Mon, 20 Aug 2018 07:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=switchways-com.20150623.gappssmtp.com; s=20150623; h=to:subject:from:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=THvRkcgJzSmRzGFgelsD1cXzQ6DAXg2gSTPNndfGSkU=; b=KRDZf70vv9ILpnyjYSCuwNDDl/queCEAGt8XP1tnctRCDihb1HWJp7eX3K1jCUIuW6 dVDt9ycFylm4GpRbpb0tsivmPdCACvl56DenfSfjxyTQro8GLAgjDf3ULn97gfRi9WSe RlpH/eCTpbu4mcT137VHselpVTkbHt+0cUqCLqTesloueEUOd3pxtq1nw9XcnX3KgooA /3iKtOelmvA1CFpIt4v66m1J9/xKi41OAIJV96Il1lt0hmlGodHZm72VqoIbk+be9doN MhRLUb2/Z9vTnDwogBHIFXKf4BHQzg+WxhMapJiIYRDB1s+EkJwqS8xqq8SbyUZzrTBN 2Efw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:subject:from:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=THvRkcgJzSmRzGFgelsD1cXzQ6DAXg2gSTPNndfGSkU=; b=XQJjNj7u6F7oDfE2XgKg6Why2hvdbZeOFkqRcOmUjpNzYxXpJ0XFKVVqXjJo4XX/jW TvvcLRPquyc4uoVIglIuEdaCIx5jAWoEx/5ESDpkX030KSKpB1Z227ab5RrMTSm+eROG +i/40hQ6xWVtRqy8NN9LrSKmlKB+vyS/ATkY8BjR23ttJhJKSpDU6Fpky/Xaqm7x9bEz qLGJgSpEUmyqsMPa+Ne157bTlN7eKTmNK+x5WJQ1xAMx7j6xhcb1jM91UxZ+y2n6B3V1 QJE7nZFyUAetQiXqAESX4qmJJpg9rRcZhXJ+9N8Sm84iv1Nw7xSBYvBWINVfwWLkdITs upOg== X-Gm-Message-State: AOUpUlESPO8ZTBHSB6EVcoet1ZtR0COAOTE39NgSaE0tO45xA8P1P8Dc zXR2tErQK4bViS/ca3Jnb2oW90zHflI= X-Google-Smtp-Source: AA+uWPwyGOVaGSpRaocy8vWAa6lo5ZzhTx3QrkZPFVqlbxuMsJFXRs8e8Ca2RtFm0t7/gfJZUdTNMg== X-Received: by 2002:a17:902:1566:: with SMTP id b35-v6mr45479467plh.135.1534775143301; Mon, 20 Aug 2018 07:25:43 -0700 (PDT) Received: from [192.168.0.9] ([103.6.157.158]) by smtp.gmail.com with ESMTPSA id l85-v6sm17053974pfk.34.2018.08.20.07.25.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 07:25:42 -0700 (PDT) To: freebsd-stable@freebsd.org Subject: Truck Owners List From: Diana Daniels Message-ID: <2b8b5800-4d13-ca0f-7f0e-8e67ad3ca1be@switchways.com> Date: Mon, 20 Aug 2018 09:55:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:25:45 -0000 Hi, Greeting of the day! Would you be interested in acquiring an email list of "Truck Owners" from USA? We also have data for Cruise Travelers, Boat Owners, Travelers List, RV Owners List, Spa and Resorts List, Scuba Divers List, Fishing Enthusiasts List, Apparel Buyers, Luxury Brand Buyers, Gift buyers and many more. Each record in the list contains Contact Name (First and Last Name), Mailing Address, List type and Opt-in email address. All the contacts are opt-in verified,complete permission based and can be used for unlimited multi-channel marketing. Let me know if you'd be interested in hearing more information about it. Waiting for your valuable and sincere reply. Best Regards, Diana Daniels Research Analyst From owner-freebsd-stable@freebsd.org Mon Aug 20 14:31:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 454D9106FD4E for ; Mon, 20 Aug 2018 14:31:01 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) 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 C0A7A8FA8E for ; Mon, 20 Aug 2018 14:31:00 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 86295106FD47; Mon, 20 Aug 2018 14:31:00 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63DDF106FD46 for ; Mon, 20 Aug 2018 14:31:00 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 000C58FA83 for ; Mon, 20 Aug 2018 14:30:59 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw1-xc2d.google.com with SMTP id n207-v6so1797725ywn.9 for ; Mon, 20 Aug 2018 07:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hOhqWNpDyvS/7J+l5q7JNH28MCYOpfC5a7aYE8R9ZaA=; b=FPnT2Oq6qQGzZQaGkATz/d4GSAV+9HMRdSq6qRbUyBiVhHsbvMryG6IIgvPuZGUsQ/ BrGeCb4MCcNRVEn5y0nbOauXoWwhxU51Wl/ubpV0lIbqcDcoKkMBG4VbIz4E9He4iY4o aGIoKmKFNSrf0wTWQLXBd1m1SKArZRqCmHeZ1GJjYg19kSrDMciMoSTp/YkcliA3uiPz geH8tqs81rzWFGqmguvZe+WoF+gkJTO2MzIrFhjOeVakCPwzkOsBq8WlzUnhPcaRW/vl 57yAHeF3qYA+pF+gdx716/v6KH30KkxjJyXSHoetln5fkKRUL5YWb/7mKTlTLxEqiOTd H4hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hOhqWNpDyvS/7J+l5q7JNH28MCYOpfC5a7aYE8R9ZaA=; b=O0TtgjG9/8kE80IytzAW/ZtFnEf2pK3UexHwdSTblAnitphLp3aB06MLEtwMJf0MZf lGXmMnLaO4LG69XfTW5APXbLCGIejZwZ4AQGOYlJ6VeYnf6btjyn4fKuka7Dikuu9jGv V78LEJ65SNfRaLkWCkuraW7xc2CE805SZzrgJK24a/TTKXRhgLeaw9oBF2E+1OMMJXRu 5ohG7YZgm0ERiKmO6jvBEAypI6j8xc80p+8aJaFHkY5/nx4L7nl5DTQ2ve1olmvllI/B 68TzMQ0oXYFE1Wnr32CGNSwMsiNfZSBBWAkYBS+rkPd5sktWQ7Tz32k3IzpDm1YHd0hL 98oA== X-Gm-Message-State: AOUpUlFguhxRYPxoXn+qwQlICOAa7Apjmb8K0tmBcrDrltkA7AgA+PFX MlJ0oEJQ7EM2GxfUntFHocaRRh/QD1wBVtetgE9MDEbYHRU= X-Google-Smtp-Source: AA+uWPzPnu1g03yNmGJElBna3BGhcO9ShcYYC/zE6KRK+nzK8yoh3d/cIDI3p4cUX3GA9uQmFrJAImqYauK6qAq1Qiw= X-Received: by 2002:a81:6b8a:: with SMTP id g132-v6mr6521188ywc.267.1534775459548; Mon, 20 Aug 2018 07:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:f205:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 07:30:58 -0700 (PDT) In-Reply-To: <20AA7D33-904F-494B-830F-59E09DC267E5@lists.zabbadoz.net> References: <5428C6C5-5627-44DD-A4ED-AF28A305C4F4@lists.zabbadoz.net> <20AA7D33-904F-494B-830F-59E09DC267E5@lists.zabbadoz.net> From: Oliver Pinter Date: Mon, 20 Aug 2018 16:30:58 +0200 Message-ID: Subject: Re: VNET related kernel panic on jail startup with epairs on 11-STABLE To: "Bjoern A. Zeeb" Cc: stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:31:01 -0000 On 8/3/18, Bjoern A. Zeeb wrote: > On 3 Aug 2018, at 20:42, Oliver Pinter wrote: > >> On 8/3/18, Bjoern A. Zeeb wrote: >>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote: >>> >>>> Hi all! >>>> >>>> One of out users observed an VNET related kernel panic with epairs >>>> in >>>> a jail. Seems like some of the >>> >>> Well would be great for a start to (a) email virtualisation@ as well, >>> (b) include a panic message, backtrace or other related information >>> to >>> deduce anything about the possible bug, (c) and not to conflate it >>> with >>> another totally unrelated MFC request. >>> >>> So what makes you think it=E2=80=99s related to tcp fast open? >> >> Every required detail is in HardenedBSD's github issue, but I copy the >> kernel panic here: > > Ah sorry my bad; the issue said ZFS in the subject and I thought it > refers to something else. > > Thanks! Looking at the backtrace it seems it is happening on teardown > and not on startup but indeed in the fast open code and that PR 216613 > indeed fixed this in head, good :) Hope Patrick will do the mfc for > you. Hi! Could you please you or Patrick MFC the above commits? > > /bz > From owner-freebsd-stable@freebsd.org Mon Aug 20 14:47:22 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D30A510705A3 for ; Mon, 20 Aug 2018 14:47:22 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7768670650 for ; Mon, 20 Aug 2018 14:47:22 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 8FCAD1EFCC0 for ; Mon, 20 Aug 2018 14:47:20 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Bind to port <1024 in jail Message-Id: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> Date: Mon, 20 Aug 2018 16:47:18 +0200 To: FreeBSD Stable X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:47:23 -0000 I have a Go program (acme-dns) that wants to bind 53, 80, and 443, and = I=E2=80=99d rather have it run as a non-privileged user. The program = doesn=E2=80=99t provide a facility to drop privs after binding the = ports. I=E2=80=99m planning to run it in a jail. After some googling, it appears that a couple of years ago I should have = been able to do: sysctl net.inet.ip.portrange.reservedhigh=3D0 and allow all processes to bind to =E2=80=9Elow=E2=80=9C ports. This = does not work in my jails on a 11-stable host. $ sudo sysctl net.inet.ip.portrange.reservedhigh=3D0 net.inet.ip.portrange.reservedhigh: 1023 sysctl: net.inet.ip.portrange.reservedhigh=3D0: Operation not permitted Securelevel should not interfere: $ sysctl kern.securelevel kern.securelevel: -1 Is there a way to allow regular processes to bind to low ports? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@freebsd.org Mon Aug 20 14:59:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0141A1070B76 for ; Mon, 20 Aug 2018 14:59:24 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 916F071037 for ; Mon, 20 Aug 2018 14:59:23 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B8F7125D37D1; Mon, 20 Aug 2018 14:59:20 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 17849D1F8E6; Mon, 20 Aug 2018 14:59:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id LhTCHd0T4Ntq; Mon, 20 Aug 2018 14:59:17 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 981EED1F868; Mon, 20 Aug 2018 14:59:17 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Stefan Bethke" Cc: "FreeBSD Stable" Subject: Re: Bind to port <1024 in jail Date: Mon, 20 Aug 2018 14:59:16 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: In-Reply-To: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:59:24 -0000 On 20 Aug 2018, at 14:47, Stefan Bethke wrote: > I have a Go program (acme-dns) that wants to bind 53, 80, and 443, and > I’d rather have it run as a non-privileged user. The program > doesn’t provide a facility to drop privs after binding the ports. > I’m planning to run it in a jail. > > After some googling, it appears that a couple of years ago I should > have been able to do: > sysctl net.inet.ip.portrange.reservedhigh=0 > and allow all processes to bind to „low“ ports. This does not work > in my jails on a 11-stable host. > > $ sudo sysctl net.inet.ip.portrange.reservedhigh=0 > net.inet.ip.portrange.reservedhigh: 1023 > sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not permitted > > Securelevel should not interfere: > $ sysctl kern.securelevel > kern.securelevel: -1 > > Is there a way to allow regular processes to bind to low ports? you have to set it on the base system; alternatively with vnet you might be able to change it per-jail. /bz From owner-freebsd-stable@freebsd.org Mon Aug 20 14:59:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A6BD1070B8F for ; Mon, 20 Aug 2018 14:59:33 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0133771040 for ; Mon, 20 Aug 2018 14:59:32 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7KExNjG052690 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Aug 2018 16:59:24 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7KExIAL075971 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Aug 2018 21:59:19 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bind to port <1024 in jail To: Stefan Bethke , FreeBSD Stable References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> From: Eugene Grosbein Message-ID: <6bfc8608-946d-39eb-cc57-88b3dc3bd7c5@grosbein.net> Date: Mon, 20 Aug 2018 21:59:14 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:59:33 -0000 20.08.2018 21:47, Stefan Bethke wrote: > I have a Go program (acme-dns) that wants to bind 53, 80, and 443, and I’d rather have it run as a non-privileged user. The program doesn’t provide a facility to drop privs after binding the ports. I’m planning to run it in a jail. > > After some googling, it appears that a couple of years ago I should have been able to do: > sysctl net.inet.ip.portrange.reservedhigh=0 > and allow all processes to bind to „low“ ports. This does not work in my jails on a 11-stable host. > > $ sudo sysctl net.inet.ip.portrange.reservedhigh=0 > net.inet.ip.portrange.reservedhigh: 1023 > sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not permitted > > Securelevel should not interfere: > $ sysctl kern.securelevel > kern.securelevel: -1 > > Is there a way to allow regular processes to bind to low ports? Yes. Just use mac_portacl kernel module: kldload mac_portacl Once loaded, it duplicates net.inet.ip.portrange.reservedhigh protection with its own security.mac.portacl.port_high, so it's safe to disable "reservedhigh" for whole system by running sysctl net.inet.ip.portrange.reservedhigh=0 for host. The trick is that mac_portacl provides a way to selectively give permission for non-root UID to bind low ports: security.mac.portacl.rules=uid:88:tcp:80,uid:88:tcp:443,uid:53:tcp:53,uid:53:udp:53 It works just fine for a host and I use it for name servers utilizing port 53 for a box with dynamically created interfaces, so it may bind the port for distinct IP addresses after it dropped privilegies when new interface is created and get new IP assigned. I have not tried it for a jails, though. Please try and respond. From owner-freebsd-stable@freebsd.org Mon Aug 20 15:02:06 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13E601070DC5 for ; Mon, 20 Aug 2018 15:02:06 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB84271447 for ; Mon, 20 Aug 2018 15:02:05 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C09D21EFDAB; Mon, 20 Aug 2018 15:02:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Bind to port <1024 in jail From: Stefan Bethke In-Reply-To: <6bfc8608-946d-39eb-cc57-88b3dc3bd7c5@grosbein.net> Date: Mon, 20 Aug 2018 17:02:03 +0200 Cc: FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <89646FDB-F1A9-4070-87EC-22C0CFAFF4E7@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <6bfc8608-946d-39eb-cc57-88b3dc3bd7c5@grosbein.net> To: Eugene Grosbein X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 15:02:06 -0000 Am 20.08.2018 um 16:59 schrieb Eugene Grosbein : >=20 > 20.08.2018 21:47, Stefan Bethke wrote: >=20 >> I have a Go program (acme-dns) that wants to bind 53, 80, and 443, = and I=E2=80=99d rather have it run as a non-privileged user. The = program doesn=E2=80=99t provide a facility to drop privs after binding = the ports. I=E2=80=99m planning to run it in a jail. >>=20 >> After some googling, it appears that a couple of years ago I should = have been able to do: >> sysctl net.inet.ip.portrange.reservedhigh=3D0 >> and allow all processes to bind to =E2=80=9Elow=E2=80=9C ports. This = does not work in my jails on a 11-stable host. >>=20 >> $ sudo sysctl net.inet.ip.portrange.reservedhigh=3D0 >> net.inet.ip.portrange.reservedhigh: 1023 >> sysctl: net.inet.ip.portrange.reservedhigh=3D0: Operation not = permitted >>=20 >> Securelevel should not interfere: >> $ sysctl kern.securelevel >> kern.securelevel: -1 >>=20 >> Is there a way to allow regular processes to bind to low ports? >=20 > Yes. Just use mac_portacl kernel module: kldload mac_portacl >=20 > Once loaded, it duplicates net.inet.ip.portrange.reservedhigh = protection > with its own security.mac.portacl.port_high, so it's safe to disable > "reservedhigh" for whole system by running sysctl = net.inet.ip.portrange.reservedhigh=3D0 > for host. >=20 > The trick is that mac_portacl provides a way to selectively give = permission for non-root UID > to bind low ports: >=20 > = security.mac.portacl.rules=3Duid:88:tcp:80,uid:88:tcp:443,uid:53:tcp:53,ui= d:53:udp:53 >=20 > It works just fine for a host and I use it for name servers utilizing = port 53 > for a box with dynamically created interfaces, so it may bind the port = for distinct IP addresses > after it dropped privilegies when new interface is created and get new = IP assigned. >=20 > I have not tried it for a jails, though. Please try and respond. Thanks, but do I understand correctly that the = security.mac.portacl.rules are system-wide and not per-jail? I=E2=80=99m running ~10 jails on this host, and I don=E2=80=99t want to = allow all of them to bind to low ports. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@freebsd.org Mon Aug 20 15:04:54 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6BEC610711DC for ; Mon, 20 Aug 2018 15:04:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 F0F6A71801 for ; Mon, 20 Aug 2018 15:04:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 62fe64d6-a48a-11e8-904b-1d2e466b3c59 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 62fe64d6-a48a-11e8-904b-1d2e466b3c59; Mon, 20 Aug 2018 15:04:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7KF4oqx088141; Mon, 20 Aug 2018 09:04:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1534777490.27158.47.camel@freebsd.org> Subject: Re: Bind to port <1024 in jail From: Ian Lepore To: Stefan Bethke , FreeBSD Stable Date: Mon, 20 Aug 2018 09:04:50 -0600 In-Reply-To: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 15:04:54 -0000 On Mon, 2018-08-20 at 16:47 +0200, Stefan Bethke wrote: > I have a Go program (acme-dns) that wants to bind 53, 80, and 443, > and Id rather have it run as a non-privileged user.The program > doesnt provide a facility to drop privs after binding the ports. Im > planning to run it in a jail. > > After some googling, it appears that a couple of years ago I should > have been able to do: > sysctl net.inet.ip.portrange.reservedhigh=0 > and allow all processes to bind to low ports. This does not work in > my jails on a 11-stable host. > > $ sudo sysctl net.inet.ip.portrange.reservedhigh=0 > net.inet.ip.portrange.reservedhigh: 1023 > sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not permitted > > Securelevel should not interfere: > $ sysctl kern.securelevel > kern.securelevel: -1 > > Is there a way to allow regular processes to bind to low ports? > > > Stefan > You might be able to set up a specific local userid for this process, then use mac_portacl(4) to allow it to bind to those ports. I'm not certain that works inside a jail, however. -- Ian From owner-freebsd-stable@freebsd.org Mon Aug 20 15:10:09 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 975981071690 for ; Mon, 20 Aug 2018 15:10:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 2185371CBF for ; Mon, 20 Aug 2018 15:10:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 1a5d7f99-a48b-11e8-93fa-f3ebd9db2b94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1a5d7f99-a48b-11e8-93fa-f3ebd9db2b94; Mon, 20 Aug 2018 15:10:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7KF9wTv088159; Mon, 20 Aug 2018 09:09:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1534777798.27158.50.camel@freebsd.org> Subject: Re: Bind to port <1024 in jail From: Ian Lepore To: Stefan Bethke , Eugene Grosbein Cc: FreeBSD Stable Date: Mon, 20 Aug 2018 09:09:58 -0600 In-Reply-To: <89646FDB-F1A9-4070-87EC-22C0CFAFF4E7@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <6bfc8608-946d-39eb-cc57-88b3dc3bd7c5@grosbein.net> <89646FDB-F1A9-4070-87EC-22C0CFAFF4E7@lassitu.de> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 15:10:09 -0000 On Mon, 2018-08-20 at 17:02 +0200, Stefan Bethke wrote: > Am 20.08.2018 um 16:59 schrieb Eugene Grosbein : > > > > > > 20.08.2018 21:47, Stefan Bethke wrote: > > > > > > > > I have a Go program (acme-dns) that wants to bind 53, 80, and > > > 443, and Id rather have it run as a non-privileged user.The > > > program doesnt provide a facility to drop privs after binding > > > the ports. Im planning to run it in a jail. > > > > > > After some googling, it appears that a couple of years ago I > > > should have been able to do: > > > sysctl net.inet.ip.portrange.reservedhigh=0 > > > and allow all processes to bind to low ports. This does not > > > work in my jails on a 11-stable host. > > > > > > $ sudo sysctl net.inet.ip.portrange.reservedhigh=0 > > > net.inet.ip.portrange.reservedhigh: 1023 > > > sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not > > > permitted > > > > > > Securelevel should not interfere: > > > $ sysctl kern.securelevel > > > kern.securelevel: -1 > > > > > > Is there a way to allow regular processes to bind to low ports? > > Yes. Just use mac_portacl kernel module: kldload mac_portacl > > > > Once loaded, it duplicates net.inet.ip.portrange.reservedhigh > > protection > > with its own security.mac.portacl.port_high, so it's safe to > > disable > > "reservedhigh" for whole system by running sysctl > > net.inet.ip.portrange.reservedhigh=0 > > for host. > > > > The trick is that mac_portacl provides a way to selectively give > > permission for non-root UID > > to bind low ports: > > > > security.mac.portacl.rules=uid:88:tcp:80,uid:88:tcp:443,uid:53:tcp: > > 53,uid:53:udp:53 > > > > It works just fine for a host and I use it for name servers > > utilizing port 53 > > for a box with dynamically created interfaces, so it may bind the > > port for distinct IP addresses > > after it dropped privilegies when new interface is created and get > > new IP assigned. > > > > I have not tried it for a jails, though. Please try and respond. > Thanks, but do I understand correctly that the > security.mac.portacl.rules are system-wide and not per-jail? > > Im running ~10 jails on this host, and I dont want to allow all of > them to bind to low ports. > Portacls are configure by userid. Just create a local userid that is dedicated to this one process that runs in the one jail, and only it (and root of course) would be able to bind to those ports. -- Ian From owner-freebsd-stable@freebsd.org Mon Aug 20 15:15:25 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A5F11071C69 for ; Mon, 20 Aug 2018 15:15:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C3957722E3 for ; Mon, 20 Aug 2018 15:15:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7KFFGA7052835 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Aug 2018 17:15:17 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7KFFDFw076225 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Aug 2018 22:15:13 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bind to port <1024 in jail To: Stefan Bethke References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <6bfc8608-946d-39eb-cc57-88b3dc3bd7c5@grosbein.net> <89646FDB-F1A9-4070-87EC-22C0CFAFF4E7@lassitu.de> Cc: FreeBSD Stable From: Eugene Grosbein Message-ID: Date: Mon, 20 Aug 2018 22:15:08 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <89646FDB-F1A9-4070-87EC-22C0CFAFF4E7@lassitu.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 15:15:25 -0000 20.08.2018 22:02, Stefan Bethke wrote: >> The trick is that mac_portacl provides a way to selectively give permission for non-root UID >> to bind low ports: >> >> security.mac.portacl.rules=uid:88:tcp:80,uid:88:tcp:443,uid:53:tcp:53,uid:53:udp:53 >> >> It works just fine for a host and I use it for name servers utilizing port 53 >> for a box with dynamically created interfaces, so it may bind the port for distinct IP addresses >> after it dropped privilegies when new interface is created and get new IP assigned. >> >> I have not tried it for a jails, though. Please try and respond. > > Thanks, but do I understand correctly that the security.mac.portacl.rules are system-wide and not per-jail? It seems so. It is small kernel module and it should not be so hard to make it VNET-aware for one already familiar with the code. You may want to fill a PR for that, so it would became possible to have per-jail settings for VIMAGE-enabled jails. From owner-freebsd-stable@freebsd.org Mon Aug 20 16:09:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B47011073DA5 for ; Mon, 20 Aug 2018 16:09:28 +0000 (UTC) (envelope-from bounce@ims11.isendservice.com.br) Received: from ims11.isendservice.com.br (ims11.isendservice.com.br [54.232.115.234]) by mx1.freebsd.org (Postfix) with ESMTP id 2ED93747F9 for ; Mon, 20 Aug 2018 16:09:27 +0000 (UTC) (envelope-from bounce@ims11.isendservice.com.br) Received: from localhost (localhost [127.0.0.1]) by ims11.isendservice.com.br (Postfix) with ESMTP id E4C6F425A4 for ; Mon, 20 Aug 2018 13:07:09 -0300 (BRT) Date: Mon, 20 Aug 2018 13:07:09 -0300 (BRT) From: =?utf-8?Q?Sistema=20FIERGS=20=7C=20SENAI-RS?= Reply-To: faculdadesenai@senairs.org.br To: freebsd-stable@freebsd.org Message-ID: <2054192928.971108.1534781229741.JavaMail.root@ims11> Subject: =?utf-8?Q?Portas=20Abertas=20SENAI=20=7C=20Porto=20Alegre=20=7C=2025=20de=20agosto?= bounce-key: <2420-22522874-2214007> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 16:09:28 -0000 From owner-freebsd-stable@freebsd.org Mon Aug 20 16:22:21 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75B94107461C for ; Mon, 20 Aug 2018 16:22:21 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 188247532F for ; Mon, 20 Aug 2018 16:22:21 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 18B651F013A; Mon, 20 Aug 2018 16:22:13 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Bind to port <1024 in jail From: Stefan Bethke In-Reply-To: Date: Mon, 20 Aug 2018 18:22:11 +0200 Cc: FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 16:22:21 -0000 > Am 20.08.2018 um 16:59 schrieb Bjoern A. Zeeb = : >=20 > On 20 Aug 2018, at 14:47, Stefan Bethke wrote: >=20 >> I have a Go program (acme-dns) that wants to bind 53, 80, and 443, = and I=E2=80=99d rather have it run as a non-privileged user. The = program doesn=E2=80=99t provide a facility to drop privs after binding = the ports. I=E2=80=99m planning to run it in a jail. >>=20 >> After some googling, it appears that a couple of years ago I should = have been able to do: >> sysctl net.inet.ip.portrange.reservedhigh=3D0 >> and allow all processes to bind to =E2=80=9Elow=E2=80=9C ports. This = does not work in my jails on a 11-stable host. >>=20 >> $ sudo sysctl net.inet.ip.portrange.reservedhigh=3D0 >> net.inet.ip.portrange.reservedhigh: 1023 >> sysctl: net.inet.ip.portrange.reservedhigh=3D0: Operation not = permitted >>=20 >> Securelevel should not interfere: >> $ sysctl kern.securelevel >> kern.securelevel: -1 >>=20 >> Is there a way to allow regular processes to bind to low ports? >=20 > you have to set it on the base system; alternatively with vnet you = might be able to change it per-jail. Do you feel it=E2=80=99s OK to enable VIMAGE in -stable? When I tried = last in 2016, I had stability issues, I think related to pf. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@freebsd.org Mon Aug 20 16:32:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D42C71074C31 for ; Mon, 20 Aug 2018 16:32:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FFDA75F56 for ; Mon, 20 Aug 2018 16:32:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A59E725D37D1; Mon, 20 Aug 2018 16:32:30 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0A617D1F8E6; Mon, 20 Aug 2018 16:32:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CSJ5kH06YdQv; Mon, 20 Aug 2018 16:32:29 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BB447D1F868; Mon, 20 Aug 2018 16:32:28 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Stefan Bethke" Cc: "FreeBSD Stable" Subject: Re: Bind to port <1024 in jail Date: Mon, 20 Aug 2018 16:32:27 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <30A6405A-6DC1-461E-B45D-CFFF659F80F8@lists.zabbadoz.net> In-Reply-To: <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 16:32:34 -0000 On 20 Aug 2018, at 16:22, Stefan Bethke wrote: >>> Is there a way to allow regular processes to bind to low ports? >> >> you have to set it on the base system; alternatively with vnet you >> might be able to change it per-jail. > > Do you feel it’s OK to enable VIMAGE in -stable? When I tried last > in 2016, I had stability issues, I think related to pf. “If you know what you are doing it won’t panic” ;-) I think with 12 I’d be a lot more confident about stability. Most fixes could not and were not MFCed. /bz From owner-freebsd-stable@freebsd.org Mon Aug 20 16:35:59 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B8681074D5A for ; Mon, 20 Aug 2018 16:35:59 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B40E276367 for ; Mon, 20 Aug 2018 16:35:58 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id C596D1F0196; Mon, 20 Aug 2018 16:35:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Bind to port <1024 in jail From: Stefan Bethke In-Reply-To: <30A6405A-6DC1-461E-B45D-CFFF659F80F8@lists.zabbadoz.net> Date: Mon, 20 Aug 2018 18:35:55 +0200 Cc: FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> <30A6405A-6DC1-461E-B45D-CFFF659F80F8@lists.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 16:35:59 -0000 > Am 20.08.2018 um 18:32 schrieb Bjoern A. Zeeb = : >=20 > On 20 Aug 2018, at 16:22, Stefan Bethke wrote: >=20 >>>> Is there a way to allow regular processes to bind to low ports? >>>=20 >>> you have to set it on the base system; alternatively with vnet you = might be able to change it per-jail. >>=20 >> Do you feel it=E2=80=99s OK to enable VIMAGE in -stable? When I tried = last in 2016, I had stability issues, I think related to pf. >=20 > =E2=80=9CIf you know what you are doing it won=E2=80=99t panic=E2=80=9D = ;-) I think with 12 I=E2=80=99d be a lot more confident about = stability. Most fixes could not and were not MFCed. OK then, should I move to -current and try there? I=E2=80=99ve not = tracked -current on a production box in years (I think the last time was = around 3 or 4), but I=E2=80=99m willing to give it a go, seeing that the = code freeze is about to start. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@freebsd.org Mon Aug 20 16:36:03 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE60C1074D71 for ; Mon, 20 Aug 2018 16:36:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5386376375 for ; Mon, 20 Aug 2018 16:36:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7KGZtKR053347 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Aug 2018 18:35:56 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7KGZqb7080868 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Aug 2018 23:35:52 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bind to port <1024 in jail To: Stefan Bethke , "Bjoern A. Zeeb" References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> Cc: FreeBSD Stable From: Eugene Grosbein Message-ID: <939ad473-caad-e1f7-5d70-56eed9d5de65@grosbein.net> Date: Mon, 20 Aug 2018 23:35:47 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2FA29D2E-7C15-4C9D-A59B-98E9EA916891@lassitu.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 16:36:04 -0000 20.08.2018 23:22, Stefan Bethke wrote: > Do you feel it’s OK to enable VIMAGE in -stable? When I tried last in 2016, I had stability issues, I think related to pf. It is already in HEAD's GENERIC and will be in 12.0-RELEASE soon, so in -stable too. I use it with stable/11 without problems but I do not use pf. From owner-freebsd-stable@freebsd.org Mon Aug 20 18:37:34 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C11441078869 for ; Mon, 20 Aug 2018 18:37:34 +0000 (UTC) (envelope-from spork@bway.net) Received: from smtp1.bway.net (smtp1.v6.bway.net [IPv6:2607:d300:1::27]) (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 774717B76A; Mon, 20 Aug 2018 18:37:34 +0000 (UTC) (envelope-from spork@bway.net) Received: from frankentosh.sporklab.com (pool-71-187-162-242.nwrknj.fios.verizon.net [71.187.162.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: spork@bway.net) by smtp1.bway.net (Postfix) with ESMTPSA id BF5E99584F; Mon, 20 Aug 2018 14:37:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Bind to port <1024 in jail From: Charles Sprickman In-Reply-To: <1534777490.27158.47.camel@freebsd.org> Date: Mon, 20 Aug 2018 14:37:25 -0400 Cc: Stefan Bethke , FreeBSD Stable Content-Transfer-Encoding: quoted-printable Message-Id: <36614699-F6E0-495D-8EC0-FCF4B1B12BA3@bway.net> References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <1534777490.27158.47.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 18:37:34 -0000 > On Aug 20, 2018, at 11:04 AM, Ian Lepore wrote: >=20 > On Mon, 2018-08-20 at 16:47 +0200, Stefan Bethke wrote: >> I have a Go program (acme-dns) that wants to bind 53, 80, and 443, >> and I=C2=B4d rather have it run as a non-privileged user. The = program >> doesn=C2=B4t provide a facility to drop privs after binding the = ports. I=C2=B4m >> planning to run it in a jail. >>=20 >> After some googling, it appears that a couple of years ago I should >> have been able to do: >> sysctl net.inet.ip.portrange.reservedhigh=3D0 >> and allow all processes to bind to =E2=80=9Elow=E2=80=9C ports. This = does not work in >> my jails on a 11-stable host. >>=20 >> $ sudo sysctl net.inet.ip.portrange.reservedhigh=3D0 >> net.inet.ip.portrange.reservedhigh: 1023 >> sysctl: net.inet.ip.portrange.reservedhigh=3D0: Operation not = permitted >>=20 >> Securelevel should not interfere: >> $ sysctl kern.securelevel >> kern.securelevel: -1 >>=20 >> Is there a way to allow regular processes to bind to low ports? >>=20 >>=20 >> Stefan >>=20 >=20 > You might be able to set up a specific local userid for this process, > then use mac_portacl(4) to allow it to bind to those ports. I'm not > certain that works inside a jail, however. I am so behind on all the new toys in the system. I was very = embarrassed to find out about this feature from someone who=E2=80=99s primarily = working with Linux in his day job. He was just looking to bind an Elixir app to = 80/443 without running as root and he shared this: security.mac.portacl.rules=3Dgid:2001:tcp:80,gid:2001:tcp:443 We stuck that in sysctl.conf and that was that. I wish FreeBSD still had the evangelism folks that would go out and tell the userbase and anyone else that would listen about all the cool new stuff. :) Charles >=20 > -- Ian > _______________________________________________ > 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-stable@freebsd.org Mon Aug 20 19:15:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 820711079BF4 for ; Mon, 20 Aug 2018 19:15:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1088F7D083 for ; Mon, 20 Aug 2018 19:15:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7KJF3qe072974 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2018 15:15:03 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7KJF1ni084317 for ; Mon, 20 Aug 2018 15:15:01 -0400 (EDT) (envelope-from mike@sentex.net) To: FreeBSD-STABLE Mailing List From: Mike Tancsa Subject: gpart strangeness Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> Date: Mon, 20 Aug 2018 15:15:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 19:15:07 -0000 I was trying to create a single partition on a 16G mSata drive and whenever I add a partition, all of a sudden the secondary GPT partion is borked. Any idea whats going on here ? 0# gpart destroy -F ada0 ada0 destroyed 0# gpart create -s GPT ada0 ada0 created 0# gpart add -t freebsd-ufs ada0 GEOM: diskid/DISK-DEF30753136101678326: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-DEF30753136101678326: using the primary only -- recovery suggested. ada0p1 added 0# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 31277191 first: 40 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 16013901824 (15G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 20480 Mode: r0w0e0 efimedia: HD(1,GPT,2256d7c5-a4ad-11e8-aa7c-000db94b5a84,0x28,0x1dd4060) rawuuid: 2256d7c5-a4ad-11e8-aa7c-000db94b5a84 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: (null) length: 16013901824 offset: 20480 type: freebsd-ufs index: 1 end: 31277191 start: 40 Consumers: 1. Name: ada0 Mediasize: 16013942784 (15G) Sectorsize: 512 Mode: r0w0e0 0# -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Mon Aug 20 20:41:49 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0170107C25E for ; Mon, 20 Aug 2018 20:41:49 +0000 (UTC) (envelope-from SRS0=h6BF=LD=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (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 5370780DA9; Mon, 20 Aug 2018 20:41:49 +0000 (UTC) (envelope-from SRS0=h6BF=LD=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id CC48628423; Mon, 20 Aug 2018 22:41:40 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 9CBEA28412; Mon, 20 Aug 2018 22:41:39 +0200 (CEST) Subject: Re: changes in iostat output in 11.x vs 10.x To: Will Andrews , freebsd-stable Stable References: <906cc905-5d1f-6792-e998-4bbd77d4f043@quip.cz> <20180819143039.GD97145@funkthat.com> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <5f6c2ebf-bd7e-21a2-8105-6b9cba26d7c1@quip.cz> Date: Mon, 20 Aug 2018 22:41:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 20:41:49 -0000 Will Andrews wrote on 2018/08/20 15:33: > On Sun, Aug 19, 2018 at 9:30 AM, John-Mark Gurney wrote: > >> Miroslav Lachman wrote this message on Sun, Aug 19, 2018 at 02:29 +0200: >>> I upgraded one of our servers from 10.4 to 11.2 and scripts using output >>> of "iostat -x" are not working anymore. >>> A checked the output of iostat and it is different. >> >> Looks like this was changed in r277566[1] by will. I've cc'd him. There >> is no documentation change associated w/ this change. >> >> [1] https://svnweb.freebsd.org/base?view=revision&revision=277566 > > > Ah, yes, that should have been accompanied by a man page update. My bad, > I'll fix it. ms/t is indeed what used to be svc_t. Thank you for the clarification. Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Tue Aug 21 03:30:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A62210875AB for ; Tue, 21 Aug 2018 03:30:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D400970295 for ; Tue, 21 Aug 2018 03:30:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7L3U5c3057978 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Aug 2018 05:30:05 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: spork@bway.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7L3TvWH088077 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Aug 2018 10:29:57 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bind to port <1024 in jail To: Charles Sprickman References: <75536186-7D58-498C-BFC6-9284EB7CB444@lassitu.de> <1534777490.27158.47.camel@freebsd.org> <36614699-F6E0-495D-8EC0-FCF4B1B12BA3@bway.net> Cc: FreeBSD Stable From: Eugene Grosbein Message-ID: Date: Tue, 21 Aug 2018 10:29:52 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <36614699-F6E0-495D-8EC0-FCF4B1B12BA3@bway.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 03:30:28 -0000 21.08.2018 1:37, Charles Sprickman via freebsd-stable wrote: > I am so behind on all the new toys in the system. I was very embarrassed > to find out about this feature from someone who’s primarily working > with Linux in his day job. He was just looking to bind an Elixir app to 80/443 > without running as root and he shared this: > > security.mac.portacl.rules=gid:2001:tcp:80,gid:2001:tcp:443 > > We stuck that in sysctl.conf and that was that. This is not so new: mac_portacl is here since 8.0-RELEASE. > I wish FreeBSD still had the evangelism folks that would go out and > tell the userbase and anyone else that would listen about all the cool > new stuff. :) Well, we still have Release Notes for every major or minor release. Get a habit reading it once a release and you'll know it all. From owner-freebsd-stable@freebsd.org Tue Aug 21 03:34:37 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55AA51087954 for ; Tue, 21 Aug 2018 03:34:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D0AE670816 for ; Tue, 21 Aug 2018 03:34:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7L3YTeK058007 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Aug 2018 05:34:30 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mike@sentex.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7L3YJkB088182 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Aug 2018 10:34:19 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: gpart strangeness To: Mike Tancsa , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> From: Eugene Grosbein Message-ID: <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> Date: Tue, 21 Aug 2018 10:34:15 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 03:34:37 -0000 21.08.2018 2:15, Mike Tancsa wrote: > I was trying to create a single partition on a 16G mSata drive and > whenever I add a partition, all of a sudden the secondary GPT partion is > borked. Any idea whats going on here ? > > > > 0# gpart destroy -F ada0 > ada0 destroyed > 0# gpart create -s GPT ada0 > ada0 created > 0# gpart add -t freebsd-ufs ada0 > GEOM: diskid/DISK-DEF30753136101678326: the secondary GPT table is > corrupt or invalid. > GEOM: diskid/DISK-DEF30753136101678326: using the primary only -- > recovery suggested. > ada0p1 added > 0# gpart list ada0 > Geom name: ada0 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 31277191 > first: 40 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada0p1 > Mediasize: 16013901824 (15G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 20480 > Mode: r0w0e0 > efimedia: HD(1,GPT,2256d7c5-a4ad-11e8-aa7c-000db94b5a84,0x28,0x1dd4060) > rawuuid: 2256d7c5-a4ad-11e8-aa7c-000db94b5a84 > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > label: (null) > length: 16013901824 > offset: 20480 > type: freebsd-ufs > index: 1 > end: 31277191 > start: 40 > Consumers: > 1. Name: ada0 > Mediasize: 16013942784 (15G) > Sectorsize: 512 > Mode: r0w0e0 > > 0# Did you look to "dmesg -a" output for additional hints? What is system version? From owner-freebsd-stable@freebsd.org Tue Aug 21 09:06:25 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E333108E82C for ; Tue, 21 Aug 2018 09:06:25 +0000 (UTC) (envelope-from Dejan.Vucko@kkl.si) Received: from avs5.arnes.si (avs5.arnes.si [193.2.1.126]) (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 076E77A29D for ; Tue, 21 Aug 2018 09:06:24 +0000 (UTC) (envelope-from Dejan.Vucko@kkl.si) Received: from localhost (scanner1.arnes.si [193.2.0.10]) by avs5.arnes.si (Postfix) with ESMTP id B2434600E944 for ; Tue, 21 Aug 2018 11:06:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kkl.si; h= mime-version:content-transfer-encoding:content-type:content-type :content-language:accept-language:message-id:date:date:subject :subject:from:from:received:received:received; s=one; t= 1534842375; x=1536138376; bh=UIQrZW1R3oaEx+p6u8Z7zNLrGB2tF7UT9Nm XRE1NsSs=; b=lGagP0PCEsQ+1DTrI4OzN7x1PS67y4OLoUFD3Gcl1ZRMbhayuYQ aavaolbRhJT2pw5L/vKm4yzzT7gC2K53iMACcbE+NnCwiKu85gWD8+pZhRlVrY6s tjce3TYY4x8pUu/gLr/rAsxanTKVeLLVanDve1zYRVg7/CPv2jXiHBdo= Received: from avs5.arnes.si ([193.2.1.126]) by localhost (scanner1.arnes.si [193.2.0.12]) (amavisd-new, port 40050) with ESMTP id 1Fwhc0zBY1gT for ; Tue, 21 Aug 2018 11:06:15 +0200 (CEST) Received: from mail.kl-kl.local (mail.kl-kl.si [193.2.53.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by avs5.arnes.si (Postfix) with ESMTPS id 96875600E3D8 for ; Tue, 21 Aug 2018 11:06:15 +0200 (CEST) Received: from MAIL.kl-kl.local ([fe80::5db5:e252:7b0f:3a88]) by mail.kl-kl.local ([fe80::5db5:e252:7b0f:3a88%10]) with mapi id 14.03.0415.000; Tue, 21 Aug 2018 11:06:15 +0200 From: =?iso-8859-2?Q?Dejan_Vu=E8ko?= To: "'freebsd-stable@freebsd.org'" Subject: Re: bad hash in repo Thread-Topic: Re: bad hash in repo Thread-Index: AdQ5LazaSxsvnvzwQimdI+1p6UznoA== Date: Tue, 21 Aug 2018 09:06:14 +0000 Message-ID: <2C2BB7D130892840922EEBE1D979B1E10145EAE736@mail.kl-kl.local> Accept-Language: sl-SI, en-US Content-Language: sl-SI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.127.197.147] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 09:06:25 -0000 Same here: --- #freebsd-update fetch -v debug -s update6.FreeBSD.org Looking up update6.FreeBSD.org mirrors... none found. Fetching metadata signature for 11.1-RELEASE from update6.FreeBSD.org... latest.ssl 100% of 512 B 3334 kBps 00m= 00s done. Fetching metadata index... 530eecbc563578617fecbbfa4036bd8d61f435d9147222100% of 225 B 1139 kBps 00m= 00s done. Inspecting system... done. Preparing to download files... done. Fetching 2 patches... /usr/libexec/phttpget update6.FreeBSD.org 11.1-RELEASE/i386/bp/7d5cea1a80a7= c5f51461af4f408df0933785b8ee66614efbb13ef1e5f337e11d-d258e13105d0e360ab6f80= 48d0ac1a8c64297224e3c4c34f29e24988bb4bb16d 11.1-RELEASE/i386/bp/aaaef0cb3e6= 6c7deb0f8af02a8036414f6a2110ccd9d7d6baec57d4848e0d7bb-104969ef03336523729ea= 1df2547267441a13cb040c778e971b74103e88dbc77 http://update6.FreeBSD.org/11.1-RELEASE/i386/bp/7d5cea1a80a7c5f51461af4f408= df0933785b8ee66614efbb13ef1e5f337e11d-d258e13105d0e360ab6f8048d0ac1a8c64297= 224e3c4c34f29e24988bb4bb16d: 200 OK http://update6.FreeBSD.org/11.1-RELEASE/i386/bp/aaaef0cb3e66c7deb0f8af02a80= 36414f6a2110ccd9d7d6baec57d4848e0d7bb-104969ef03336523729ea1df2547267441a13= cb040c778e971b74103e88dbc77: 200 OK done. Applying patches... done. Fetching 2 files... /usr/libexec/phttpget update6.FreeBSD.org 11.1-RELEASE/i386/f/104969ef03336= 523729ea1df2547267441a13cb040c778e971b74103e88dbc77.gz 11.1-RELEASE/i386/f/= d258e13105d0e360ab6f8048d0ac1a8c64297224e3c4c34f29e24988bb4bb16d.gz http://update6.FreeBSD.org/11.1-RELEASE/i386/f/104969ef03336523729ea1df2547= 267441a13cb040c778e971b74103e88dbc77.gz: 200 OK http://update6.FreeBSD.org/11.1-RELEASE/i386/f/d258e13105d0e360ab6f8048d0ac= 1a8c64297224e3c4c34f29e24988bb4bb16d.gz: 200 OK 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorr= ect hash. --- Best regards,=20 Dejan Vu=E8ko From owner-freebsd-stable@freebsd.org Tue Aug 21 11:30:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BA7D106E0D4 for ; Tue, 21 Aug 2018 11:30:07 +0000 (UTC) (envelope-from denn_28@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BC657F332 for ; Tue, 21 Aug 2018 11:30:06 +0000 (UTC) (envelope-from denn_28@yahoo.com) X-YMail-OSG: ib6p68AVM1lgq7GHSFR0TLz2rwDPtVnbU8MDNDrhLCdHrjVfqVZjYsuN2ZgtDbL lufxQpB9aA2fuZzDbSrMc.d1bV2Ej65M6_BwYpWdTg5LUxnWjtUYD6Jc2S0SerCSftJdLxtZ0iUQ z.oss0DUNwByV7QuWVskVF.RN2aJ9hjvtOWIs.uGzg3V5Lkvv_5_rtg6tMZdMOwPgQk9gWqy3o_e jlWZ2f1vluBj_MWmO86jOUoX16zVOqPBe7BzPd4erjHCUELpwTdLlyx_IDuWRHrmHu9h7HcypYJi jPGnffMGIrDwaJLXxe8NW.JhdfT73tiEgOqG8paTI4FgFP6EYArd3946f6i2rqaHI1319dX0ini0 mroFIMz4eW9fHIzxGSn1p6NHJx0aDy0o4rJY4wDH4Lsd1_SDKptKM2EvCFRS6n1kW_w93yn0MKQ_ xdaiDOYawy7bsljBoXCCG19XMqN52JVH46vA7f7lkT43Fi629ZbjdChWfGxC1GOXxtYh9SerUdyv azO5Z6U8LoOKcZ1Ug5FiPwX427ao4I4tq7djieOc2R8upAWEqw1KFg4soGgWuELq4AtLrQ61hF8e _HEeVduB7sa2XHTBaGnuQS._ZAFNgBnHmFP6yiHzt6FgsfqJr9.JDgs01c4wlqwCztz1ta508251 pGloczS0FAs09.2XpdBYGK4hPz53Xw6A67Ezl6WyiDQbiTZnnaK452BxLAyBbLOiAGjJJbiLdpAf 0N_lmNU13462ub1Iz..Hh0AHRYzvFh2o4aEoy_Dg.XrGhk_6BVAjvt46olpJOJNNn1oFlXtnOWbE qqkIcDr8HlCmwpQJ_q9cf63jwWs7vyXw.DhmqKwGi04Ep6M7siBFx6kOvUCWMD0MxvRu7JdeSPUU bQ9sKFEn73UA7hqlLG0ZH1oMvZCCMGOFMgGRFJng047SfYTv6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 21 Aug 2018 11:29:59 +0000 Date: Tue, 21 Aug 2018 11:29:56 +0000 (UTC) From: "Denis A. Konovalyenko" To: "freebsd-stable@freebsd.org" Message-ID: <27677493.1408567.1534850996965@mail.yahoo.com> Subject: Segfaults with more than 1 core active on Intel Core2 Duo CPU MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1408566_461147516.1534850996965" References: <27677493.1408567.1534850996965.ref@mail.yahoo.com> X-Mailer: WebService/1.1.12262 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 11:30:07 -0000 ------=_Part_1408566_461147516.1534850996965 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone! Since 8.0-R came out, FreeBSD has been present as a dual-boot citizen on my= laptop (Lenovo ThinkPad SL510). And it worked fine with subsequent upgrade= s to 8.x and 9.x. However, after upgrades to 10.x (do not remember the exac= t version - most likely 10.1-R or 10.2-R), something caused my desktop appl= ications with immense demands of resources (Firefox ESR, IntelliJ IDEA) to = stop running sporadically with the segmentation faults (now these programs = just die on lunching on 11.1-R). I thought that was related to some sort of= UI libraries or Linux layer incompatibilities or kevent kernel support, so= gave them new tries from time to time=C2=A0to figure out the cause. As usual, this week I started my experiments with building a custom kernel = (I found the generic one quite suitable for binary updates/upgrades) and re= vealed that "make depend" behaved the same way. Only that day I switched of= f multiple CPU cores support in BIOS and booted. That was remarkable! There= was no a segfault on a single core after that! Hence, my question is - does anybody know or have an idea of what might be = the cause of segfaults with 2 CPU cores active? Also, I would really apprec= iate it if someone could give me some hints on how to pinpoint the issue. Could you please find attached the outputs of "uname -a" and "dmesg" comman= ds as well as my current loader.conf, rc.conf and sysctl.conf configuration= files? Best regards, Denis ------=_Part_1408566_461147516.1534850996965 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg-output" Content-ID: <95acf869-414b-cff3-f012-b95b4b02c1f5@yahoo.com> Q29weXJpZ2h0IChjKSAxOTkyLTIwMTcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4xLVJFTEVBU0UtcDEzICMwOiBUdWUgQXVnIDE0 IDE5OjM0OjIxIFVUQyAyMDE4CiAgICByb290QGFtZDY0LWJ1aWxkZXIuZGFlbW9ub2xvZ3kubmV0 Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMgYW1kNjQKRnJlZUJTRCBjbGFuZyB2ZXJzaW9u IDQuMC4wICh0YWdzL1JFTEVBU0VfNDAwL2ZpbmFsIDI5NzM0NykgKGJhc2VkIG9uIExMVk0gNC4w LjApClZUKHZnYSk6IHJlc29sdXRpb24gNjQweDQ4MAppbmZvOiBbZHJtXSBJbml0aWFsaXplZCBk cm0gMS4xLjAgMjAwNjA4MTAKQ1BVOiBJbnRlbChSKSBDb3JlKFRNKTIgRHVvIENQVSAgICAgVDk5 MDAgIEAgMy4wNkdIeiAoMzA1OS4wNy1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbj0iR2VudWlu ZUludGVsIiAgSWQ9MHgxMDY3YSAgRmFtaWx5PTB4NiAgTW9kZWw9MHgxNyAgU3RlcHBpbmc9MTAK ICBGZWF0dXJlcz0weGFmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgs QVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1Y LEZYU1IsU1NFLFNTRTIsU1MsVE0sUEJFPgogIEZlYXR1cmVzMj0weGMwOGUzZmQ8U1NFMyxEVEVT NjQsTU9OLERTX0NQTCxWTVgsU01YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sU1NFNC4x LFhTQVZFLE9TWFNBVkU+CiAgQU1EIEZlYXR1cmVzPTB4MjAxMDA4MDA8U1lTQ0FMTCxOWCxMTT4K ICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIFZULXg6IEhMVCxQQVVTRQogIFRTQzogUC1zdGF0 ZSBpbnZhcmlhbnQsIHBlcmZvcm1hbmNlIHN0YXRpc3RpY3MKcmVhbCBtZW1vcnkgID0gODU4OTkz NDU5MiAoODE5MiBNQikKYXZhaWwgbWVtb3J5ID0gODA5NjM1MDIwOCAoNzcyMSBNQikKRXZlbnQg dGltZXIgIkxBUElDIiBxdWFsaXR5IDEwMApBQ1BJIEFQSUMgVGFibGU6IDxMRU5PVk8gVFAtNkog ICA+CnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFz IDAtMjMgb24gbW90aGVyYm9hcmQKVGltZWNvdW50ZXIgIlRTQy1sb3ciIGZyZXF1ZW5jeSAxNTI5 NTM1NzcwIEh6IHF1YWxpdHkgMTAwMApDdXNlIHYwLjEuMzQgQCAvZGV2L2N1c2UKdGFza3Fncm91 cF9hZGp1c3QgZmFpbGVkIGNudDogMSBzdHJpZGU6IDEgbXBfbmNwdXM6IDEgc21wX3N0YXJ0ZWQ6 IDAKdGFza3Fncm91cF9hZGp1c3QgZmFpbGVkIGNudDogMSBzdHJpZGU6IDEgbXBfbmNwdXM6IDEg c21wX3N0YXJ0ZWQ6IDAKcmFuZG9tOiBlbnRyb3B5IGRldmljZSBleHRlcm5hbCBpbnRlcmZhY2UK a2JkMSBhdCBrYmRtdXgwCm5ldG1hcDogbG9hZGVkIG1vZHVsZQptb2R1bGVfcmVnaXN0ZXJfaW5p dDogTU9EX0xPQUQgKHZlc2EsIDB4ZmZmZmZmZmY4MGY1ZWM2MCwgMCkgZXJyb3IgMTkKbmV4dXMw CnZ0dmdhMDogPFZUIFZHQSBkcml2ZXI+IG9uIG1vdGhlcmJvYXJkCmNyeXB0b3NvZnQwOiA8c29m dHdhcmUgY3J5cHRvPiBvbiBtb3RoZXJib2FyZAphY3BpMDogPExFTk9WTyBUUC02Sj4gb24gbW90 aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCmhwZXQwOiA8SGlnaCBQcmVjaXNp b24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1l Y291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRp bWVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTAKRXZlbnQgdGltZXIg IkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQ RVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQz IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKY3B1MDogPEFDUEkgQ1BVPiBvbiBh Y3BpMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4NzcgaXJxIDggb24g YWNwaTAKYXRydGMwOiBXYXJuaW5nOiBDb3VsZG4ndCBtYXAgSS9PLgpFdmVudCB0aW1lciAiUlRD IiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwCmF0dGltZXIwOiA8QVQgdGltZXI+IHBvcnQg MHg0MC0weDQzLDB4NTAtMHg1MyBpcnEgMCBvbiBhY3BpMApUaW1lY291bnRlciAiaTgyNTQiIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5j eSAxMTkzMTgyIEh6IHF1YWxpdHkgMTAwClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5j eSAzNTc5NTQ1IEh6IHF1YWxpdHkgOTAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMu NTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQg Q29udHJvbGxlcjogR1BFIDB4MTc+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCnBjaWIwOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjAKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQg MHgxODAwLTB4MTgwNyBtZW0gMHhmMjQwMDAwMC0weGYyN2ZmZmZmLDB4ZDAwMDAwMDAtMHhkZmZm ZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFncDA6IDxJbnRlbCBHTTQ1IFNWR0Eg Y29udHJvbGxlcj4gb24gdmdhcGNpMAphZ3AwOiBhcGVydHVyZSBzaXplIGlzIDI1Nk0sIGRldGVj dGVkIDEzMTA2OGsgc3RvbGVuIG1lbW9yeQpkcm1uMDogPE1vYmlsZSBJbnRlbMKuIEdNNDUgRXhw cmVzcyBDaGlwc2V0PiBvbiB2Z2FwY2kwCmluZm86IFtkcm1dIE1UUlIgYWxsb2NhdGlvbiBmYWls ZWQuICBHcmFwaGljcyBwZXJmb3JtYW5jZSBtYXkgc3VmZmVyLgppbnRlbF9paWNiYjAgb24gZHJt bjAKaWljYnVzMDogPFBoaWxpcHMgSTJDIGJ1cz4gb24gaWljYmIwIGFkZHIgMHhmZgppaWMwOiA8 STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMwCmlpY2J1czE6IDxQaGlsaXBzIEkyQyBidXM+IG9u IGludGVsX2dtYnVzMAppaWMxOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxCmludGVsX2lp Y2JiMSBvbiBkcm1uMAppaWNidXMyOiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBpaWNiYjEgYWRkciAw eGZmCmlpYzI6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czIKaWljYnVzMzogPFBoaWxpcHMg STJDIGJ1cz4gb24gaW50ZWxfZ21idXMxCmlpYzM6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1 czMKaW50ZWxfaWljYmIyIG9uIGRybW4wCmlpY2J1czQ6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGlp Y2JiMiBhZGRyIDB4ZmYKaWljNDogPEkyQyBnZW5lcmljIEkvTz4gb24gaWljYnVzNAppaWNidXM1 OiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBpbnRlbF9nbWJ1czIKaWljNTogPEkyQyBnZW5lcmljIEkv Tz4gb24gaWljYnVzNQppbnRlbF9paWNiYjMgb24gZHJtbjAKaWljYnVzNjogPFBoaWxpcHMgSTJD IGJ1cz4gb24gaWljYmIzIGFkZHIgMHhmZgppaWM2OiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNi dXM2CmlpY2J1czc6IDxQaGlsaXBzIEkyQyBidXM+IG9uIGludGVsX2dtYnVzMwppaWM3OiA8STJD IGdlbmVyaWMgSS9PPiBvbiBpaWNidXM3CmludGVsX2lpY2JiNCBvbiBkcm1uMAppaWNidXM4OiA8 UGhpbGlwcyBJMkMgYnVzPiBvbiBpaWNiYjQgYWRkciAweGZmCmlpYzg6IDxJMkMgZ2VuZXJpYyBJ L08+IG9uIGlpY2J1czgKaWljYnVzOTogPFBoaWxpcHMgSTJDIGJ1cz4gb24gaW50ZWxfZ21idXM0 CmlpYzk6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czkKaW50ZWxfaWljYmI1IG9uIGRybW4w CmlpY2J1czEwOiA8UGhpbGlwcyBJMkMgYnVzPiBvbiBpaWNiYjUgYWRkciAweGZmCmlpYzEwOiA8 STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxMAppaWNidXMxMTogPFBoaWxpcHMgSTJDIGJ1cz4g b24gaW50ZWxfZ21idXM1CmlpYzExOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNidXMxMQppbmZv OiBbZHJtXSBNU0kgZW5hYmxlZCAxIG1lc3NhZ2UocykKaW5mbzogW2RybV0gU3VwcG9ydHMgdmJs YW5rIHRpbWVzdGFtcCBjYWNoaW5nIFJldiAxICgxMC4xMC4yMDEwKS4KaW5mbzogW2RybV0gRHJp dmVyIHN1cHBvcnRzIHByZWNpc2UgdmJsYW5rIHRpbWVzdGFtcCBxdWVyeS4KaW50ZWxfc2R2b19k ZGNfcHJveHkzOTc2MzIgb24gZHJtbjAKaW50ZWxfc2R2b19kZGNfcHJveHkzOTc2MzI6IGRldGFj aGVkCmRybV9paWNfZHBfYXV4MCBvbiBkcm1uMAppbnRlbF9zZHZvX2RkY19wcm94eTM5NzY2NCBv biBkcm1uMAppbnRlbF9zZHZvX2RkY19wcm94eTM5NzY2NDogZGV0YWNoZWQKZHJtX2lpY19kcF9h dXgxIG9uIGRybW4wCmRybW4wOiB0YWtpbmcgb3ZlciB0aGUgZmljdGl0aW91cyByYW5nZSAweGQw MDAwMDAwLTB4ZTAwMDAwMDAKaW5mbzogW2RybV0gQ29ubmVjdG9yIExWRFMtMTogZ2V0IG1vZGUg ZnJvbSB0dW5hYmxlczoKaW5mbzogW2RybV0gICAtIGtlcm4udnQuZmIubW9kZXMuTFZEUy0xCmlu Zm86IFtkcm1dICAgLSBrZXJuLnZ0LmZiLmRlZmF1bHRfbW9kZQppbmZvOiBbZHJtXSBDb25uZWN0 b3IgVkdBLTE6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6CmluZm86IFtkcm1dICAgLSBrZXJuLnZ0 LmZiLm1vZGVzLlZHQS0xCmluZm86IFtkcm1dICAgLSBrZXJuLnZ0LmZiLmRlZmF1bHRfbW9kZQpp bmZvOiBbZHJtXSBDb25uZWN0b3IgSERNSS1BLTE6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6Cmlu Zm86IFtkcm1dICAgLSBrZXJuLnZ0LmZiLm1vZGVzLkhETUktQS0xCmluZm86IFtkcm1dICAgLSBr ZXJuLnZ0LmZiLmRlZmF1bHRfbW9kZQppbmZvOiBbZHJtXSBDb25uZWN0b3IgRFAtMTogZ2V0IG1v ZGUgZnJvbSB0dW5hYmxlczoKaW5mbzogW2RybV0gICAtIGtlcm4udnQuZmIubW9kZXMuRFAtMQpp bmZvOiBbZHJtXSAgIC0ga2Vybi52dC5mYi5kZWZhdWx0X21vZGUKaW5mbzogW2RybV0gQ29ubmVj dG9yIERQLTI6IGdldCBtb2RlIGZyb20gdHVuYWJsZXM6CmluZm86IFtkcm1dICAgLSBrZXJuLnZ0 LmZiLm1vZGVzLkRQLTIKaW5mbzogW2RybV0gICAtIGtlcm4udnQuZmIuZGVmYXVsdF9tb2RlCmZi ZDAgb24gZHJtbjAKVlQ6IFJlcGxhY2luZyBkcml2ZXIgInZnYSIgd2l0aCBuZXcgImZiIi4KaW5m bzogW2RybV0gSW5pdGlhbGl6ZWQgaTkxNSAxLjYuMCAyMDA4MDczMCBmb3IgZHJtbjAgb24gbWlu b3IgMAp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQp2Z2FwY2kxOiA8VkdBLWNvbXBhdGlibGUg ZGlzcGxheT4gbWVtIDB4ZjIxMDAwMDAtMHhmMjFmZmZmZiBhdCBkZXZpY2UgMi4xIG9uIHBjaTAK dWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MTgyMC0w eDE4M2YgaXJxIDE2IGF0IGRldmljZSAyNi4wIG9uIHBjaTAKdXNidXMwIG9uIHVoY2kwCnVoY2kx OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDE4NDAtMHgxODVm IGlycSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVzYnVzMSBvbiB1aGNpMQp1aGNpMjogPElu dGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgxODYwLTB4MTg3ZiBpcnEg MTkgYXQgZGV2aWNlIDI2LjIgb24gcGNpMAp1c2J1czIgb24gdWhjaTIKZWhjaTA6IDxJbnRlbCA4 MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZjJhMDQ4MDAtMHhmMmEwNGJm ZiBpcnEgMTkgYXQgZGV2aWNlIDI2Ljcgb24gcGNpMAp1c2J1czM6IEVIQ0kgdmVyc2lvbiAxLjAK dXNidXMzIG9uIGVoY2kwCmhkYWMwOiA8SW50ZWwgODI4MDFJIEhEQSBDb250cm9sbGVyPiBtZW0g MHhmMmEwMDAwMC0weGYyYTAzZmZmIGlycSAyMiBhdCBkZXZpY2UgMjcuMCBvbiBwY2kwCnBjaWIx OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4wIG9uIHBjaTAKcGNp YjE6IFtHSUFOVC1MT0NLRURdCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnNkaGNpX3Bj aTA6IDxKTWljcm9uIEpNQjM4WCBTRD4gbWVtIDB4ZjIzMDA0MDAtMHhmMjMwMDRmZiBpcnEgMTYg YXQgZGV2aWNlIDAuMiBvbiBwY2kxCnNkaGNpX3BjaTA6IDEgc2xvdChzKSBhbGxvY2F0ZWQKcGNp YjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjEgb24gcGNpMApw Y2liMjogW0dJQU5ULUxPQ0tFRF0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTgg YXQgZGV2aWNlIDI4LjIgb24gcGNpMApwY2liMzogW0dJQU5ULUxPQ0tFRF0KcGNpYjQ6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTkgYXQgZGV2aWNlIDI4LjMgb24gcGNpMApwY2liNDogW0dJ QU5ULUxPQ0tFRF0KcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKaXduMDogPEludGVsIENl bnRyaW5vIFdpcmVsZXNzLU4gMTAwMD4gbWVtIDB4ZjIyMDAwMDAtMHhmMjIwMWZmZiBpcnEgMTkg YXQgZGV2aWNlIDAuMCBvbiBwY2kyCnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3 IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpYjU6IFtHSUFOVC1MT0NLRURdCnBjaWI2OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC41IG9uIHBjaTAKcGNpYjY6IFtH SUFOVC1MT0NLRURdCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnJlMDogPFJlYWxUZWsg ODE2OC84MTExIEIvQy9DUC9EL0RQL0UvRi9HIFBDSWUgR2lnYWJpdCBFdGhlcm5ldD4gcG9ydCAw eDMwMDAtMHgzMGZmIG1lbSAweGYyMDA0MDAwLTB4ZjIwMDRmZmYsMHhmMjAwMDAwMC0weGYyMDAz ZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTMKcmUwOiBVc2luZyAxIE1TSS1YIG1lc3Nh Z2UKcmUwOiBBU1BNIGRpc2FibGVkCnJlMDogQ2hpcCByZXYuIDB4MjgwMDAwMDAKcmUwOiBNQUMg cmV2LiAweDAwMTAwMDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiByZTAKcmdlcGh5MDogPFJUTDgx NjlTLzgxMTBTLzgyMTEgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1 czAKcmdlcGh5MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMGJhc2VULUZEWC1mbG93 LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMGJhc2VUWC1GRFgtZmxvdywgMTAwMGJhc2VU LCAxMDAwYmFzZVQtbWFzdGVyLCAxMDAwYmFzZVQtRkRYLCAxMDAwYmFzZVQtRkRYLW1hc3Rlciwg MTAwMGJhc2VULUZEWC1mbG93LCAxMDAwYmFzZVQtRkRYLWZsb3ctbWFzdGVyLCBhdXRvLCBhdXRv LWZsb3cKcmUwOiBVc2luZyBkZWZhdWx0cyBmb3IgVFNPOiA2NTUxOC8zNS8yMDQ4CnJlMDogRXRo ZXJuZXQgYWRkcmVzczogNjA6ZWI6Njk6OTM6ZDE6MDkKcmUwOiBuZXRtYXAgcXVldWVzL3Nsb3Rz OiBUWCAxLzI1NiwgUlggMS8yNTYKdWhjaTM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250 cm9sbGVyPiBwb3J0IDB4MTg4MC0weDE4OWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTAK dXNidXM0IG9uIHVoY2kzCnVoY2k0OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxl cj4gcG9ydCAweDE4YTAtMHgxOGJmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVzYnVz NSBvbiB1aGNpNAp1aGNpNTogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBv cnQgMHgxOGMwLTB4MThkZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1c2J1czYgb24g dWhjaTUKZWhjaTE6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVt IDB4ZjJhMDRjMDAtMHhmMmEwNGZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAp1c2J1 czc6IEVIQ0kgdmVyc2lvbiAxLjAKdXNidXM3IG9uIGVoY2kxCnBjaWI3OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liNwppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6 IDxJU0EgYnVzPiBvbiBpc2FiMAphaGNpMDogPEludGVsIElDSDlNIEFIQ0kgU0FUQSBjb250cm9s bGVyPiBwb3J0IDB4MTgxOC0weDE4MWYsMHgxODBjLTB4MTgwZiwweDE4MTAtMHgxODE3LDB4MTgw OC0weDE4MGIsMHgxOGUwLTB4MThmZiBtZW0gMHhmMmEwNDAwMC0weGYyYTA0N2ZmIGlycSAxOSBh dCBkZXZpY2UgMzEuMiBvbiBwY2kwCmFoY2kwOiBBSENJIHYxLjIwIHdpdGggNCAzR2JwcyBwb3J0 cywgUG9ydCBNdWx0aXBsaWVyIG5vdCBzdXBwb3J0ZWQKYWhjaWNoMDogPEFIQ0kgY2hhbm5lbD4g YXQgY2hhbm5lbCAwIG9uIGFoY2kwCmFoY2ljaDE6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwg MSBvbiBhaGNpMAphaGNpY2g0OiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDQgb24gYWhjaTAK YWhjaWNoNTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCA1IG9uIGFoY2kwCmFoY2llbTA6IDxB SENJIGVuY2xvc3VyZSBtYW5hZ2VtZW50IGJyaWRnZT4gb24gYWhjaTAKaWNoc21iMDogPEludGVs IDgyODAxSSAoSUNIOSkgU01CdXMgY29udHJvbGxlcj4gcG9ydCAweDFjMDAtMHgxYzFmIGlycSAx OSBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwCnNtYnVzMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4g b24gaWNoc21iMApzbWIwOiA8U01CdXMgZ2VuZXJpYyBJL08+IG9uIHNtYnVzMAphY3BpX2FjYWQw OiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYmF0dGVyeTA6IDxBQ1BJIENvbnRyb2wgTWV0aG9kIEJh dHRlcnk+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9u IGFjcGkwCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9idXR0b24x OiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMAphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNw aTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQg aXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2Jk MCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJx IDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwgU3luYXB0aWNz IFRvdWNocGFkLCBkZXZpY2UgSUQgMAphY3BpX2libTA6IDxJQk0gVGhpbmtQYWQgQUNQSSBFeHRy YXM+IG9uIGFjcGkwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4ZTAwMDAtMHhl MWZmZiwweGUyMDAwLTB4ZTM3ZmYgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9y dCByYW5nZQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBj cHUwCmZ1c2UtZnJlZWJzZDogdmVyc2lvbiAwLjQuNCwgRlVTRSBBQkkgNy44ClpGUyBmaWxlc3lz dGVtIHZlcnNpb246IDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBzdXBwb3J0 ICg1MDAwKQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCm52bWUgY2FtIHByb2Jl IGRldmljZSBpbml0CmhkYWNjMDogPFJlYWx0ZWsgQUxDMjY5IEhEQSBDT0RFQz4gYXQgY2FkIDAg b24gaGRhYzAKaGRhYTA6IDxSZWFsdGVrIEFMQzI2OSBBdWRpbyBGdW5jdGlvbiBHcm91cD4gYXQg bmlkIDEgb24gaGRhY2MwCnBjbTA6IDxSZWFsdGVrIEFMQzI2OSAoQW5hbG9nIDIuMCtIUC8yLjAp PiBhdCBuaWQgMjAsMjEgYW5kIDE4IG9uIGhkYWEwCnBjbTE6IDxSZWFsdGVrIEFMQzI2OSAoUmVh ciBBbmFsb2cgTWljKT4gYXQgbmlkIDI0IG9uIGhkYWEwCmhkYWNjMTogPEludGVsIENhbnRpZ2Eg SERBIENPREVDPiBhdCBjYWQgMyBvbiBoZGFjMApoZGFhMTogPEludGVsIENhbnRpZ2EgQXVkaW8g RnVuY3Rpb24gR3JvdXA+IGF0IG5pZCAxIG9uIGhkYWNjMQpwY20yOiA8SW50ZWwgQ2FudGlnYSAo SERNSSA4Y2gpPiBhdCBuaWQgMyBvbiBoZGFhMQp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXMyOiAxMk1icHMg RnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1 c2J1czQ6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVzYnVzNTogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKdXNidXM2OiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czc6IDQ4 ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuNy4xOiA8SW50ZWwgRUhDSSByb290IEhVQj4g YXQgdXNidXM3CnVodWIwOiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNwp1Z2VuNi4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXM2CnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNgp1Z2VuNS4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXM1CnVodWIyOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNQp1Z2VuNC4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXM0CnVodWIzOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNAp1Z2VuMy4xOiA8SW50ZWwgRUhDSSByb290IEhVQj4g YXQgdXNidXMzCnVodWI0OiA8SW50ZWwgRUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMwp1Z2VuMi4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXMyCnVodWI1OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMgp1Z2VuMS4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXMxCnVodWI2OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMC4xOiA8SW50ZWwgVUhDSSByb290IEhVQj4g YXQgdXNidXMwCnVodWI3OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dl cmVkCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNjog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjU6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVodWI3OiAyIHBvcnRzIHdpdGggMiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZApzZXMwIGF0IGFoY2llbTAgYnVzIDAgc2NidXM0IHRhcmdldCAwIGx1 biAwCnNlczA6IDxBSENJIFNHUElPIEVuY2xvc3VyZSAxLjAwIDAwMDE+IFNFTUIgUy1FLVMgMi4w MCBkZXZpY2UKc2VzMDogU0VNQiBTRVMgRGV2aWNlCmFkYTAgYXQgYWhjaWNoMCBidXMgMCBzY2J1 czAgdGFyZ2V0IDAgbHVuIDAKYWRhMDogPFAzLTEyOCAxLjAwPiBBQ1MtNCBBVEEgU0FUQSAzLngg ZGV2aWNlCmFkYTA6IFNlcmlhbCBOdW1iZXIgMDg3MDkxODYxMzY4CmFkYTA6IDMwMC4wMDBNQi9z IHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gODE5MmJ5dGVzKQphZGEwOiBDb21tYW5k IFF1ZXVlaW5nIGVuYWJsZWQKYWRhMDogMTIyMTA0TUIgKDI1MDA2OTY4MCA1MTIgYnl0ZSBzZWN0 b3JzKQphZGExIGF0IGFoY2ljaDEgYnVzIDAgc2NidXMxIHRhcmdldCAwIGx1biAwCmFkYTE6IDxL SU5HU1RPTiBTVjMwMFMzN0ExMjBHIDYwQUFCQkYwPiBBVEE4LUFDUyBTQVRBIDMueCBkZXZpY2UK YWRhMTogU2VyaWFsIE51bWJlciA1MDAyNkI3NjZBMDEyMDQwCmFkYTE6IDMwMC4wMDBNQi9zIHRy YW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQSU8gNTEyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVl dWVpbmcgZW5hYmxlZAphZGExOiAxMTQ0NzNNQiAoMjM0NDQxNjQ4IDUxMiBieXRlIHNlY3RvcnMp ClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnptIFtdLi4uClJvb3QgbW91bnQgd2FpdGlu ZyBmb3I6IHVzYnVzNyB1c2J1czMKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3IHVzYnVz Mwp1aHViNDogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjA6IDYg cG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVzYl9hbGxvY19kZXZpY2U6IHNl dCBhZGRyZXNzIDIgZmFpbGVkIChVU0JfRVJSX0lPRVJST1IsIGlnbm9yZWQpClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzNwpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcKdXNiZF9z ZXR1cF9kZXZpY2VfZGVzYzogZ2V0dGluZyBkZXZpY2UgZGVzY3JpcHRvciBhdCBhZGRyIDIgZmFp bGVkLCBVU0JfRVJSX0lPRVJST1IKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3CnVnZW43 LjI6IDxTdVlpbiBJbnRlZ3JhdGVkIENhbWVyYT4gYXQgdXNidXM3CndsYW4wOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDoyNjpjNzo3ZDo2OTpiMgpicmlkZ2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjo3 ODplMzphNjo0NTowMApyZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dOCml3bjA6IGl3bl9y ZWFkX2Zpcm13YXJlOiB1Y29kZSByZXY9MHgyNzFmMDUwMQp3bGFuMDogbGluayBzdGF0ZSBjaGFu Z2VkIHRvIFVQCldBUk5JTkc6IGF0dGVtcHQgdG8gZG9tYWluX2FkZChibHVldG9vdGgpIGFmdGVy IGRvbWFpbmZpbmFsaXplKCkK ------=_Part_1408566_461147516.1534850996965 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="uname-output" Content-ID: <65e64ee9-b767-9858-a45d-e4cfb21c4a33@yahoo.com> RnJlZUJTRCBkZW5pcyAxMS4xLVJFTEVBU0UtcDEzIEZyZWVCU0QgMTEuMS1SRUxFQVNFLXAxMyAj MDogVHVlIEF1ZyAxNCAxOTozNDoyMSBVVEMgMjAxOCAgICAgcm9vdEBhbWQ2NC1idWlsZGVyLmRh ZW1vbm9sb2d5Lm5ldDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDICBhbWQ2NAo= ------=_Part_1408566_461147516.1534850996965 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="loader.conf" Content-ID: <75f7864b-ff6c-2709-9d53-d7eb1713bd92@yahoo.com> I2FoY2lfbG9hZD0iWUVTIgp6ZnNfbG9hZD0iWUVTIgp2ZnMuemZzLnByZWZldGNoX2Rpc2FibGU9 IjAiCnZmcy5yb290Lm1vdW50ZnJvbT0iemZzOnptIgpmdXNlX2xvYWQ9IllFUyIKI2N1c2U0YnNk X2xvYWQ9IllFUyIgIyBGcmVlQlNEIDwgMTEueCwgcGFja2FnZSBmcm9tIHBvcnRzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VzZV9sb2FkPSJZRVMiCmN1c2VfbG9hZD0iWUVT IiAjIEZyZWVCU0QgPj0gMTEueCwgcGFydCBvZiBkZWZhdWx0IGtlcm5lbCBidWlsZApjcHVmcmVx X2VuYWJsZT0iWUVTIgphY3BpX2libV9sb2FkPSJZRVMiCnNuZF9oZGFfbG9hZD0iWUVTIgppY2hz bWJfbG9hZD0iWUVTIgpzbWJfbG9hZD0iWUVTIgojI2lmX2l3bl9sb2FkPSJZRVMiCiMjaXduMTAw MGZ3X2xvYWQ9IllFUyIKc2RoY2lfbG9hZD0iWUVTIgojbmdfdWJ0X2xvYWQ9IllFUyIKI25nX2hj aV9sb2FkPSJZRVMiCiNuZ19uZXRncmFwaF9sb2FkPSJZRVMiCmxpbnV4X2xvYWQ9IllFUyIKaWZf dGFwX2xvYWQ9IllFUyIKI3Zib3hkcnZfbG9hZD0iWUVTIgoKaHcucHNtLnN5bmFwdGljc19zdXBw b3J0PSIxIgpody5wc20udHJhY2twb2ludF9zdXBwb3J0PSIxIgoKI2tlcm4uaXBjLnNlbW1ucz0i MzIwMDAiCiNrZXJuLmlwYy5zZW1tbmk9IjEyOCIKI2tlcm4uaXBjLnNobW1uaT0iNDA5NiIKCnZt LmttZW1fc2l6ZT0iNTEyTSIKdm0ua21lbV9zaXplX21heD0iNTEyTSIKdmZzLnpmcy5hcmNfbWF4 PSIxNjBNIgp2ZnMuemZzLnZkZXYuY2FjaGUuc2l6ZT0iNU0iIAoKaTkxNWttc19sb2FkPSJZRVMi Cmtlcm4udnR5PXZ0CiNody52Z2EudGV4dG1vZGU9MQoja2Vybi52dC5mYi5kZWZhdWx0X21vZGU9 IjEwMjR4NzY4IgoKYmVhc3RpZV9kaXNhYmxlPSJZRVMiCmxvYWRlcl9sb2dvPSJub25lIgo= ------=_Part_1408566_461147516.1534850996965 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rc.conf" Content-ID: aG9zdG5hbWU9ImRlbmlzIgoKemZzX2VuYWJsZT0iWUVTIgpmdXNlZnNfZW5hYmxlPSJZRVMiCiNr cWVtdV9lbmFibGU9IllFUyIKbGludXhfZW5hYmxlPSJZRVMiCgpkZXZkX2VuYWJsZT0iWUVTIgpk ZXZmc19zeXN0ZW1fcnVsZXNldD0iZGV2ZnNydWxlc19jb21tb24iCgptb3VzZWRfZW5hYmxlPSJZ RVMiCgpwb3dlcmRfZW5hYmxlPSJZRVMiCnBvd2VyZF9mbGFncz0iLWEgaGlhZGFwdGl2ZSAtYiBh ZGFwdGl2ZSIKCnVzYmRfZW5hYmxlPSJZRVMiCgpkYnVzX2VuYWJsZT0iWUVTIgojaGFsZF9lbmFi bGU9IllFUyIKCndlYmNhbWRfZW5hYmxlPSJZRVMiCgpkdW1wZGV2PSJOTyIKY2xlYXJfdG1wX2Vu YWJsZT0iWUVTIgpzeXNsb2dkX2ZsYWdzPSItc3MiCgprZXliZWxsPSJxdWlldC5vZmYiCmtleXJh dGU9ImZhc3QiCmJsYW5rdGltZT0iMzAwIgpzYXZlcj0iZ3JlZW4iCgojc2Nybm1hcD0ia29pOC1y MmNwODY2Igoja2V5bWFwPSJydS5rb2k4LXIud2luIgoKI2ZvbnQ4eDE2PSJjcDg2Ni04eDE2Igoj Zm9udDh4MTQ9ImNwODY2LTh4MTQiCiNmb250OHg4PSJjcDg2Ni04eDgiCgpoY3NlY2RfZW5hYmxl PSJZRVMiCgojcmZjb21tX3BwcGRfc2VydmVyX2VuYWJsZT0iWUVTIgojcmZjb21tX3BwcGRfc2Vy dmVyX3Byb2ZpbGU9InJmY29tbS1kYWlsdXAiCiNyZmNvbW1fcHBwZF9zZXJ2ZXJfcmZjb21tLWRh aWx1cF9yZWdpc3Rlcl9kdW49IllFUyIKCiNwZl9lbmFibGU9IllFUyIKI3BmX3J1bGVzPSIvZXRj L3BmLmNvbmYiCiNwZl9mbGFncz0iIgojcGZsb2dfZW5hYmxlPSJZRVMiCiNwZmxvZ19sb2dmaWxl PSIvdmFyL2xvZy9wZi5sb2ciCiNwZmxvZ19mbGFncz0iIgoKY2xvbmVkX2ludGVyZmFjZXM9ImJy aWRnZTAiCmF1dG9icmlkZ2VfaW50ZXJmYWNlcz0iYnJpZGdlMCIKYXV0b2JyaWRnZV9icmlkZ2Uw PSJ0YXAqIgoKaWZjb25maWdfYnJpZGdlMD0iaW5ldCAxOTIuMTY4LjEuMjU0IG5ldG1hc2sgMjU1 LjI1NS4yNTUuMCIKCiNzdGF0aWNfcm91dGVzPSJpbnRlcm5hbG5ldDEiCiNyb3V0ZV9pbnRlcm5h bG5ldDE9Ii1uZXQgMTkyLjE2OC4xLjAvMjQgMTkyLjE2OC4xLjI1NCIKCmlmY29uZmlnX3JlMD0i REhDUCIKCndsYW5zX2l3bjA9IndsYW4wIgppZmNvbmZpZ193bGFuMD0iV1BBIFNZTkNESENQIgoK b3BlbnZwbl9pZj0idGFwIgoKZ2F0ZXdheV9lbmFibGU9IllFUyIKCiNmaXJld2FsbF9lbmFibGU9 IllFUyIKI2ZpcmV3YWxsX3R5cGU9Ik9QRU4iCiNmaXJld2FsbF90eXBlPSJDTElFTlQiCiNmaXJl d2FsbF9jbGllbnRfbmV0PSIxOTIuMTY4LjAuMC8yNCIKCiNuYXRkX2VuYWJsZT0iWUVTIgojbmF0 ZF9pbnRlcmZhY2U9InJlMCIKI25hdGRfZmxhZ3M9IiIKCnNzaGRfZW5hYmxlPSJZRVMiCgpudHBk X2VuYWJsZT0iWUVTIgpudHBkX3N5bmNfb25fc3RhcnQ9IllFUyIKCiNpbmV0ZF9lbmFibGU9IllF UyIKCiNjbnVwbV9lbmFibGU9IllFUyIKI2NudXBtX2lmYWNlPSJ0dW4wIgojY251cG1fZmxhZ3M9 Ii1hIDEgLWVwRCAtZiBpbmV0IC11IGNudXBtIgoKI2RoY3BkX2VuYWJsZT0iWUVTIgojZGhjcGRf aWZhY2VzPSIiCgojemlwcm94eV9lbmFibGU9IllFUyIKCnNlbmRtYWlsX2VuYWJsZT0iTk9ORSIK CiNwb3N0Z3Jlc3FsX2VuYWJsZT0iWUVTIgoKI215c3FsX2VuYWJsZT0iWUVTIgojYXBhY2hlMjRf ZW5hYmxlPSJZRVMiCg== ------=_Part_1408566_461147516.1534850996965 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sysctl.conf" Content-ID: IyAkRnJlZUJTRDogcmVsZW5nLzExLjEvZXRjL3N5c2N0bC5jb25mIDExMjIwMCAyMDAzLTAzLTEz IDE4OjQzOjUwWiBtdXggJAojCiMgIFRoaXMgZmlsZSBpcyByZWFkIHdoZW4gZ29pbmcgdG8gbXVs dGktdXNlciBhbmQgaXRzIGNvbnRlbnRzIHBpcGVkIHRocnUKIyAgYGBzeXNjdGwnJyB0byBhZGp1 c3Qga2VybmVsIHZhbHVlcy4gIGBgbWFuIDUgc3lzY3RsLmNvbmYnJyBmb3IgZGV0YWlscy4KIwoK IyBVbmNvbW1lbnQgdGhpcyB0byBwcmV2ZW50IHVzZXJzIGZyb20gc2VlaW5nIGluZm9ybWF0aW9u IGFib3V0IHByb2Nlc3NlcyB0aGF0CiMgYXJlIGJlaW5nIHJ1biB1bmRlciBhbm90aGVyIFVJRC4K I3NlY3VyaXR5LmJzZC5zZWVfb3RoZXJfdWlkcz0wCgpody5wc20uc3luYXB0aWNzLnR3b19maW5n ZXJfc2Nyb2xsPTAK ------=_Part_1408566_461147516.1534850996965-- From owner-freebsd-stable@freebsd.org Tue Aug 21 13:21:03 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15A281071C8E for ; Tue, 21 Aug 2018 13:21:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5954182EB5 for ; Tue, 21 Aug 2018 13:21:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7LDL0SR038525 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2018 09:21:00 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7LDKxnB088054; Tue, 21 Aug 2018 09:20:59 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: gpart strangeness To: Eugene Grosbein , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> From: Mike Tancsa Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> Date: Tue, 21 Aug 2018 09:20:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 13:21:03 -0000 On 8/20/2018 11:34 PM, Eugene Grosbein wrote: >> I was trying to create a single partition on a 16G mSata drive and >> whenever I add a partition, all of a sudden the secondary GPT partion is >> borked. Any idea whats going on here ? >> > > Did you look to "dmesg -a" output for additional hints? > What is system version? RELENG11 r337953 AMD64 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number DED9075313EC01677930 ada0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) ada0: Command Queueing enabled ada0: 15272MB (31277232 512 byte sectors) Other than the message when I create the partition, nada GEOM: diskid/DISK-DED9075313EC01677930: the secondary GPT table is corrupt or invalid. GEOM: diskid/DISK-DED9075313EC01677930: using the primary only -- recovery suggested. I tried different alignment options for the partition, and no changes. Doing MBR however seems to work for some reason 0# gpart destroy -F ada0 ada0 destroyed 0# gpart create -s mbr ada0 ada0 created 0# gpart add -t freebsd ada0 ada0s1 added 0# ls -l /dev/ada0* crw-r----- 1 root operator - 0x4b Jan 19 23:59 /dev/ada0 crw-r----- 1 root operator - 0x7a Jan 20 22:09 /dev/ada0s1 crw-r----- 1 root operator - 0x7c Jan 20 22:09 /dev/ada0s1a 0# newfs -U -O2 /dev/ada0s1a /dev/ada0s1a: 15272.1MB (31277168 sectors) block size 32768, fragment size 4096 using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952 0# However, when I try to write to the disk, it crashes the box. I wonder if this is a bad batch of mSata SSDs.... Hmmm login: panic: ufs_dirbad: /mnt: bad dir ino 2 at offset 0: mangled entry cpuid = 3 KDB: stack backtrace: #0 0xffffffff80642407 at kdb_backtrace+0x67 #1 0xffffffff805fbc37 at vpanic+0x177 #2 0xffffffff805fbab3 at panic+0x43 #3 0xffffffff808255d1 at ufs_lookup_ino+0xe21 #4 0xffffffff80929f6c at VOP_CACHEDLOOKUP_APV+0x7c #5 0xffffffff806a9c86 at vfs_cache_lookup+0xd6 #6 0xffffffff80929e4c at VOP_LOOKUP_APV+0x7c #7 0xffffffff806b3691 at lookup+0x6d1 #8 0xffffffff806b2b59 at namei+0x489 #9 0xffffffff806c9168 at kern_statat+0x98 #10 0xffffffff806c931c at sys_fstatat+0x2c #11 0xffffffff80889778 at amd64_syscall+0xa38 #12 0xffffffff8086a1fd at fast_syscall_common+0x101 Uptime: 1m6s PCEngines apu3 coreboot build 20170302 4080 MB ECC DRAM SeaBIOS (version rel-1.10.0.1) Press F10 key now for boot menu Booting from Hard Disk... F1 FreeBSD F2 FreeBSD F5 Drive 1 F6 PXE Boot: F1 /boot/config: -h -S115200 If I create a gpart, I can write to the disk, but there is corruption behind the scenes 0# gpart create -s gpt ada0 ada0 created 0# gpart add -t freebsd-ufs ada0 ada0p1 added 0# newfs newfs newfs_msdos 0# newfs -U -O2 /dev/ada0p1 /dev/ada0p1: 15272.0MB (31277152 sectors) block size 32768, fragment size 4096 using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates super-block backups (for fsck_ffs -b #) at: 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712, 30773952 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/test1 bs=4096k count=200 200+0 records in 200+0 records out 838860800 bytes transferred in 44.383275 secs (18900381 bytes/sec) 0# md5 /mnt/test1 MD5 (/mnt/test1) = 02fba9e2f3795f13b864c8613c8ae49e 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/test2 bs=4096k count=100 100+0 records in 100+0 records out 419430400 bytes transferred in 22.194061 secs (18898317 bytes/sec) 0# md5 /mnt/test1 MD5 (/mnt/test1) = 318ee3900564460b14e4e80e0bb8f358 0# ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Tue Aug 21 13:52:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 651F810730D2 for ; Tue, 21 Aug 2018 13:52:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D4A65845A4 for ; Tue, 21 Aug 2018 13:52:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w7LDq7ws062094 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Aug 2018 15:52:08 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mike@sentex.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w7LDq3tm095221 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Aug 2018 20:52:03 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: gpart strangeness To: Mike Tancsa , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> From: Eugene Grosbein Message-ID: Date: Tue, 21 Aug 2018 20:51:58 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 13:52:17 -0000 21.08.2018 20:20, Mike Tancsa wrote: > On 8/20/2018 11:34 PM, Eugene Grosbein wrote: >>> I was trying to create a single partition on a 16G mSata drive and >>> whenever I add a partition, all of a sudden the secondary GPT partion is >>> borked. Any idea whats going on here ? >> >> Did you look to "dmesg -a" output for additional hints? >> What is system version? > > RELENG11 r337953 AMD64 > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-3 ATA SATA 3.x device > ada0: Serial Number DED9075313EC01677930 > ada0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 15272MB (31277232 512 byte sectors) > > Other than the message when I create the partition, nada > > GEOM: diskid/DISK-DED9075313EC01677930: the secondary GPT table is > corrupt or invalid. > GEOM: diskid/DISK-DED9075313EC01677930: using the primary only -- > recovery suggested. > > I tried different alignment options for the partition, and no changes. > Doing MBR however seems to work for some reason > > 0# gpart destroy -F ada0 > ada0 destroyed > 0# gpart create -s mbr ada0 > ada0 created > 0# gpart add -t freebsd ada0 > ada0s1 added > 0# ls -l /dev/ada0* > crw-r----- 1 root operator - 0x4b Jan 19 23:59 /dev/ada0 > crw-r----- 1 root operator - 0x7a Jan 20 22:09 /dev/ada0s1 > crw-r----- 1 root operator - 0x7c Jan 20 22:09 /dev/ada0s1a > 0# newfs -U -O2 /dev/ada0s1a > /dev/ada0s1a: 15272.1MB (31277168 sectors) block size 32768, fragment > size 4096 > using 25 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. > with soft updates > super-block backups (for fsck_ffs -b #) at: > 192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, > 10258112, 11540352, 12822592, 14104832, 15387072, 16669312, 17951552, > 19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232, > 28209472, 29491712, 30773952 > 0# > > > However, when I try to write to the disk, it crashes the box. I wonder > if this is a bad batch of mSata SSDs.... Hmmm > > > login: panic: ufs_dirbad: /mnt: bad dir ino 2 at offset 0: mangled entry It seems like faulty media to me: it silently returns bad data. There is an easy way to verify this just with naked eye: yes | dd bs=128k of=/dev/ada0 hd /dev/ada0 That is, hd(1) should write back only 3 lines of output: 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| * 01000000 If not, the media if faulty. From owner-freebsd-stable@freebsd.org Tue Aug 21 18:30:55 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FC9C107B982 for ; Tue, 21 Aug 2018 18:30:55 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CB7290FAC for ; Tue, 21 Aug 2018 18:30:53 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7LIUqVB030501 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Aug 2018 14:30:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.ca [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7LIUoWX090058; Tue, 21 Aug 2018 14:30:50 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: gpart strangeness To: Eugene Grosbein , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> From: Mike Tancsa Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Date: Tue, 21 Aug 2018 14:30:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 18:30:55 -0000 On 8/21/2018 9:51 AM, Eugene Grosbein wrote: > > It seems like faulty media to me: it silently returns bad data. > > There is an easy way to verify this just with naked eye: > > yes | dd bs=128k of=/dev/ada0 > hd /dev/ada0 > > That is, hd(1) should write back only 3 lines of output: > > 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| > * > 01000000 > > If not, the media if faulty. > There are 3 of these disks I found. Unfortunately, they all seem a little different from the revision stamps on the board. They are all from PCEngines who generally seem to source quality products. This is in an APU3 A "bad" disk 0# camcontrol identify ada0 pass0: ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-10 SATA 3.x device model SATA SSD firmware revision S9FM02.0 serial number DED9075313EC01677930 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no 0# vs a 'good' disk # camcontrol identify ada0 pass0: ACS-4 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-11 SATA 3.x device model SATA SSD firmware revision SBFM01.0 serial number A44907781CE300040613 WWN 5000000000000000 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload no no general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no % diff good bad 1c1 < pass0: ACS-4 ATA SATA 3.x device --- > pass0: ACS-3 ATA SATA 3.x device 4c4 < protocol ATA/ATAPI-11 SATA 3.x --- > protocol ATA/ATAPI-10 SATA 3.x 6,8c6,7 < firmware revision SBFM01.0 < serial number A44907781CE300040613 < WWN 5000000000000000 --- > firmware revision S9FM02.0 > serial number DED9075313EC01677930 34c33 < advanced power management no no --- > advanced power management yes no 0/0x00 39c38 < unload no no --- > unload yes yes 46a46 > 1# yes | dd bs=128k of=/dev/ada0 dd: /dev/ada0: short write on character device dd: /dev/ada0: end of device 0+1066621 records in 122176+1 records out 16013942784 bytes transferred in 566.461990 secs (28270110 bytes/sec) 1# hd /dev/ada0 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| * 3ba816000 0# -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Tue Aug 21 18:43:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29277107C229 for ; Tue, 21 Aug 2018 18:43:17 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) (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 CCF4591DCE for ; Tue, 21 Aug 2018 18:43:16 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from hammy.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5B7855646E; Tue, 21 Aug 2018 13:43:10 -0500 (CDT) Subject: Re: gpart strangeness To: Mike Tancsa , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> From: Eric van Gyzen Message-ID: <2cfb1ceb-7f42-9c00-bbdc-1fbf8036edd1@vangyzen.net> Date: Tue, 21 Aug 2018 13:43:09 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 18:43:17 -0000 On 8/21/18 1:30 PM, Mike Tancsa wrote: > There are 3 of these disks I found. Unfortunately, they all seem a > little different from the revision stamps on the board. They are all > from PCEngines who generally seem to source quality products. This is in > an APU3 I have an APU2.  My disk is exactly like your 'good' disk, except for the serial number, obviously.  I don't have any trouble. Maybe you can update the firmware on your bad disk.  I have no idea how. Eric From owner-freebsd-stable@freebsd.org Wed Aug 22 01:55:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 387D31086F0F; Wed, 22 Aug 2018 01:55:07 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D33D479E3B; Wed, 22 Aug 2018 01:55:06 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 931CD101AB; Wed, 22 Aug 2018 01:55:06 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f170.google.com with SMTP id c22-v6so303149iob.1; Tue, 21 Aug 2018 18:55:06 -0700 (PDT) X-Gm-Message-State: APzg51AVJNCBjuxyJJ39FLhBJHPg6NHe1oA4HjEyH6imYePZAZ1Tu8cY u5T2FHQv/hA2HBhwlo7B+Ai3OJvnYmRpLhgAbIM= X-Google-Smtp-Source: ANB0Vda3RyZzbAzQS1sufVblGKXMa9ugYSSpxCulob4Abnu1a5l0vs8BPrNh7N8VjlAybaQlFHD1pEYQXJUpvy3/SDI= X-Received: by 2002:a5e:dd4b:: with SMTP id u11-v6mr3621713iop.237.1534902905949; Tue, 21 Aug 2018 18:55:05 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Tue, 21 Aug 2018 18:54:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: drm / drm2 removal in 12 To: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 01:55:07 -0000 Just in case anyone misses the change to UPDATING: 20180821: drm and drm2 have been removed. Users on powerpc, 32-bit hardware, or with GPUs predating Radeon and i915 will need to install the graphics/drm-legacy-kmod. All other users should be able to use one of the LinuxKPI-based ports: graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod. Note that this applies only to 12. -M From owner-freebsd-stable@freebsd.org Wed Aug 22 02:03:20 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46BAC1087559 for ; Wed, 22 Aug 2018 02:03:20 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BDAF37A614 for ; Wed, 22 Aug 2018 02:03:19 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: by mail-ed1-x531.google.com with SMTP id f38-v6so410081edd.8 for ; Tue, 21 Aug 2018 19:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cordula-ws.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=iM9D6/CfuB+SLZv9YZVcea4bHWQcd3QARN5jzea2mDc=; b=BpbXuIJTXlE6fKrgK5FzsAlfzEU7A99pkUFdB8SOIsIe2RKnEg6WuR5cy5l8ZqXTse gDuZiouNjdRPKscdytz3xZoLwNFyVKw4i0QC1Tuz6U25wN7tdsBlt1FCgu8bA0vyqciq 6kpD3ENlYSi4hWraqz6AJ8Jn+slloASRWlJCWzFL5jQ/KiYdaPYBJvZ3Move56gzST3s Lvf3DsaSgMbAMcDiTdIaGRB8VMf0d0q7HB3u2uo3To/exdB5fKs2NGWegeBshwHTlz+d 3lyW2WAj8mPgdFvNbl+2dhx0hKnLzlTswkGRo3LoMuRkF+F6HWK4qK6stvz/kqH/7ctU Nlcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=iM9D6/CfuB+SLZv9YZVcea4bHWQcd3QARN5jzea2mDc=; b=aFf38sSU90lIe52/EYK4tjHKYbvUepT8M1ZX3H7xNSeoyaEjIgWtjYq9Tw/ZpE3eEk LwFMcBqTG3Td5x0dRScwOgyYeA4TZ22S1HxpmA0e+DZF8n/tJkxZrA5pX0pE+cOMSKAp knIlmrPCOolqoNMsRZOdh6zNKhdcgr03Pjr9YZcZt8EfBQuk1P+QXIijl3O0h1R3YFbv 52Lgr50tTRy5CQ/zaf5OWLR/BfUMSm8s5oVSxLhNOk8ZIkb96l5HZDjVFh0Zg3dWFfvU w1lTP0gKZDJPDIYGO8x26u+NJgd/l2imT7GHRlryyBx50ztWRRHtNRNIIgnbtuvaHtFM JPvA== X-Gm-Message-State: AOUpUlFUTJYC5Pvjpq7fqLoicTALdKC4TeGT9usP0rkRC2dN5rLkZ7bU bs6rtpeJZW4348OsdTGSTMMnqTfUZek= X-Google-Smtp-Source: AA+uWPzeAccu2jnu4s7grbwn9V0jKXHfurNScGFTM/84dIiKTGq+OZP1SFYtrLkyWw0GRstgA57HYA== X-Received: by 2002:a50:8dcb:: with SMTP id s11-v6mr61908387edh.86.1534903398233; Tue, 21 Aug 2018 19:03:18 -0700 (PDT) Received: from ?IPv6:2a02:908:960:c43e:2efd:a1ff:fe57:abb8? ([2a02:908:960:c43e:2efd:a1ff:fe57:abb8]) by smtp.gmail.com with ESMTPSA id t44-v6sm309427edd.96.2018.08.21.19.03.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 19:03:16 -0700 (PDT) Subject: Re: drm / drm2 removal in 12 To: freebsd-stable@freebsd.org References: From: cpghost Message-ID: <1bfb7527-7fbf-be46-c1fa-3a7ab22e5580@cordula.ws> Date: Wed, 22 Aug 2018 04:03:15 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000304010207050004060407" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 02:03:20 -0000 This is a cryptographically signed message in MIME format. --------------ms000304010207050004060407 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 8/22/18 3:54 AM, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: >=20 > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardwa= re, > or with GPUs predating Radeon and i915 will need to install the= > graphics/drm-legacy-kmod. All other users should be able to use= > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. >=20 > Note that this applies only to 12. Thanks for the headsup. Will graphics/drm-stable-kmod be updated on 11-STABLE from 4.11 to 4.15? Currently, OpenCL stuff ist broken with drm-stable-kmod and amdgpu... -Thanks, cpghost. > -M --------------ms000304010207050004060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cx4wggUwMIIEGKADAgECAhEAxi8czu5BfArXx+KbCt8qNjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjIwMDAw MDAwWhcNMTgxMjIwMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJjcGdob3N0QGNvcmR1bGEu d3MwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCuV3EBb8py/1yrTdT8cb8h5Ocl h5XDYOn2HNcGCENONWU7Rrz9X+suOufiGCwUzrj+ysDLzM/jfB8EQMFH+uZrt9hi1gb9QvXh jzHvHqrb0P6Bj/HV8VvWyywa+BbuHNxuvOHB+ECpQYs4/Itfyhr4F/08FhweUpP7W+NKK/m8 VvLyY3kT5T58DYN0AvxgN6LK0ejbKD44wOrjK4EwuZpRmKewuWi+VquqRS04vo6xVE+h2tqq BUmVv4q9S6fHnvDcDCg3Gs4NTc6eujsHK6O9SLcgKB3CkHm5mxMkqGWNvtLb9p3/y9A+/v3n 2GRE07mmRkeJ43ntSytkz5xCiYmpAgMBAAGjggHoMIIB5DAfBgNVHSMEGDAWgBSCr2yM+MX+ lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQUJVBhgnBvX0Bb+4bCJ8KLFjYJ4powDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBL hklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv bTAdBgNVHREEFjAUgRJjcGdob3N0QGNvcmR1bGEud3MwDQYJKoZIhvcNAQELBQADggEBAAZ0 otdXgClU/ijwGvnOdARI7LVDD4pPg6BD1kTbMywUE6ti082zAvujveH4DkleGZaVByv1VHGV HAdB8S7P21bm2uGCxwJNdRGl2R8USNmE7OP0EXYlQLTXDQbpBBPoB8k5Tv8WGJfguxIrPpS6 L729xb5d75NoKFMYn8JHTlujcfYt5TZCir0tO5/B9BgfB01tokFQ814wpUWmXplnD+tfRLaJ OChKmyUnOi5qpBntd/PHpUDNFIUJy0QZ3sYt1PyW7ejhtMvGvI/cQLZdDOUXv432nu0dgy2K 8PDGRfhp/NZhW8He7ililwDIu4B229OfiKI3fpPCDtm+xz7V900wggXmMIIDzqADAgECAhBq m+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00 SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0 RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq 8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmO upyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOC ATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM +MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEE ZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRU cnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqG SIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxC DBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt /eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77 ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT 3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWB f/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5I SYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwxCTP9 bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S /GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDgwggQ0AgEBMIGt MIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQH EwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RP IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMYvHM7u QXwK18fimwrfKjYwDQYJYIZIAWUDBAIBBQCgggJbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDgyMjAyMDMxNVowLwYJKoZIhvcNAQkEMSIEIBjkwNmC 8q5IW38n5/6LLC010sv/khz29F/80VDxcXLZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDGLxzO7kF8CtfH 4psK3yo2MIHABgsqhkiG9w0BCRACCzGBsKCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP IENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDGLxzO7kF8CtfH4psK3yo2MA0GCSqGSIb3DQEBAQUA BIIBADjdkBV9xQb4jk/SQPbp64BwwFFXGWaKgwjYWMrJ6agyU3IlXP1hP5hwNtSOu2oic6Eo oLLWYOu4poNB25yBR3cn4RNUaIJXDdmynw4886TdgPrp745T04XTmdn9XtTDMFRLiTzzND3d rEhx4fQeOMteOrPvhPLBhishF1xfqZkaqZOEHBQIddbVy1JjUd0qDd8K3X+uH0I6D3Qps//C J0+zQYNqhc6vt6IwMNuIy4qdodk3HVfWJIUQhX0sSUd5y9Bq38nVoV8N3Mc3k3AKtbNWUp/n bBnoafsUhoaJlYxau/l97rz8vQBoERUj8hKTzXVHN8QhtLRleRV4DVD6AYoAAAAAAAA= --------------ms000304010207050004060407-- From owner-freebsd-stable@freebsd.org Wed Aug 22 05:24:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 414AE108CF6F for ; Wed, 22 Aug 2018 05:24:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 D0C848265E for ; Wed, 22 Aug 2018 05:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 95A00108CF68; Wed, 22 Aug 2018 05:24:27 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 847CC108CF66 for ; Wed, 22 Aug 2018 05:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25D148265D for ; Wed, 22 Aug 2018 05:24:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7402A11493 for ; Wed, 22 Aug 2018 05:24:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w7M5OQDC082813 for ; Wed, 22 Aug 2018 05:24:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7M5OQcW082812 for stable@FreeBSD.org; Wed, 22 Aug 2018 05:24:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 228535] emulators/virtualbox-ose-kmod: 11.2-BETA3 - kldload vboxdrv leads to panic Date: Wed, 22 Aug 2018 05:24:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Documentation X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: doc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status version product assigned_to component resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 05:24:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228535 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Version|11.1-STABLE |Latest Product|Base System |Documentation Assignee|bugs@FreeBSD.org |doc@FreeBSD.org Component|kern |Documentation Resolution|--- |FIXED --- Comment #10 from Kubilay Kocak --- Issue was documented (with workaround) in the 11.2-RELEASE Errata notes [1]: [2018-06-26] An issue had been discovered late in the release cycle where a system crash could occur after installing emulators/virtualbox-ose from upstream package mirrors via pkg(8). Building emulators/virtualbox-ose from the ports(7) collection has been observed to work around the crash. [1] https://www.freebsd.org/releases/11.2R/errata.html --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Wed Aug 22 13:56:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A58671089BC6; Wed, 22 Aug 2018 13:56:51 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 43AE275625; Wed, 22 Aug 2018 13:56:51 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CED3B416; Wed, 22 Aug 2018 09:56:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Aug 2018 09:56:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=tLlAXzwiQg5aea8b9jU8DKU90a8WH +fa/WVYjW7B9Tw=; b=mCC/vWAOKIRMPOpSOjUHDB0CvjLjzvOVzw2gqP9rH0UGP gnK717N4alGysUAuazmnfbmmMuZ8y2TcZNsZ9ssw3enZT+KH4/JNsr3/RpBVmnm7 jjLGOAE6zfYVWpd+fY4r0aJVV9ixCyuVEQO9Hx6+uGHyjPC+d3vmdghg8sBIo+tC j/IhwWj5ZUJ7vCfENzLiN6HCU4LcwTHbILawLte+jape47o1uzC13brit82QlDvt mDW0MpH4w7gPHg7MNa+eJ9uhANDetWRSTTaQQF57pxFPwgRzUesDSD4eRbWpOa/7 QVbOYXCYYp28xJFO+umFLNZTHXuoM55b5g0JQIU+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tLlAXz wiQg5aea8b9jU8DKU90a8WH+fa/WVYjW7B9Tw=; b=mrCBgEuBZ1Qx826ECxZIr9 P3xTAe1JkcD2r4uXJJktJqdqld39AUaxn2/SU64qz8tJZqoHqA62JpYN5Flk/znx DMDtm4rpnl5YKWYHxd5IbhBjDHsYZ1BmEz7qRLJtlYPly89JjvXNomVoa7EMyboB a6lgytOf3SnnOuy8cW2aWmf54ItN+bGCVC8i67s5oEI2fJxUiXMFZAHcDbmfrcRu FtNOc35xA11z7CHVk1DAP7b1Sdho+3Figt/AGLdVeyYZAFemt1YEv6TW5NM+Oabw bzZRf09o6yDIRH9uIp+YB7zR5lKCaGW6McFd45JypYLeFCh1k0LFLsFacb8LzJRA == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FE15E4818; Wed, 22 Aug 2018 09:56:48 -0400 (EDT) Subject: Re: problems with installworld To: Polytropon Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org References: <1534585160.3056848.1478206184.0EBD80FB@webmail.messagingengine.com> <20180818151503.7da44655.freebsd@edvax.de> From: tech-lists Organization: none Message-ID: <59778e2a-ad7a-746e-ec37-31a23430daf8@zyxst.net> Date: Wed, 22 Aug 2018 14:56:48 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180818151503.7da44655.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 13:56:51 -0000 On 18/08/2018 14:15, Polytropon wrote: > Try to follow the instructions on top of /usr/src/Makefile > (comment header). Before you perform "make installworld", > make sure you have rebooted the system into single-user mode > (with the new kernel). > > Also see "man 7 build" for details. > > yep, that fixed it, sorry for the noise ;) -- J. From owner-freebsd-stable@freebsd.org Wed Aug 22 16:17:19 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DD73108D4CF for ; Wed, 22 Aug 2018 16:17:19 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9B937C124 for ; Wed, 22 Aug 2018 16:17:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7MGHGdq062833 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2018 12:17:17 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7MGHEWh094296; Wed, 22 Aug 2018 12:17:14 -0400 (EDT) (envelope-from mike@sentex.net) Subject: mSATA strangeness (was Re: gpart strangeness) From: Mike Tancsa To: Eugene Grosbein , FreeBSD-STABLE Mailing List , Eric van Gyzen References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <3c606f0b-41a2-b654-9413-8b0f1be2f651@sentex.net> Date: Wed, 22 Aug 2018 12:17:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 16:17:19 -0000 OK, Some more odd things going on. If I write to a file from dd some random junk, not all of the file is saved when I do an unmount. This seems to be specific either to the ata controller of the APU or to the msata disk as I tested on a regular server with plain old disks and no issue Eric, any chance you can try this on your APU as well ? 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 0# hd /mnt/junk2 > /tmp/hd-junk2 0# ls -l /mnt/junk2 -rw------- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb 0# ls -l /mnt/junk2 -rw------- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount 0# ls -l /tmp/hd-junk2* -rw------- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 -rw------- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount 0# If I do the same test on a USB stick it works as expected 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# Same with an SD card. All is OK 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# Looking at hd before and after, its missing the end of the file --- hd-junk2 2018-08-22 11:54:09.891572000 -0400 +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 @@ -24574,106500 +24574,6 @@ 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 |.q..x.r...;.1...| 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb |.9r..9...u...VC.| 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f |@.T...>......i.o| -00060000 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 |..........h.=..C| -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 |.[N..7..[....'.T| -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 |.l.}....JJ......| -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 |.<...ONb....^'.q| -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 |."......d....#sg| -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 |.x...p.."...;u..| -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 |S9...9_.. ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-10 SATA 3.x device model SATA SSD firmware revision S9FM02.0 serial number 81B5074C1B6500076878 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queued no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no 0# On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. >> >> There is an easy way to verify this just with naked eye: >> >> yes | dd bs=128k of=/dev/ada0 >> hd /dev/ada0 >> >> That is, hd(1) should write back only 3 lines of output: >> >> 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| >> * >> 01000000 >> >> If not, the media if faulty. >> > > There are 3 of these disks I found. Unfortunately, they all seem a > little different from the revision stamps on the board. They are all > from PCEngines who generally seem to source quality products. This is in > an APU3 > > A "bad" disk > > 0# camcontrol identify ada0 > pass0: ACS-3 ATA SATA 3.x device > pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > > protocol ATA/ATAPI-10 SATA 3.x > device model SATA SSD > firmware revision S9FM02.0 > serial number DED9075313EC01677930 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 31277232 sectors > LBA48 supported 31277232 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > Zoned-Device Commands no > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queued no > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management yes no 0/0x00 > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify no no > unload yes yes > general purpose logging yes yes > free-fall no no > Data Set Management (DSM/TRIM) yes > DSM - max 512byte blocks yes 8 > DSM - deterministic read no > Host Protected Area (HPA) yes no 31277232/31277232 > HPA - Security no > 0# > > vs > a 'good' disk > > # camcontrol identify ada0 > pass0: ACS-4 ATA SATA 3.x device > pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > > protocol ATA/ATAPI-11 SATA 3.x > device model SATA SSD > firmware revision SBFM01.0 > serial number A44907781CE300040613 > WWN 5000000000000000 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 31277232 sectors > LBA48 supported 31277232 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > Zoned-Device Commands no > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queued no > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify no no > unload no no > general purpose logging yes yes > free-fall no no > Data Set Management (DSM/TRIM) yes > DSM - max 512byte blocks yes 8 > DSM - deterministic read no > Host Protected Area (HPA) yes no 31277232/31277232 > HPA - Security no > > > > % diff good bad > 1c1 > < pass0: ACS-4 ATA SATA 3.x device > --- >> pass0: ACS-3 ATA SATA 3.x device > 4c4 > < protocol ATA/ATAPI-11 SATA 3.x > --- >> protocol ATA/ATAPI-10 SATA 3.x > 6,8c6,7 > < firmware revision SBFM01.0 > < serial number A44907781CE300040613 > < WWN 5000000000000000 > --- >> firmware revision S9FM02.0 >> serial number DED9075313EC01677930 > 34c33 > < advanced power management no no > --- >> advanced power management yes no 0/0x00 > 39c38 > < unload no no > --- >> unload yes yes > 46a46 >> > > 1# yes | dd bs=128k of=/dev/ada0 > dd: /dev/ada0: short write on character device > dd: /dev/ada0: end of device > 0+1066621 records in > 122176+1 records out > 16013942784 bytes transferred in 566.461990 secs (28270110 bytes/sec) > 1# hd /dev/ada0 > 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a > |y.y.y.y.y.y.y.y.| > * > 3ba816000 > 0# > -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Wed Aug 22 16:19:10 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44C61108D58E for ; Wed, 22 Aug 2018 16:19:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1B307C25C for ; Wed, 22 Aug 2018 16:19:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fsVqe-00083F-7j for freebsd-stable@freebsd.org; Wed, 22 Aug 2018 16:19:08 +0000 Date: Wed, 22 Aug 2018 09:19:07 -0700 Message-ID: From: Randy Bush To: FreeBSD Stable Subject: Re: bad hash in repo In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 16:19:10 -0000 > seeing a lot of these > > Looking up update.FreeBSD.org mirrors... 2 mirrors found. > Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > Fetching 2 patches.. done. > Applying patches... done. > Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorrect hash. these continue; like for a week. for multiple servers, all on the global internet no filters other than samba etc. randy From owner-freebsd-stable@freebsd.org Wed Aug 22 16:46:34 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7722F108EA57 for ; Wed, 22 Aug 2018 16:46:34 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (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 F17507E0AE for ; Wed, 22 Aug 2018 16:46:33 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 71bd45bf TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Wed, 22 Aug 2018 09:46:32 -0700 (PDT) Subject: Re: bad hash in repo To: freebsd-stable@freebsd.org References: From: Pete Wright Message-ID: <40cbc4e4-c0c8-e9f7-ba88-48dc226b032a@nomadlogic.org> Date: Wed, 22 Aug 2018 09:46:30 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 16:46:34 -0000 On 8/22/18 9:19 AM, Randy Bush wrote: >> seeing a lot of these >> >> Looking up update.FreeBSD.org mirrors... 2 mirrors found. >> Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done. >> Fetching metadata index... done. >> Inspecting system... done. >> Preparing to download files... done. >> Fetching 2 patches.. done. >> Applying patches... done. >> Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorrect hash. > these continue; like for a week. for multiple servers, all on the > global internet no filters other than samba etc. have you forced pulling down metadata from the pkg servers?  i have gotten into this state in the past and a "pkg update -f" would get me out of that scenario. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Wed Aug 22 17:47:29 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD55510904D1 for ; Wed, 22 Aug 2018 17:47:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 207A880F0E for ; Wed, 22 Aug 2018 17:47:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7MHlR2M086933 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2018 13:47:27 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7MHlPvc096172; Wed, 22 Aug 2018 13:47:25 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: gpart strangeness (solved) From: Mike Tancsa To: Eugene Grosbein , FreeBSD-STABLE Mailing List References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: Date: Wed, 22 Aug 2018 13:47:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 17:47:29 -0000 On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. OK, it was a config issue on my part! Some legacy config from the long ago days of Soekris 5501s, had hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf Commenting those out fixed the issue! Sorry for the noise everyone! ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Wed Aug 22 17:48:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 179DF109051A for ; Wed, 22 Aug 2018 17:48:33 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E8580FA8 for ; Wed, 22 Aug 2018 17:48:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w7MHmVJk087256 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Aug 2018 13:48:32 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w7MHmTKT096175; Wed, 22 Aug 2018 13:48:30 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: mSATA strangeness (was Re: gpart strangeness) From: Mike Tancsa To: Eugene Grosbein , FreeBSD-STABLE Mailing List , Eric van Gyzen References: <4e5b6d81-7fc5-c538-2bd2-8cd5dd040a1d@sentex.net> <6be4ee74-c09d-b88f-e4ed-cadb1537e478@grosbein.net> <7886da80-d2e3-1562-07df-cb955d888e1b@sentex.net> <62183e11-77ad-9b6d-ed57-357764e988d8@sentex.net> <3c606f0b-41a2-b654-9413-8b0f1be2f651@sentex.net> Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <76177786-2e0e-2a21-fcaa-e07695b7d49a@sentex.net> Date: Wed, 22 Aug 2018 13:48:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3c606f0b-41a2-b654-9413-8b0f1be2f651@sentex.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 17:48:33 -0000 Never mind, I found the issue hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf, hanging around from the days of wood burning power supplies was causing this strange behaviour! Sorry for the noise folks! ---Mike On 8/22/2018 12:17 PM, Mike Tancsa wrote: > OK, > Some more odd things going on. If I write to a file from dd some random > junk, not all of the file is saved when I do an unmount. This seems to > be specific either to the ata controller of the APU or to the msata disk > as I tested on a regular server with plain old disks and no issue > > Eric, any chance you can try this on your APU as well ? > > > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 > 0# hd /mnt/junk2 > /tmp/hd-junk2 > 0# ls -l /mnt/junk2 > -rw------- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb > 0# ls -l /mnt/junk2 > -rw------- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount > 0# ls -l /tmp/hd-junk2* > -rw------- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 > -rw------- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount > 0# > > If I do the same test on a USB stick it works as expected > > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# > Same with an SD card. All is OK > > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# > > Looking at hd before and after, its missing the end of the file > > --- hd-junk2 2018-08-22 11:54:09.891572000 -0400 > +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 > @@ -24574,106500 +24574,6 @@ > 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 > |.q..x.r...;.1...| > 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb > |.9r..9...u...VC.| > 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f > |@.T...>......i.o| > -00060000 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 > |..........h.=..C| > -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 > |.[N..7..[....'.T| > -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 > |.l.}....JJ......| > -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 > |.<...ONb....^'.q| > -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 > |."......d....#sg| > -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 > |.x...p.."...;u..| > -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 > |S9...9_.. -00060070 ea f0 2f 19 3c 6d 1c 21 f1 58 4a 4b a8 26 8e f6 > |../. -00060080 05 99 8a 9d 54 75 e4 77 78 78 6c 75 21 31 d4 0c > |....Tu.wxxlu!1..| > -00060090 52 88 c6 65 c0 09 04 ce 7f 5f 29 0c 46 9a 68 13 > |R..e....._).F.h.| > -000600a0 73 30 97 78 d7 b7 d2 ba 8f 73 27 58 3d eb 0c d6 > |s0.x.....s'X=...| > > > 1# camcontrol identify ada0 > pass0: ACS-3 ATA SATA 3.x device > pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > > protocol ATA/ATAPI-10 SATA 3.x > device model SATA SSD > firmware revision S9FM02.0 > serial number 81B5074C1B6500076878 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 31277232 sectors > LBA48 supported 31277232 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > Zoned-Device Commands no > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queued no > SMART yes yes > microcode download yes yes > security yes no > power management yes yes > advanced power management yes no 0/0x00 > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify no no > unload yes yes > general purpose logging yes yes > free-fall no no > Data Set Management (DSM/TRIM) yes > DSM - max 512byte blocks yes 8 > DSM - deterministic read no > Host Protected Area (HPA) yes no 31277232/31277232 > HPA - Security no > 0# > > > > On 8/21/2018 2:30 PM, Mike Tancsa wrote: >> On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >>> >>> It seems like faulty media to me: it silently returns bad data. >>> >>> There is an easy way to verify this just with naked eye: >>> >>> yes | dd bs=128k of=/dev/ada0 >>> hd /dev/ada0 >>> >>> That is, hd(1) should write back only 3 lines of output: >>> >>> 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a |y.y.y.y.y.y.y.y.| >>> * >>> 01000000 >>> >>> If not, the media if faulty. >>> >> >> There are 3 of these disks I found. Unfortunately, they all seem a >> little different from the revision stamps on the board. They are all >> from PCEngines who generally seem to source quality products. This is in >> an APU3 >> >> A "bad" disk >> >> 0# camcontrol identify ada0 >> pass0: ACS-3 ATA SATA 3.x device >> pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) >> >> protocol ATA/ATAPI-10 SATA 3.x >> device model SATA SSD >> firmware revision S9FM02.0 >> serial number DED9075313EC01677930 >> cylinders 16383 >> heads 16 >> sectors/track 63 >> sector size logical 512, physical 512, offset 0 >> LBA supported 31277232 sectors >> LBA48 supported 31277232 sectors >> PIO supported PIO4 >> DMA supported WDMA2 UDMA6 >> media RPM non-rotating >> Zoned-Device Commands no >> >> Feature Support Enabled Value Vendor >> read ahead yes yes >> write cache yes yes >> flush cache yes yes >> overlap no >> Tagged Command Queuing (TCQ) no no >> Native Command Queuing (NCQ) yes 32 tags >> NCQ Queue Management no >> NCQ Streaming no >> Receive & Send FPDMA Queued no >> SMART yes yes >> microcode download yes yes >> security yes no >> power management yes yes >> advanced power management yes no 0/0x00 >> automatic acoustic management no no >> media status notification no no >> power-up in Standby no no >> write-read-verify no no >> unload yes yes >> general purpose logging yes yes >> free-fall no no >> Data Set Management (DSM/TRIM) yes >> DSM - max 512byte blocks yes 8 >> DSM - deterministic read no >> Host Protected Area (HPA) yes no 31277232/31277232 >> HPA - Security no >> 0# >> >> vs >> a 'good' disk >> >> # camcontrol identify ada0 >> pass0: ACS-4 ATA SATA 3.x device >> pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) >> >> protocol ATA/ATAPI-11 SATA 3.x >> device model SATA SSD >> firmware revision SBFM01.0 >> serial number A44907781CE300040613 >> WWN 5000000000000000 >> cylinders 16383 >> heads 16 >> sectors/track 63 >> sector size logical 512, physical 512, offset 0 >> LBA supported 31277232 sectors >> LBA48 supported 31277232 sectors >> PIO supported PIO4 >> DMA supported WDMA2 UDMA6 >> media RPM non-rotating >> Zoned-Device Commands no >> >> Feature Support Enabled Value Vendor >> read ahead yes yes >> write cache yes yes >> flush cache yes yes >> overlap no >> Tagged Command Queuing (TCQ) no no >> Native Command Queuing (NCQ) yes 32 tags >> NCQ Queue Management no >> NCQ Streaming no >> Receive & Send FPDMA Queued no >> SMART yes yes >> microcode download yes yes >> security yes no >> power management yes yes >> advanced power management no no >> automatic acoustic management no no >> media status notification no no >> power-up in Standby no no >> write-read-verify no no >> unload no no >> general purpose logging yes yes >> free-fall no no >> Data Set Management (DSM/TRIM) yes >> DSM - max 512byte blocks yes 8 >> DSM - deterministic read no >> Host Protected Area (HPA) yes no 31277232/31277232 >> HPA - Security no >> >> >> >> % diff good bad >> 1c1 >> < pass0: ACS-4 ATA SATA 3.x device >> --- >>> pass0: ACS-3 ATA SATA 3.x device >> 4c4 >> < protocol ATA/ATAPI-11 SATA 3.x >> --- >>> protocol ATA/ATAPI-10 SATA 3.x >> 6,8c6,7 >> < firmware revision SBFM01.0 >> < serial number A44907781CE300040613 >> < WWN 5000000000000000 >> --- >>> firmware revision S9FM02.0 >>> serial number DED9075313EC01677930 >> 34c33 >> < advanced power management no no >> --- >>> advanced power management yes no 0/0x00 >> 39c38 >> < unload no no >> --- >>> unload yes yes >> 46a46 >>> >> >> 1# yes | dd bs=128k of=/dev/ada0 >> dd: /dev/ada0: short write on character device >> dd: /dev/ada0: end of device >> 0+1066621 records in >> 122176+1 records out >> 16013942784 bytes transferred in 566.461990 secs (28270110 bytes/sec) >> 1# hd /dev/ada0 >> 00000000 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a 79 0a >> |y.y.y.y.y.y.y.y.| >> * >> 3ba816000 >> 0# >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Thu Aug 23 02:26:06 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 285B0109DC80 for ; Thu, 23 Aug 2018 02:26:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C729B79E8C for ; Thu, 23 Aug 2018 02:26:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fsfJz-0001jS-Ir; Thu, 23 Aug 2018 02:26:03 +0000 Date: Wed, 22 Aug 2018 19:26:03 -0700 Message-ID: From: Randy Bush To: Pete Wright Cc: freebsd-stable@freebsd.org Subject: Re: bad hash in repo In-Reply-To: <40cbc4e4-c0c8-e9f7-ba88-48dc226b032a@nomadlogic.org> References: <40cbc4e4-c0c8-e9f7-ba88-48dc226b032a@nomadlogic.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 02:26:06 -0000 >>> seeing a lot of these >>>=20 >>> Looking up update.FreeBSD.org mirrors... 2 mirrors found. >>> Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org..= . done. >>> Fetching metadata index... done. >>> Inspecting system... done. >>> Preparing to download files... done. >>> Fetching 2 patches.. done. >>> Applying patches... done. >>> Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b= 74103e88dbc77 has incorrect hash. >> these continue; like for a week. for multiple servers, all on the >> global internet no filters other than samba etc. >=20 > have you forced pulling down metadata from the pkg servers?=A0 i have > gotten into this state in the past and a "pkg update -f" would get me > out of that scenario. # pkg update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9kB/s 00:01 =20 Fetching packagesite.txz: 100% 6 MiB 2.2MB/s 00:03 =20 Processing entries: 100% FreeBSD repository update completed. 32029 packages processed. All repositories are up to date. # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 2 mirrors found. Fetching metadata signature for 11.1-RELEASE from update5.freebsd.org... do= ne. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. Fetching 2 patches.. done. Applying patches... done. Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b7410= 3e88dbc77 has incorrect hash. From owner-freebsd-stable@freebsd.org Thu Aug 23 16:40:46 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABA951092374 for ; Thu, 23 Aug 2018 16:40:46 +0000 (UTC) (envelope-from bounce@ims4.isendservice.com.br) Received: from ims4.isendservice.com.br (ims4.isendservice.com.br [54.232.89.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2797C79C05 for ; Thu, 23 Aug 2018 16:40:45 +0000 (UTC) (envelope-from bounce@ims4.isendservice.com.br) Received: from localhost (localhost [127.0.0.1]) by ims4.isendservice.com.br (Postfix) with ESMTP id D48364530F for ; Thu, 23 Aug 2018 13:37:48 -0300 (BRT) Date: Thu, 23 Aug 2018 13:37:48 -0300 (BRT) From: =?utf-8?Q?Sistema=20FIERGS=20=7C=20SENAI-RS?= Reply-To: faculdadesenai@senairs.org.br To: freebsd-stable@freebsd.org Message-ID: <61862406.1856633.1535042268549.JavaMail.root@ims4> Subject: =?utf-8?Q?Portas=20Abertas=20SENAI=20=7C=20Porto=20Alegre=20=7C=2025=20de=20agosto?= bounce-key: <2420-22522874-2202486> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 16:40:47 -0000 From owner-freebsd-stable@freebsd.org Fri Aug 24 13:28:22 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E42A108A176 for ; Fri, 24 Aug 2018 13:28:22 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD82685ED4 for ; Fri, 24 Aug 2018 13:28:21 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: by mail-ua1-x92e.google.com with SMTP id w7-v6so5356481uan.9 for ; Fri, 24 Aug 2018 06:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-bg-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wiYfBPsHLhwzNEpVFEDiME3EZ6b9yVI4k45kIUIatJs=; b=gRc5wBHFmp5LmAr6B2Wmu/4mD84tE5ZrKp9tTMZMYKF1JdYEvoJuJzxPpNyxIlpU43 u+YN8IQKjliKAFFo4mHtqJlZjQJe/AKm1ceK7uA4G/yFfGST9GPQSbZ+VM1izIsi13IJ EhfUy+i714a3Y33TbhUuxlUr5zW0v48hJwqkwDbodcNmYTewKbKVz5LMrX/HegeBlRuI 9YepIYEGSGAA3FOS711qjxu6xncxA8F65spmKXUMaPt9yn7e7cPSLrCXqCR/3/KW6j/g rCQVu3ToEFxXGI3krxlXnU1Ws/plLALmyp/XBvZGHdfCQBgDa2T/0tyoASzHubdIK4Sf Ej0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wiYfBPsHLhwzNEpVFEDiME3EZ6b9yVI4k45kIUIatJs=; b=NSmBeRFe4zwmryqjjbc6/x7QJD422ZkEcO8RX98AqZCLZVtNJ0uWFbZDYkb/hNylEO 934jL3WqKSFp78F0RqSuMYjrKtxxPgR6+HS6M+SzpVCfAYfrfTIB2/c44tiKQppuXaMu rFgN8h7eqs8SRnYM0X8Vjd/6OuuYgT1GWA8+tfA2PvgA+NxLokOoW8D7M1JSEAHG3lbq thmCFPc4HPIsshpFDtnm0QuiLSbfOBgfuN+g3uM2e+1NN16F62Z6TXgJAT0/IlUd3m2T +VCN1xylRo3zIm+w0YQ8ai8lNcih88BlVsC1trV1s+ckWv5sj13+bLNWLqBvD8u57Y6B 4tCg== X-Gm-Message-State: APzg51DPCQAOfFZcM0IU3Ky5ttSJeFIM58ltgJZtKOi5IfTbjXwLrapo Ym0HrlCm9emcBzDaeuzPhWVVclg26TggTGR29I0juKKWfOc= X-Google-Smtp-Source: ANB0Vda9LPGZYddTxaQDtd1+l8liK07N28jZW6tVnsDqJ7PdvyUvBPAHDYsCp1f9gXpakwqGGWsH9B9qC+z+Mzv9SHE= X-Received: by 2002:a9f:3bd1:: with SMTP id y17-v6mr1038276uah.177.1535117300012; Fri, 24 Aug 2018 06:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9f4d:0:0:0:0:0 with HTTP; Fri, 24 Aug 2018 06:28:19 -0700 (PDT) From: Stefan Lambrev Date: Fri, 24 Aug 2018 16:28:19 +0300 Message-ID: Subject: Strange unbound behaviour To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 13:28:22 -0000 Hi, I have two DNS servers up and running for my home setup. But for some reason both stop resolving at some point. 1st instance is with unbbound from ports, second from base system but configs are very similar: # cat /usr/local/etc/unbound/unbound.conf # This file was generated by local-unbound-setup. # Modifications will be overwritten. server: interface: 0.0.0.0 port: 53 do-ip4: yes do-ip6: no do-udp: yes do-tcp: yes use-caps-for-id: yes username: unbound directory: /usr/local/etc/unbound chroot: /usr/local/etc/unbound pidfile: /var/run/local_unbound.pid auto-trust-anchor-file: /usr/local/etc/unbound/root.key use-syslog: yes logfile: "log/unbound.log" statistics-interval: 600 verbosity: 1 access-control: 127.0.0.0/8 allow access-control: 10.1.1.0/24 allow hide-identity: yes hide-version: yes num-threads: 6 include: /usr/local/etc/unbound/forward.conf include: /usr/local/etc/unbound/lan-zones.conf include: /usr/local/etc/unbound/control.conf include: /usr/local/etc/unbound/conf.d/*.conf If I restart the service it works again... root@umbrella:~# host dir.bg 127.0.0.1 ;; connection timed out; no servers could be reached umbrella:~# /etc/rc.d/local_unbound restart Stopping local_unbound. Waiting for PIDS: 645. Starting local_unbound. [1535116695] unbound[81742:0] warning: too many file descriptors requested. The builtinmini-event cannot handle more than 1024. Config for less fds or compile with libevent [1535116695] unbound[81742:0] warning: continuing with less udp ports: 139 Waiting for nameserver to start... good [16:18]root@umbrella:~# host dir.bg 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: dir.bg has address 194.145.63.12 dir.bg mail is handled by 1 mail.dir.bg. Exactly the same behaviour on the other server. The servers do not have many clients - it's a home network. If've tried to debug this, but I do not see any errors in the logs, no sign of low buffers or whatever. The thing is that it looks like very easy to reproduce in my environment - just launch the service use it for few days (sometimes hours) and it just stops resolving new requests (cache is working, local zone are working and etc) Oh and If I reduce "num-threads" it's even easier to reproduce. Anyone with similar experience? From owner-freebsd-stable@freebsd.org Fri Aug 24 15:51:23 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BEE0108D751 for ; Fri, 24 Aug 2018 15:51:23 +0000 (UTC) (envelope-from matt.xtaz@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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DD838B9A8 for ; Fri, 24 Aug 2018 15:51:22 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id t25-v6so2089662wmi.3 for ; Fri, 24 Aug 2018 08:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3Of/hfXSrZezWkusW42ANC4/b0vQT3C9JeNnjaapIvY=; b=oV62nA3OT8p0rVR11gNAOxOcajB7t0NaZc+ID9aEG7/i9SJgsmbeyS2HK2kMZXzisu paFG5chyu+2oTDKkP3DLvA7+H+Scw7uThbuEBtWJavhsPQ8hsMZ8OP7wORwolv1uP4iv WsRVzZcRqu70a/5151i/oiLwUGyeSwgAr+IVrTMlrJ/Ma4AI8o9R/+PiC/2GlshJzFvW 53mhIKbs1j7Z4kOzM5bwCiE6Z+eKXTmbQPpld4IdfjCROPAqDUA5lRO+QJVbYT5sj1+k w1PpkyQwB6CkNbATvXrYUFsrPqv2lOJF1sOLprj4DSV6pGBllz9K661yZeCxpfkb4ubI GGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=3Of/hfXSrZezWkusW42ANC4/b0vQT3C9JeNnjaapIvY=; b=mDyj4FuKT7R4C8tSgYWiru1MvtgNkG5PyAGleZH6sRStwm6M7XSdK++An47+32Aoyl 30uhR8JFiRamrSVLgST7wTECVQY+KnxSDRztUMtuN5g4O9pE4Qsyvx9ydiqUa/0Y9M+J 31AqW5XTkwJmL4hBdVnQ3+t5g9GjLLPK31dLbOtbJvew0/NLGsoVwG2CXsOGQ5HXveMc FfQ8ypJfY2M+xy27VPRZa34yxX2qhRJNtrbTrAUPyScoLeBCgnrGi0NWC+Wdy3E6lEGE 0taUD2hUFawhGhMSZnZdGW7hLuKlU8k/32IXLZGcSidsvsLZP7kkd8ywEesAhWLYIJRm H+qg== X-Gm-Message-State: APzg51A0s0ot0SG2Lm+v4/c/gi41Nu+08leGAUMUQIUJKfiAnaP7NKJN MYbd5Xazk5iLkNNcenxwDV772ri5 X-Google-Smtp-Source: ANB0VdbaxqhRIuswztlkWSEjArkYOl4v3ecQKwvZKIGFCEzaIv86f/n34zIW1V12FG6vvwLPnm10eg== X-Received: by 2002:a1c:65c5:: with SMTP id z188-v6mr1785933wmb.57.1535125881678; Fri, 24 Aug 2018 08:51:21 -0700 (PDT) Received: from gmail.com (tao.xtaz.uk. [2a02:390:7e52::10]) by smtp.gmail.com with ESMTPSA id f17-v6sm5521738wrs.1.2018.08.24.08.51.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Aug 2018 08:51:21 -0700 (PDT) Date: Fri, 24 Aug 2018 16:51:19 +0100 From: Matt Smith To: Stefan Lambrev Cc: freebsd-stable@freebsd.org Subject: Re: Strange unbound behaviour Message-ID: <20180824155119.GA66993@gmail.com> Mail-Followup-To: Matt Smith , Stefan Lambrev , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:51:23 -0000 On Aug 24 16:28, Stefan Lambrev wrote: >Hi, > >I have two DNS servers up and running for my home setup. But for some >reason both stop resolving at some point. > >1st instance is with unbbound from ports, second from base system but >configs are very similar: > ># cat /usr/local/etc/unbound/unbound.conf > directory: /usr/local/etc/unbound > chroot: /usr/local/etc/unbound > >If I restart the service it works again... > In man(5) unbound.conf it says this: # make sure unbound can access entropy from inside the chroot. # e.g. on linux the use these commands (on BSD, devfs(8) is used): # mount --bind -n /dev/random /etc/unbound/dev/random I can see that you use a chroot. I'm wondering if you've not mounted a /dev/random into the chroot and maybe it's running out of free entropy for something and blocking. This might explain why it works for a while and then fails. I do this: In /etc/fstab: devfs /usr/local/etc/unbound/dev devfs rw 0 0 In /etc/rc.conf: devfs_set_rulesets="/usr/local/etc/unbound/dev=devfsrules_unbound" In /etc/devfs.rules: [devfsrules_unbound=10] add hide add path random unhide Might help? -- Matt From owner-freebsd-stable@freebsd.org Fri Aug 24 17:14:05 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C963108F966 for ; Fri, 24 Aug 2018 17:14:05 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D808B8E94C for ; Fri, 24 Aug 2018 17:14:04 +0000 (UTC) (envelope-from cheffo@freebsd-bg.org) Received: by mail-vk0-x22e.google.com with SMTP id 125-v6so4617615vke.11 for ; Fri, 24 Aug 2018 10:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-bg-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mLB5qWJ60xutrq3wQeDJfIH6dkS52d47UZr/kezmoWE=; b=sW91zz3oG18BMrLcW7aYfI2QxTzEFnYd8d4XBq+Q01KtMZCSFKSnMketE1gTM+ztCi t3DagiOnJtPDitRVNGnhM+EPEje/q/dag7UQO+hHNz+AqhlRf8wlv4z780qr0x6qvR3S lIr++HYHDv/YVJ2iOoTdOrC7Y1mp+Lwjz1tR5q6liYlyQH/3KBjpUt+oiv1ZHlER1Dhm kfo40AD4xn5QZzMO9J8IKCZLII+vt7dVH8iyCRM8bNia6D52CeDcRiY09RD/JCWgzYWb 4Wbw4x7PiFplKlTatKmkQytqFpJnGcbst4jzRUe5Exgl2XRHkQgKH/p0CcC1ghxClGPQ AxXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mLB5qWJ60xutrq3wQeDJfIH6dkS52d47UZr/kezmoWE=; b=Bl959qyrwxB9RrT4V8YhKXA09RukCkj5n9fakZjtOPYJ+GpT/w18bv1ibdHm3G4e2Z qvprMXpvcxqtG8LhqKAgmhG+yNsgpDh1RE4EgMZMwvm1b3KAUMKu1jW273phJ6XH/8tF 43BSdAJC/9ju/YanQmbiH5NahnEK8NINavEkkZGa/rpGb1LyrezSr5Ezsx4HKYDhODJs DIqMsr8CQYiOGalVa4bi4YNFfs5SSRNvQ7owinIZzAPIEF9gGimIYVSqk/uYmSoPp4Qh UgXgax97VXEzp9orzo31KmvSw3BWSFdwbSCfQcYV1TSAfEHvNzYB7feKaDOe49pbdM2c H9cQ== X-Gm-Message-State: APzg51AnFsi7Ky7YSAxBjd0kBpyVacuKMYdig59fhO55XGl3Jl+AQ6B6 fYGxeJErEryWKUmPfxqi5EJzBuBUDfs+kdwekqgzpA== X-Google-Smtp-Source: ANB0VdasOuZ/sq7wcUwKqj/jaf8NSd60oIkmU9VUxDi7Jam7Bk/bXPLFIOv72wUGa7pxQ/aEt+XLN40NZQ1a4npxMgc= X-Received: by 2002:a1f:9ecd:: with SMTP id h196-v6mr1581476vke.157.1535130844199; Fri, 24 Aug 2018 10:14:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9f4d:0:0:0:0:0 with HTTP; Fri, 24 Aug 2018 10:14:03 -0700 (PDT) In-Reply-To: <20180824155119.GA66993@gmail.com> References: <20180824155119.GA66993@gmail.com> From: Stefan Lambrev Date: Fri, 24 Aug 2018 20:14:03 +0300 Message-ID: Subject: Re: Strange unbound behaviour To: Matt Smith , Stefan Lambrev , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 17:14:05 -0000 Hm.. looks like I missed this one. Will test and let you know. On Fri, Aug 24, 2018 at 6:51 PM, Matt Smith wrote: > On Aug 24 16:28, Stefan Lambrev wrote: > >> Hi, >> >> I have two DNS servers up and running for my home setup. But for some >> reason both stop resolving at some point. >> >> 1st instance is with unbbound from ports, second from base system but >> configs are very similar: >> >> # cat /usr/local/etc/unbound/unbound.conf >> directory: /usr/local/etc/unbound >> chroot: /usr/local/etc/unbound >> >> If I restart the service it works again... >> >> > In man(5) unbound.conf it says this: > > # make sure unbound can access entropy from inside the chroot. > # e.g. on linux the use these commands (on BSD, devfs(8) is used): > # mount --bind -n /dev/random /etc/unbound/dev/random > > I can see that you use a chroot. I'm wondering if you've not mounted a > /dev/random into the chroot and maybe it's running out of free entropy for > something and blocking. This might explain why it works for a while and > then fails. > > I do this: > > In /etc/fstab: > > devfs /usr/local/etc/unbound/dev devfs rw 0 > 0 > > In /etc/rc.conf: > > devfs_set_rulesets="/usr/local/etc/unbound/dev=devfsrules_unbound" > > In /etc/devfs.rules: > > [devfsrules_unbound=10] > add hide > add path random unhide > > Might help? > > -- > Matt > From owner-freebsd-stable@freebsd.org Fri Aug 24 21:53:06 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC3501094ABD; Fri, 24 Aug 2018 21:53:06 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 387B977FFA; Fri, 24 Aug 2018 21:53:06 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id n2-v6so8542912wrw.7; Fri, 24 Aug 2018 14:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ytAhTE1wNoJLS7qlLpanApV03J7UxSnyPtJWmU3FepM=; b=NWJpgy+EcjXLn3YEPfnYD4pvm4pXQDQhb5TmWHC0KpXOauQ4wp4CdTUjvPY8ke+Qci 5j/v5VvwFes2VeWDKJvohoM0HrZRITb5MC9Ow+ST8XnMIHH31xJ70A/3JyrutKwClzYe g2squOxEQQ3kQXDFNfAD/eV3egt3MRu+o7OfenTCwPxh/m3nnYJ0AnT9lOSKF8IesZ6b PJDAOdr49szksDLu0c+y4MHPrEhWlWOgyC0bgTthW14ZgQIqcQuVtZqYL8AByVARP6Xz iB5EAe7ps+xdgm5z7L3YlNxiIZ3nvLvpknGVhLDbIcmUqcr1vAoq9wbrEmITSN2coZQW 6yoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ytAhTE1wNoJLS7qlLpanApV03J7UxSnyPtJWmU3FepM=; b=K3r2Aju+GLhh1Ba/5RoWJjp3ocybEyy0O2XyZMr8C7+HltNHYISMDsI3gmlueTBJFX nBfWvB4o6FDshyqzcZeijI2I3r5O071XxoM9XkXUZ0Yf2jXcH8PTqqZ9ipPti6v5CR4B scbdtZQpYtvw6WX8wFuRIuA4jE1Gccs0Nu9O2yFhQQcAofqcQXGUcE8egY1IAmVzkZd0 n6TkPlCht7eXYrhjCWAG1aqK+Ig2IwpCDJ67LcNf+KY+BpSeH6qfl3JGCm/zL3vXSkFB f/Jthyje678NxhO3r5to5D5utE2dTT0EvgZF7eopoLuUVoPMJcNu4wvmihCrlhRbonyk 6LLw== X-Gm-Message-State: APzg51D9xzZvHG7A3vW6DPTnERQJ46IR5WMmqru6Pb6iwh9FiW/qKr5b kvldCcHiM7nTJuCsOHhsfalHPdhe X-Google-Smtp-Source: ANB0VdZTFCK5/exeuahrLNTev/IlM2odpNTqJzCjoCT32VwGTKAatHLtLB4+sBeFDp2VDLnL5AqKrg== X-Received: by 2002:adf:e648:: with SMTP id b8-v6mr2411265wrn.254.1535147584866; Fri, 24 Aug 2018 14:53:04 -0700 (PDT) Received: from freebsd480.station (net-2-39-246-29.cust.vodafonedsl.it. [2.39.246.29]) by smtp.gmail.com with ESMTPSA id h75-v6sm6443308wma.46.2018.08.24.14.53.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 14:53:04 -0700 (PDT) From: Ali X-Google-Original-From: Ali Date: Fri, 24 Aug 2018 23:53:02 +0200 To: Matthew Macy Cc: freebsd-current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 Message-ID: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 21:53:07 -0000 On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: > > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install the > graphics/drm-legacy-kmod. All other users should be able to use > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. > Note that this applies only to 12. I see that The removal of drm and drm2 has been reverted on svn. Could you please kindly share the reasons behind the re-inclusion? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Aug 24 22:19:35 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D500310954F9; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D6DE794E8; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 3A7C5A213; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f52.google.com with SMTP id t69-v6so3804068itb.4; Fri, 24 Aug 2018 15:19:34 -0700 (PDT) X-Gm-Message-State: APzg51AtpHvTriTCNZYHjYDnyDFJwex6mBsG1qYcHkNSZpWAp0v5vnt7 tKPdZWKM07Fz4X9WhQG25CCKgiGE4Ecf4KhQ6ZE= X-Google-Smtp-Source: ANB0Vdb82xCipaPvmswTEK+Rz4RPivDeBWpQpIbzyGTWFY8jxZvcTBsEiEkTuC7XXrbRA8kErWg7ZzQBQWLwRocRuOk= X-Received: by 2002:a02:88ad:: with SMTP id n42-v6mr2785567jaj.38.1535149173394; Fri, 24 Aug 2018 15:19:33 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Matthew Macy Date: Fri, 24 Aug 2018 15:19:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: drm / drm2 removal in 12 To: Ali Cc: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:19:35 -0000 On Fri, Aug 24, 2018 at 14:53 Ali wrote: > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > Just in case anyone misses the change to UPDATING: > > > > 20180821: > > drm and drm2 have been removed. Users on powerpc, 32-bit > hardware, > > or with GPUs predating Radeon and i915 will need to install the > > graphics/drm-legacy-kmod. All other users should be able to use > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > Note that this applies only to 12. > > I see that The removal of drm and drm2 has been reverted on svn. Could > you please kindly share the reasons behind the re-inclusion? > I can=E2=80=99t really give the blow by blow of internal project drama, but= the gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet actu= ally documented anywhere that I=E2=80=99ve seen) were not followed with regards to the depr= ecation process. Warner and others believe that we can address the objectives of the drm removal (improving the user experience and communicating that drm/drm2 are _completely_ unsupported apart from continuing to compile) through less disruptive means. I am only acting as a lightning rod and representative of the graphics team and so have done an inadequate job of tracking their activities with respect to project timelines. As a result of this misunderstanding Johannes Lundberg will be sponsored for a bit and will be able to be involved in internal discussions that impact his work. Our only continued frustration is that we were never given any guidance by RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion was= taking place in May and then those groups behaved as if this were a surprise when the removal happened. I=E2=80=99m cautiously optimistic that this well expedite improving communications on those matters. Cheers. -M From owner-freebsd-stable@freebsd.org Fri Aug 24 22:23:54 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A1481095838 for ; Fri, 24 Aug 2018 22:23:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD7F5799DB for ; Fri, 24 Aug 2018 22:23:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id k188-v6so4145984itk.3 for ; Fri, 24 Aug 2018 15:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vKhoMMpGKE9lNkEItER0HyK1G0fm5LHWkB+cZdxBBUs=; b=Tm46sNEzvv5fEwL4c6caaep9rf4komRDgJOlhLCHUYLUI3oydkuQzfa7rDDmazJqWg V1UVx89S1oMdY4yRBenZxow+z/v+ZA8A4PJ3VnLYa643nNZdtcnVD6OCKccFf9oKvMGY s8H9WMTlvqij6a4el6Lztp3WEPdFQHts3nY/rq5i5RcK2Ly9prx6XzYaWFKmF+CqfrX6 6yasvxAmuP4vXgeK2YBcCzPK7eb6G/xsfMarngdNVAvjwHEFzrdKMaE4m7kH3MRIsGmX 0ZCkuMZHTScu+Utw7HuzwlnxQ1K7UN7L/1OGGCMkDyVqxBnaULitXsjO0BKNgkZV00vR 1DWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vKhoMMpGKE9lNkEItER0HyK1G0fm5LHWkB+cZdxBBUs=; b=c5p5PEmIEVqmpuEYEHd9CTCMRGUP/Qp41Fw9NrC0jabggvqQ8RHzjaVrWtRFoCpLrB IYXozD0gV2FFYov/Q63SDoY6DB2DJAhubppYTpPvj4TZTDXlMVhbgYzKCJ0oXynBhwCj PV+Vj8TneaCAeMFW2NpEMe1HKCqCqmjbD93qD4zTxDEAszVBHlPeJ9eIjnubvYvo8H9t IgzDVxsLBpTKB484aGRDmy24Jq5lvyYo7HPfOg4gbDl44bjVUZcoJRj3FSGb0A+XBDCt YZ5CiCfRMgUXaFc6udmDT+btXuJfMRlOG/Mn7HK1puhIKb+CENgBtOQ2IRHCrulFVa+7 9fmw== X-Gm-Message-State: APzg51CbGstio1MYS4GL5XvCAUwWgmo3eXdxTRVWFgV86Etq3HPpe4xy 9osnyOXGJJZ5+y/UnKlcbFIh5uX59U7kBDgLjbWKlg== X-Google-Smtp-Source: ANB0VdbnUnvi0MSDZK960yxVFVElo8m4610NAnX4JYKUE1k0KKi+Li9uE6v1j75lxEeQP0njDFIye+bdcc+ZQgBpKHQ= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr2762608ite.39.1535149432879; Fri, 24 Aug 2018 15:23:52 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 16:23:42 -0600 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Matt Macy Cc: aliovx@gmail.com, FreeBSD Current , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:23:54 -0000 On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > Just in case anyone misses the change to UPDATING: > > > > > > 20180821: > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > hardware, > > > or with GPUs predating Radeon and i915 will need to install t= he > > > graphics/drm-legacy-kmod. All other users should be able to u= se > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > Note that this applies only to 12. > > > > I see that The removal of drm and drm2 has been reverted on svn. Could > > you please kindly share the reasons behind the re-inclusion? > > > > > I can=E2=80=99t really give the blow by blow of internal project drama, b= ut the > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet ac= tually documented > anywhere that I=E2=80=99ve seen) were not followed with regards to the de= precation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. > Just so. Our only continued frustration is that we were never given any guidance by > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion w= as taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I=E2=80=99m cautiously optimistic that this well expedi= te > improving communications on those matters. > All the problems that are exposed by this aren't technical. This one is social, but no less important. Warner From owner-freebsd-stable@freebsd.org Fri Aug 24 23:03:10 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48D6D1096C89 for ; Fri, 24 Aug 2018 23:03:10 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) 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 C30757B7DC for ; Fri, 24 Aug 2018 23:03:09 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8750D1096C88; Fri, 24 Aug 2018 23:03:09 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 655AD1096C87 for ; Fri, 24 Aug 2018 23:03:09 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D250F7B7D9 for ; Fri, 24 Aug 2018 23:03:08 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw1-xc29.google.com with SMTP id x67-v6so3679020ywg.0 for ; Fri, 24 Aug 2018 16:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fzNKefMSgVYF3amPd1IlYC7Y67CVTA1/AYsY3rY0C9Y=; b=XO6ILQqDMYrl7Epcruqc0cbG7cFbB1nS0dWe6Q117zs5/1hGAFuqNiBPTUx4CfeKb8 9A41KPz/Yr4kWbK50yFMNPA9jF+NyhvgZNZIVua+Pcjcfxiyoo3mAmezQvmjSw6udRok 2Jo6s2c/DLZ124dR42ifrfdoBKkD7c1WHC8M78G4gyRxnP7FMINVFB8Gq//7jRez4ejx Xw6TDJ4cJU52C325K1ftxwqk60N+4RrvWp+B/SKtSNXtIcfck2uOJB9oLBCuFihnoWWj PguqJN285tQkAl2U1WPLRdHcrRAcKv6bZGBcqc/gH1W2FYG5PFiy9umo+/wkfw2Co7vV j44g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fzNKefMSgVYF3amPd1IlYC7Y67CVTA1/AYsY3rY0C9Y=; b=W3gmOw9jU0Lr/dLlAlcIFlUwu/FNfHbMkydTH3qcARYPYP6NinWjdGkQpJr1xGnshL W5wLtFl1glb5f1vR0EmCcEaYzkPO9lbpFpYiT2kt43xutNkVPINo4Va64LAV4/Zqrp9O w7bA5+nGW6lZFDyI9GyXITOzbOnSlRgPu6cafycMnDBy+1DMYzT1zHmKHvqFq3bclrN6 cb98KEys6QjonX5waivOeQ39ZiIFa7iEBUZR+GbH/0I3Rx4YW03i21OrFxIcrO97+OHW BvNDkylogc4pktCc2mQI3XqjbNVF+d1SuwbDaYr0cbN3fdD/+BBy11JmVLbB92/UY+XT 382Q== X-Gm-Message-State: APzg51APe9itH1EmnhtASIOXE5krv9EzbOLKltb/ino78h552PPaw+ZH KvrvcZR5xoujOqea4BeULW99qo0OZOpMMhWjS6SgbP+T+20= X-Google-Smtp-Source: ANB0VdZ+rW6t9LauiLXCKFht0rjj4uM6hr+2NIjb1Kxz+FDZwiqfsOK1M0wb2mrt2WMKAhnTuhpteKGhlI73AEOlkds= X-Received: by 2002:a81:3843:: with SMTP id f64-v6mr2136092ywa.79.1535151787946; Fri, 24 Aug 2018 16:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:f205:0:0:0:0:0 with HTTP; Fri, 24 Aug 2018 16:03:07 -0700 (PDT) In-Reply-To: References: <5428C6C5-5627-44DD-A4ED-AF28A305C4F4@lists.zabbadoz.net> <20AA7D33-904F-494B-830F-59E09DC267E5@lists.zabbadoz.net> From: Oliver Pinter Date: Sat, 25 Aug 2018 01:03:07 +0200 Message-ID: Subject: Re: VNET related kernel panic on jail startup with epairs on 11-STABLE To: "Bjoern A. Zeeb" Cc: "stable@freebsd.org" , Ed Maste , Patrick Kelsey , Warner Losh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:03:10 -0000 On Monday, August 20, 2018, Oliver Pinter wrote: > On 8/3/18, Bjoern A. Zeeb wrote: > > On 3 Aug 2018, at 20:42, Oliver Pinter wrote: > > > >> On 8/3/18, Bjoern A. Zeeb wrote: > >>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote: > >>> > >>>> Hi all! > >>>> > >>>> One of out users observed an VNET related kernel panic with epairs > >>>> in > >>>> a jail. Seems like some of the > >>> > >>> Well would be great for a start to (a) email virtualisation@ as well, > >>> (b) include a panic message, backtrace or other related information > >>> to > >>> deduce anything about the possible bug, (c) and not to conflate it > >>> with > >>> another totally unrelated MFC request. > >>> > >>> So what makes you think it=E2=80=99s related to tcp fast open? > >> > >> Every required detail is in HardenedBSD's github issue, but I copy the > >> kernel panic here: > > > > Ah sorry my bad; the issue said ZFS in the subject and I thought it > > refers to something else. > > > > Thanks! Looking at the backtrace it seems it is happening on teardown > > and not on startup but indeed in the fast open code and that PR 216613 > > indeed fixed this in head, good :) Hope Patrick will do the mfc for > > you. > > Hi! > > Could you please you or Patrick MFC the above commits? > > So from HardenedBSD's point of view, we don't care about these MFCs, because we already MFCd them, but from FreeBSD users PoV it would be nice to get in at least before the next 11.X release... This was my last mail in this context. Have a better day. ;) > > > > /bz > > > From owner-freebsd-stable@freebsd.org Fri Aug 24 23:07:37 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14DFB1096DB8; Fri, 24 Aug 2018 23:07:37 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4997B967; Fri, 24 Aug 2018 23:07:36 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x230.google.com with SMTP id y12-v6so8393836ioj.13; Fri, 24 Aug 2018 16:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Q+cZBmamAqw2iXZXTEVQQt7zvDkozLQHEc3H/sgujo=; b=A+BukvShRLJs3dvh1hLPLEITXMk0KQJ4TA91LTMlyl4By3Q0rxglQ0lgKV6WJsMCY5 s5H1D+ZnBarY9regso4fkq15X7WqcX+yFSr91YyodbeEkjt3iOZWZrHKS5D/z6OieNBb xE7kdWoQoEUUlvzqimXNCRdTeUOdBPNg0excAt3wKD1Tn20yGknUIQkW1IMKHJmnlzMy L7vifjaAkDBVFERjd2kJ7DKUBIj645K+pCsoAGYA64aKPtGeyIV9KhegJmcI1RBm0Jm5 HyYyVUz45jTy3z+pVrXqc3JRb1SyOmV3wMBW7ZRQrreFwM/Z+BKB9vWVWGriBCws3QLg SZJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1Q+cZBmamAqw2iXZXTEVQQt7zvDkozLQHEc3H/sgujo=; b=Lb1rX3SbkQ8TK2FkCPICog2C8jU18gVl1zDQHfG1Z3hWEROWfGnq+ZD4/dC3e9/Bol trJPe9sU1oFurZDto+QuqdSbZolYYiQNcgAtEIk/5h4Hs6NWN5XKliAUtHJWH6Jzzokh M6SL6Fqk2geronyGrvD+y2ipOevFmFqSGuUOwuTY1fzeO8EFpOYKgisgWVOwJNxYxJxb rLddbyeoFLM+J2iMjrz2Djut3LP6kiF7cayqaqBkkw8oWYbMNdohThO44a9pvI+rs3V5 CYvXhnspuHBWIlrqnb7qPt0YE2H0xWh3665+ZdOcNxPGwtsZn+yOYHK1GRy68N8slfmL Xlpg== X-Gm-Message-State: APzg51AjFC/9pXMCRy1uMpN33wbrXCIw8u5OTWnt173VtKaOY23/WkZb 6/TddITT3pqcxrp1uCCMnITromjhB2ke98YqrL8= X-Google-Smtp-Source: ANB0VdaOKLtvJS6FVDBBeIdQpZAWgt/7gLzxm9fp89XX6QGyE6Fc1/S61QTcywTe9Cv8bS2OG7KaMWFBf2cKKtEdklU= X-Received: by 2002:a5e:890c:: with SMTP id k12-v6mr2780762ioj.136.1535152055929; Fri, 24 Aug 2018 16:07:35 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 07:07:24 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Warner Losh Cc: mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:07:37 -0000 On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > > Just in case anyone misses the change to UPDATING: > > > > > > > > 20180821: > > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > > hardware, > > > > or with GPUs predating Radeon and i915 will need to install > the > > > > graphics/drm-legacy-kmod. All other users should be able to > use > > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > > Note that this applies only to 12. > > > > > > I see that The removal of drm and drm2 has been reverted on svn. Coul= d > > > you please kindly share the reasons behind the re-inclusion? > > > > > > > > > I can=E2=80=99t really give the blow by blow of internal project drama,= but the > > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet = actually > documented > > anywhere that I=E2=80=99ve seen) were not followed with regards to the > deprecation > > process. Warner and others believe that we can address the objectives o= f > > the drm removal (improving the user experience and communicating that > > drm/drm2 are _completely_ unsupported apart from continuing to compile) > > through less disruptive means. > > > > Just so. > > Our only continued frustration is that we were never given any guidance b= y > > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion= was taking place > in > > May and then those groups behaved as if this were a surprise when the > > removal happened. I=E2=80=99m cautiously optimistic that this well expe= dite > > improving communications on those matters. > > > > All the problems that are exposed by this aren't technical. This one is > social, but no less important. > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I've been watching this debacle for quite some time now and I'd just like to ask why the rush? The graphics team is working very hard to destroy the stability of FreeBSD just so that they can force their uncooked work down users throats. The Linuxkpi is unstable at best, alpha level software that's constantly in need of someone to go and fix something on FreeBSD because Linux devs decided to make some changes or implement a new feature. This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. Are these guys insane and please avoid the nonsense about you're doing this in your spare time. If you cannot devote the resources to do something right then don't do it at all. Keep that stuff in to yourself or anyone crazy enough to follow those steps to get it up and running, you guys cannot expect to contaminate the entire FreeBSD project for this mess. This is nonsense and I hope that more people who see it as such would say so and stop having these guys forcing this crap; it's maintenance hell who will maintain it if they decide to leave? Best, Owen From owner-freebsd-stable@freebsd.org Sat Aug 25 00:40:03 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 046F71098DCF; Sat, 25 Aug 2018 00:40:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (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 5A9B77E31D; Sat, 25 Aug 2018 00:40:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.203] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id e5d9fd9d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 24 Aug 2018 17:39:59 -0700 (PDT) Subject: Re: drm / drm2 removal in 12 To: blubee blubeeme , Warner Losh Cc: mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Pete Wright Message-ID: Date: Fri, 24 Aug 2018 17:39:55 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 00:40:03 -0000 On 8/24/18 4:07 PM, blubee blubeeme wrote: > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > > - Move DRM headers to a similar location as Linux > - > > Use kmalloc() instead of malloc(9) > - Use kref > - > > Use idr and get rid of drm_gem_names.c > - Use PCI API > - Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go do > that on Linux. having a hard time not feeding the troll here...but what specifically is garbage.  as in, what implementation of all this work do you have available that has been developed independently which also enables support for modern desktop and portable systems that you can buy today? > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. speaking as someone who's been working on this from pretty much the day of the initial CFT (maybe before?) - i don't know anyone who's getting paid for this specific work.  at least when it comes to GPU support.  but, if you have the means, I'd love to work on this full time and am open to any serious offers :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Sat Aug 25 00:55:29 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A8CB1099670; Sat, 25 Aug 2018 00:55:29 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99A787F21C; Sat, 25 Aug 2018 00:55:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id p129-v6so4113112ite.3; Fri, 24 Aug 2018 17:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K2UfZBhBFmhJy7iqOlPoEy+gUzJxkZA+hsOqUmaruY4=; b=MmHqVS/PKPMc019iIF2wQVrmIa6UaGXtdvoXpOcCHAVFTBHoFQ+4jpUQtd67coh+jy W8KpPsWX5MlE52JzwtdrG9LW3+TeYJRSFqNeONsjCk1zjqIVHIdnPrbCo+z1u0ONxrEL glgzFtCLD+VsEXG5/CfCQeTHh7lK9r+80YjmFaNoICXA3NA/r9Yrq1RsmLS4u+ZSwlP0 ZB8Jx4cW4+qTdSeaWPbXr8JTVWk/YCv3LWmhJoUufEymN7QeoKOck8aiXYMqb5s2Ord9 9qodaV4LkMeNY24wtuLn40kY3LAEvInUvk415KOIhd9sDsOphkkqUR85tBZsL7AMI1Zi yU5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K2UfZBhBFmhJy7iqOlPoEy+gUzJxkZA+hsOqUmaruY4=; b=sfBfP+/CBV6aD+bBsmgmHwOmFe9fuBwgBSsn+gCp2D5noT+rVJ5hyRWH/M7a3TeABz Wto9viia5mR/hDGUxXj2h7EfrHJCB7RxGzOicnOQ3HztZ79WbA4OHpkPa5NJqYs2hC7u kYpO7iz8ouT9gyz5dLmHACiXRPCdMkgENRE4PqfhPOye0ZrWuVPGDrmsSwK9Vw3Y+qvQ J0fB0PZFQXhyggGhk5j3Eh/LUE051F4BBDGjwTJ3Yr+MmwjHXIPLl5Cap/ySn9chJ7vh yfAgH6pUEgiPAT87DxvBxXlNjmIF0oMUnMqhNT26bq38/+WFvzCpdkjGIObF6LYQgwDw H4Rg== X-Gm-Message-State: APzg51Dv+NsVu/x6hhYQ4PAk1GsZU7Fkgfh000LcUTchWNhsRqeV0cD2 aPgDN17AO3SuM5zEkEyMafJ1LvnnGXmuipaFMTY= X-Google-Smtp-Source: ANB0VdZrG/JDEu51+/gVZsF9f1Ej+XON6OL5c4U1eo3Wr/t0mUAEErGnec0ZgyFUeww5OjYj+pby+P7V5dIz6SDm+X8= X-Received: by 2002:a24:7c4a:: with SMTP id a71-v6mr60698itd.69.1535158527617; Fri, 24 Aug 2018 17:55:27 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 08:55:15 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Pete Wright Cc: Warner Losh , mmacy@freebsd.org, Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 00:55:29 -0000 On Sat, Aug 25, 2018 at 8:40 AM Pete Wright wrote: > > > On 8/24/18 4:07 PM, blubee blubeeme wrote: > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > > - Move DRM headers to a similar location as Linux > > - > > > > Use kmalloc() instead of malloc(9) > > - Use kref > > - > > > > Use idr and get rid of drm_gem_names.c > > - Use PCI API > > - Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > having a hard time not feeding the troll here...but what specifically is > garbage. as in, what implementation of all this work do you have > available that has been developed independently which also enables > support for modern desktop and portable systems that you can buy today? > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > The idea that FreeBSD relax it's standards just so that some devs have an easier time bringing up a half baked idea is nonsense. Let's take power management, after you guys do all this work to get the graphics card working how much of devd will you need to implement to get that working properly? I don't understand why this concept seems so hard to grasp but FreeBSD is not Linux why are some people continually trying to turn it into some Frankenstein thing. If you guys consider yourself developers then do what developers do and solve problems with constraints, if you cannot accomplish that stop pushing these breaking changes. None of these kmod guys seems to have put any thought into long term maintenance of this project. Look at the mailing list, every few days there's some breaking changes waiting for patches because something changed in Linux-land... If you can't solve the problem in a maintainable way, you will just create bigger problems for developers down the line. Until you guys have something that's at least as stable as what's available now, keep working on it. Some people take pride in their work and deliver a working product, they don't need to twist peoples arms into getting their way. speaking as someone who's been working on this from pretty much the day > of the initial CFT (maybe before?) - i don't know anyone who's getting > paid for this specific work. at least when it comes to GPU support. > but, if you have the means, I'd love to work on this full time and am > open to any serious offers :) > > -pete > I'd hope you have something more compelling than [http://nomadlogic.org] as your calling card. -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Sat Aug 25 02:04:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8382A109C3E1; Sat, 25 Aug 2018 02:04:28 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32AC181C88; Sat, 25 Aug 2018 02:04:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 4FE2F13B37; Sat, 25 Aug 2018 02:04:27 +0000 (UTC) Date: Sat, 25 Aug 2018 02:04:25 +0000 From: Mark Linimon To: blubee blubeeme Cc: Warner Losh , mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 Message-ID: <20180825020424.GA16497@lonesome.com> References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 02:04:28 -0000 On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. Let us know how whatever OS you wind up using instead works for you. I suggest you look for one that will put up with your constant harangues. There are very few people on the mailing lists as nasty and rude as yourself. It is tiresome, demotivating, and childish. Please go elsewhere. mcl From owner-freebsd-stable@freebsd.org Sat Aug 25 07:09:42 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C551108035F; Sat, 25 Aug 2018 07:09:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF07B8C2E4; Sat, 25 Aug 2018 07:09:41 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id p16-v6so4691141itp.1; Sat, 25 Aug 2018 00:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmAw1c00j+Mc2pGgdP5PC4j+7C2Vb473bBX23LmxzA0=; b=iLryk+y2QYQBjsYlYefYDTxkZ7REVBUDUP8kEx4L12IftriU6GxhQ6I6SedaNyBJUO cCRNHdWKBCYOfr0xjPV0jdH15qEldvesDy1x1AyxN36SyTvfcUktJJTetAV3hBVX8kND LTR/BV/c4p0kyyg8Iy9R6U4KBYXC53D6pa2+Bzsh5pMQgLV0RUcq2UJjkMeUUPsoNY28 b9M/NpofI41euk6sLAtz1m/4WTSaEUABEyNqj539wNyxYr7eFnYKgum7YLNbr7u3kKUV ytceSFvbj/TAr6x0pBp06htCfF/Ku/9jRZPBPxzdVCUbxvtQk9Kath4cT9jspaUuQnvT j9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmAw1c00j+Mc2pGgdP5PC4j+7C2Vb473bBX23LmxzA0=; b=K2+L13fjZl/BlfxCJavR/fW+I7fREsZu9lDJNkh6om2VLtDgSE8JToO6Clda51qwL2 5a9cIAbZJjihdCXm88hXUShLU6hRWJ3k+DqWxGX51VCbYYtgP//wcy0yB4kr+W4ajyLx ODdaX4syd0V4z2dESgufOcTUN9WB2H4lPa2Q6kt9OPydh8g2hWzUNMaUQKckHaQmZmlR OvadAxYf/rHJA5s2aiTxgXcbhRFTIU9u+aRHWiUxA6DeX4h4wBqbUk3Nv7Idb1cZfQBO DsLH8Mx78z3S+oYCyLzkS2ULPMVDeQIwj4xQ0l+jtGeEgO4xyEkkuBghLdLDJUyK3wqH DxZQ== X-Gm-Message-State: APzg51DxqlXDrnkL10h66ccNMpPtIOxoBcarIiHB7/uYFErqUYuTmy7F MmwPo3gEdbAhbw5yrPElrPBYSgoB/bSKvbLkX1s= X-Google-Smtp-Source: ANB0VdackqLgtoqDvm9wCk7onIWjHnPCvdm0MNLfMyG0RbzGxg3QjNj0/xH3d9XPqMiEoSokXxToW1TI/ZWzzfzc4ok= X-Received: by 2002:a02:1643:: with SMTP id a64-v6mr3774697jaa.133.1535180981050; Sat, 25 Aug 2018 00:09:41 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <20180825020424.GA16497@lonesome.com> In-Reply-To: <20180825020424.GA16497@lonesome.com> From: blubee blubeeme Date: Sat, 25 Aug 2018 15:09:29 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Mark Linimon Cc: Warner Losh , mmacy@freebsd.org, Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 07:09:42 -0000 On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon wrote: > On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > Let us know how whatever OS you wind up using instead works for you. > I suggest you look for one that will put up with your constant harangues. > > There are very few people on the mailing lists as nasty and rude as > yourself. It is tiresome, demotivating, and childish. Please go > elsewhere. > > mcl > Your opinion has been noted but this issue isn't about me. It's about the Graphics devs coding themselves into a corner and looking for an easy button so they can continue to feel good about their toy. There's a reason the changes they tried to force down the FreeBSD source tree was reverted; It does not meet any standards of quality. I have no inside knowledge other than my ability to think clearly and it's obvious that The FreeBSD team wanted to hint at them that their code doesn't pass the sniff test. Instead of being whiny brats improve your code and have it work without breaking compatibility with what has been working for quite a long time. Here's the play by play; You guys push this mess contaminating the FreeBSD source tree, some long standing user tries to update their machines and it blows up; 1) Most will just leave 2) Some will complain 2a) You guys will say; Read UPDATING..... bleh bleh blen They'll get aggravated, thereby aggravating people who came to this platform for Stability. Users who actually use FreeBSD to get things done do not time to trawl these mailing lists, they have real world problems to solve with real world constraints. There are OS with kqueue and all those things it's called Linux; You can go there and play w/ that stuff to your hearts content. If you want your code to get merged, make sure it follows the guidelines and not break the systems for people who are already using the platform. Now, I understand hearing harsh criticism about your work might hurt your feelings and all but here's the antidote; work harder, improve your code, try again when your code quality improves. You guys cannot expect people to accept these kludges in their systems that they run everyday. It's an open source project, you can't get mad because your code isn't accepted, it's your jobs and engineers to do better not expect users to jump through hoops to accommodate your subpar attempts at coding. This isn't about me, it's about the quality of code that you guys are trying to submit. Best, Owen From owner-freebsd-stable@freebsd.org Sat Aug 25 08:27:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9484108202B; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2FF8E851; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 528E2DFFA; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f44.google.com with SMTP id k188-v6so5147361itk.3; Sat, 25 Aug 2018 01:27:27 -0700 (PDT) X-Gm-Message-State: APzg51CEAUjbeJKN2JDmzFhBCf5SsoK04UVDof4BRQ+hjNZjtQ6VmcyB QZoPSnp6bj97yfHQM+vM7zchBzYnBAf3n21moT0= X-Google-Smtp-Source: ANB0VdbzHht3oDJPaowMk2cBWb3pgW3vuyvFzEaDidRZMc0qqGDVBhnjW+tyy0crtiVgtGltdpWcJ+9dTGERRpzXTPI= X-Received: by 2002:a24:704f:: with SMTP id f76-v6mr827257itc.30.1535185646401; Sat, 25 Aug 2018 01:27:26 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: Matthew Macy Date: Sat, 25 Aug 2018 01:27:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: drm / drm2 removal in 12 To: gurenchan@gmail.com Cc: Warner Losh , Ali , freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:27:28 -0000 Hi Owen - I understand that you're enthusiastic and you just want what's best for the project. However, there's a couple of points I hope you'll take to heart. First, please read what you sent and think about the tone and word choice. It's extremely negative and critical - you're actively alienating people on the list. You're not going to be successful engaging any open source community or workplace if you choose to communicate like this. Second, this is a volunteer project. One needs to establish a track record of producing patches and working with developers to get them committed. Regardless of how sound your technical position is - you're going to have a hard time being acknowledged if there is no contribution to match. Best wishes. -M On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme wrote= : > > > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >> >> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >> > >> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > > > Just in case anyone misses the change to UPDATING: >> > > > >> > > > 20180821: >> > > > drm and drm2 have been removed. Users on powerpc, 32-bit >> > > hardware, >> > > > or with GPUs predating Radeon and i915 will need to instal= l >> the >> > > > graphics/drm-legacy-kmod. All other users should be able t= o >> use >> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. >> > > > Note that this applies only to 12. >> > > >> > > I see that The removal of drm and drm2 has been reverted on svn. Cou= ld >> > > you please kindly share the reasons behind the re-inclusion? >> > > >> > >> > >> > I can=E2=80=99t really give the blow by blow of internal project drama= , but the >> > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet= actually >> documented >> > anywhere that I=E2=80=99ve seen) were not followed with regards to the >> deprecation >> > process. Warner and others believe that we can address the objectives = of >> > the drm removal (improving the user experience and communicating that >> > drm/drm2 are _completely_ unsupported apart from continuing to compile= ) >> > through less disruptive means. >> > >> >> Just so. >> >> Our only continued frustration is that we were never given any guidance = by >> > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussio= n was taking >> place in >> > May and then those groups behaved as if this were a surprise when the >> > removal happened. I=E2=80=99m cautiously optimistic that this well exp= edite >> > improving communications on those matters. >> > >> >> All the problems that are exposed by this aren't technical. This one is >> social, but no less important. >> >> Warner >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> > > I've been watching this debacle for quite some time now and I'd just like > to ask why the rush? > > The graphics team is working very hard to destroy the stability of FreeBS= D > just so that they can force their uncooked work down users throats. > > The Linuxkpi is unstable at best, alpha level software that's constantly > in need of someone to go and fix something on FreeBSD because Linux devs > decided to make some changes or implement a new feature. > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > > - Move DRM headers to a similar location as Linux > - > > Use kmalloc() instead of malloc(9) > - Use kref > - > > Use idr and get rid of drm_gem_names.c > - Use PCI API > - Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go d= o > that on Linux. > > Are these guys insane and please avoid the nonsense about you're doing > this in your spare time. > > If you cannot devote the resources to do something right then don't do it > at all. > > Keep that stuff in to yourself or anyone crazy enough to follow those > steps to get it up and running, you guys cannot expect to contaminate the > entire FreeBSD project for this mess. > > This is nonsense and I hope that more people who see it as such would say > so and stop having these guys forcing this crap; it's maintenance hell wh= o > will maintain it if they decide to leave? > > Best, > Owen > > From owner-freebsd-stable@freebsd.org Sat Aug 25 08:32:40 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24A6810823DE; Sat, 25 Aug 2018 08:32:40 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA90D8ECE8; Sat, 25 Aug 2018 08:32:39 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id p84-v6so19288025oic.4; Sat, 25 Aug 2018 01:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPDe6yrEpFGuRtOupOrkHo2OzH7ScBHn884XA0Ie814=; b=X2GfbUupOoF+yJGuf5tY/Q50nrbJ1EyX9YZL+0f1AIAWXkprkwIvNqAmECkR1Mz2Bk zR0JmoF1Y3BffHActCrP1SThImjH/B1DS/XPNBRBr8+IUJYR8GeaZn/lvqKY2P8Oeem5 +HdsK7GpVoT2KAVrR0PgZja8hMXikgGPyEFtMi7/UvJ94AaYSIRXvKj1fvbC/3JE34a0 CEHjyf2HNccBL5I+9JbpJ6RBBkw3XPGjyWeLH8xOFH2FimqZ+UU90ZoUAGpKrB1pTSiA pmKyWIhCbbb3HYSyzWQ7eNnLTfFUjREWsVgXPWAHq0akZMnoM6dGVeIviJBCRAmFVoxM Tb9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPDe6yrEpFGuRtOupOrkHo2OzH7ScBHn884XA0Ie814=; b=guWmVhaIF+h09BoJlf24hxKN3oYBdJZ8Qj3Rb54rgPnB+WcgqSWdS4jL1FE1uCSqD2 j+NTq3BL9wpnsy4SE5JQ2n7VV6WVsTHT0k+sTTOWT+7RhBlxTCBYC6zJ5gpT9yjv9iJv i8vAhoVNaoCEteQykytXMIgsZZq92NiEXnQL8yGIv4alnw+kcYjgE7F8j/b+OQXPXyWq bc8yZmM/Pms/12qrTDUNJ4ACvTBczEoRFTKiSxozdhL4pvyu4TfYsW3+i28aMwvRpsml zsVg1nst3BLjcTYFVWecvPO0EIPIW+YiLDBFW1EU1TI2MSE7OaCnYvp7dy0ajl1mgK65 qjvw== X-Gm-Message-State: APzg51BhgcPs9R5d8pnJbXvaAiJvEVgz3+fGgmPMqZ7mQLyvbvzNtSt3 /cTdVBd+IuVsR1LaHKCu6dW2sPEpdw0DqIENXJ0/sWfh X-Google-Smtp-Source: ANB0VdY3v/zx0lwM3JnCGqlm3n2Ij5OIJwxLmKmJNgj1XRmYb4Tw9gn8ylwuuPMasBDruhBZO7MYmAoPjkfacHqWWcY= X-Received: by 2002:aca:d4cd:: with SMTP id l196-v6mr4664304oig.15.1535185958512; Sat, 25 Aug 2018 01:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:144b:0:0:0:0:0 with HTTP; Sat, 25 Aug 2018 01:32:38 -0700 (PDT) In-Reply-To: References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Ali Abdallah Date: Sat, 25 Aug 2018 10:32:38 +0200 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Matthew Macy Cc: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:32:40 -0000 Isn't Intel supposed to be working on a native drm driver for FreeBSD? https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from= -2015/ On Sat, Aug 25, 2018 at 12:19 AM, Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > Just in case anyone misses the change to UPDATING: >> > >> > 20180821: >> > drm and drm2 have been removed. Users on powerpc, 32-bit >> hardware, >> > or with GPUs predating Radeon and i915 will need to install th= e >> > graphics/drm-legacy-kmod. All other users should be able to us= e >> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >> > graphics/drm-next-kmod, graphics/drm-devel-kmod. >> > Note that this applies only to 12. >> >> I see that The removal of drm and drm2 has been reverted on svn. Could >> you please kindly share the reasons behind the re-inclusion? >> > > > I can=E2=80=99t really give the blow by blow of internal project drama, b= ut the > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet ac= tually documented > anywhere that I=E2=80=99ve seen) were not followed with regards to the de= precation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. I am only acting as a lightning rod and > representative of the graphics team and so have done an inadequate job of > tracking their activities with respect to project timelines. As a result = of > this misunderstanding Johannes Lundberg will be sponsored for a bit and > will be able to be involved in internal discussions that impact his work. > > Our only continued frustration is that we were never given any guidance b= y > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion w= as taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I=E2=80=99m cautiously optimistic that this well expedi= te > improving communications on those matters. > > > Cheers. > -M > From owner-freebsd-stable@freebsd.org Sat Aug 25 08:44:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC9951082B40; Sat, 25 Aug 2018 08:44:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 779A88F5BA; Sat, 25 Aug 2018 08:44:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id j81-v6so5181259ite.0; Sat, 25 Aug 2018 01:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gqfb2oSsiSUIEN0b+lYkkEHmpR6w1Po/a32C0ej1fMk=; b=GfuXK/syqbG+/kUc0Wc9OBF9rjpOx1Wf6spyZSkQWeHbfQ6qrRsWb4RX/aBxpaoKkb w+Z7wQJVF848QommWPcBoLaZ572w1Yydq6lsIAuBkMbikVseWudA9l+4eIlIdvpGAqg1 R0yo5vFtexs2/giRwFVGYCBiMmbrZMoodtthtLm3m94BjPL2j8Cbz/rtjwo7lukIRTUO stwdEVIvFgVlRkD4tpqVgZY+5fT+FyVTD+dJz8VPP5NY5v+tQ+Ka+M6f7RWQyJc58ICP 4u/TPehG9SDzPnA7P6qw7ALyga4DotXP7iYFO9Pvfmo5fuQTTa51Ubq2ynBGHvGdfzXu 961A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gqfb2oSsiSUIEN0b+lYkkEHmpR6w1Po/a32C0ej1fMk=; b=saKadzpo1+ns+K9H+DUKssasFJQMTjPmDARZlx9/TxibFilFfM4X+yLiVZRc4ytiX/ sIPJDN816UCMcxRUkrdDrnt2zncvi+wAIZfX7zfQdMz9OjfVvPo1L6K1Ezi7B6mCyGnp 8oVT/2C3GpdnmfBAU8a2/DeDVLass5vySL9tyiOc3Nu6WGwsD/kjGLv2apx3Ao0KgDQY tg0i9BqDltpoSWMURPU/Mjwe/HlBfwnuC6RNB1wh3Tm5C3aP0a8dnT2Uf/vOcLOsLUor dV1a1SGAdsO1Qe0XGRzG1oqzOhT8lijWEkOYpNH+kY8M39OU5vXlZc0uYmeagyNwyKU7 Peew== X-Gm-Message-State: APzg51A6zd+0FkAfU6+h/3iGBjduSoG44/d2rUJYtb4rceWBCTavQRd3 Utk0dbi/awXy1AlVsysy89rqk+LEOTgx/k6FCkUL4PMBZvk= X-Google-Smtp-Source: ANB0Vdb/c27/HAzg3fWD16x8Jgal1VhMutkqcZDPTI55ujkYGv94rQ+RUw5q1pRq8U07tOgwgTRfq0Awj9GLYYhkhu0= X-Received: by 2002:a24:d0d6:: with SMTP id m205-v6mr863089itg.89.1535186654061; Sat, 25 Aug 2018 01:44:14 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 16:44:02 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: mmacy@freebsd.org Cc: Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:44:16 -0000 On Sat, Aug 25, 2018 at 4:27 PM Matthew Macy wrote: > Hi Owen - > I understand that you're enthusiastic and you just want what's best for > the project. However, there's a couple of points I hope you'll take to > heart. First, please read what you sent and think about the tone and word > choice. It's extremely negative and critical - you're actively alienating > people on the list. You're not going to be successful engaging any open > source community or workplace if you choose to communicate like this. > Second, this is a volunteer project. One needs to establish a track recor= d > of producing patches and working with developers to get them committed. > Regardless of how sound your technical position is - you're going to have= a > hard time being acknowledged if there is no contribution to match. > > Best wishes. > -M > True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. How far will core FreeBSD bend over backwards to accommodate these devs. Their project is half baked at best and sure it works; sorta if the moon is just right. This is the beauty of an open source project, we bring the best to the table, not rip off two legs only to glue them back on later just slightly askew. This isn't a world where everyone gets a gold star, people fail even if they work very hard, failure is still an option. I guess the most important question to ask is what's the standards that the FreeBSD Foundation want to represent, uphold, and maintain? > > > On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme > wrote: > >> >> >> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: >> >>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >>> >>> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >>> > >>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >>> > > > Just in case anyone misses the change to UPDATING: >>> > > > >>> > > > 20180821: >>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit >>> > > hardware, >>> > > > or with GPUs predating Radeon and i915 will need to >>> install the >>> > > > graphics/drm-legacy-kmod. All other users should be able >>> to use >>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod= , >>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. >>> > > > Note that this applies only to 12. >>> > > >>> > > I see that The removal of drm and drm2 has been reverted on svn. >>> Could >>> > > you please kindly share the reasons behind the re-inclusion? >>> > > >>> > >>> > >>> > I can=E2=80=99t really give the blow by blow of internal project dram= a, but the >>> > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not ye= t actually >>> documented >>> > anywhere that I=E2=80=99ve seen) were not followed with regards to th= e >>> deprecation >>> > process. Warner and others believe that we can address the objectives >>> of >>> > the drm removal (improving the user experience and communicating that >>> > drm/drm2 are _completely_ unsupported apart from continuing to compil= e) >>> > through less disruptive means. >>> > >>> >>> Just so. >>> >>> Our only continued frustration is that we were never given any guidance >>> by >>> > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussi= on was taking >>> place in >>> > May and then those groups behaved as if this were a surprise when the >>> > removal happened. I=E2=80=99m cautiously optimistic that this well ex= pedite >>> > improving communications on those matters. >>> > >>> >>> All the problems that are exposed by this aren't technical. This one is >>> social, but no less important. >>> >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> I've been watching this debacle for quite some time now and I'd just lik= e >> to ask why the rush? >> >> The graphics team is working very hard to destroy the stability of >> FreeBSD just so that they can force their uncooked work down users throa= ts. >> >> The Linuxkpi is unstable at best, alpha level software that's constantly >> in need of someone to go and fix something on FreeBSD because Linux devs >> decided to make some changes or implement a new feature. >> >> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM >> Goals >> >> - Move DRM headers to a similar location as Linux >> - >> >> Use kmalloc() instead of malloc(9) >> - Use kref >> - >> >> Use idr and get rid of drm_gem_names.c >> - Use PCI API >> - Use Linux locking primitives >> >> is garbage, if you want to use develop Linux code and use Linux then go >> do that on Linux. >> >> Are these guys insane and please avoid the nonsense about you're doing >> this in your spare time. >> >> If you cannot devote the resources to do something right then don't do i= t >> at all. >> >> Keep that stuff in to yourself or anyone crazy enough to follow those >> steps to get it up and running, you guys cannot expect to contaminate th= e >> entire FreeBSD project for this mess. >> >> This is nonsense and I hope that more people who see it as such would sa= y >> so and stop having these guys forcing this crap; it's maintenance hell w= ho >> will maintain it if they decide to leave? >> >> Best, >> Owen >> >> > From owner-freebsd-stable@freebsd.org Sat Aug 25 13:04:36 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94EB2108A332 for ; Sat, 25 Aug 2018 13:04:36 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 D032497437; Sat, 25 Aug 2018 13:04:35 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w7PD4WKG031348; Sat, 25 Aug 2018 15:04:32 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 9E97C267; Sat, 25 Aug 2018 15:04:32 +0200 (CEST) Subject: Re: ctld(8) 11.2-release lockup with w2k16 [Was: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions)] From: Harry Schmalzbauer To: FreeBSD Stable References: <5444C94C.4050705@omnilan.de> <20141021104308.GA5990@brick.home> <3613504a-b017-bc3a-cd62-54d8bb051ea1@omnilan.de> Organization: OmniLAN Cc: =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= Message-ID: <151ecc4c-5c6b-82ab-d24b-209d685002ad@omnilan.de> Date: Sat, 25 Aug 2018 15:04:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3613504a-b017-bc3a-cd62-54d8bb051ea1@omnilan.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: ACL 130 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sat, 25 Aug 2018 15:04:32 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 13:04:36 -0000 Am 05.07.2018 um 18:17 schrieb Harry Schmalzbauer: > Am 21.10.2014 um 12:43 schrieb Edward Tomasz Napierała: >> On 1020T1035, Harald Schmalzbauer wrote: >>>   Hello, >>> >>> I'm trying to move from istgt(1) to ctld(8), but it seems my setup >>> isn't >>> possible with ctld. >>> Besides missing support for virtual-DVDs ('UnitType DVD' in istgt) and >>> real ODD-devices ('UnitType pass' in istgt), >> Yup, we don't implement virtual DVDs and passthrough. Especially the >> latter would be a nice feature to have. > > > Hello Edward, > > my current problem is unrelated. > But this old mail illustrates the timeframe I've been happily using > ctld(8) without problems :-) Thanks! > > Recently, I discovered that WindowsServerBackup fails with Win2k16 > (never used 2k12). > Old initiators running 2008R2 (or ESXi 5.5) are still able to use > ctld(8) ZVOL targets for WindowsServerBackup on 11.2-release without > problems. Unfortunately also ESXi6.5 initiatiors are not working well with ctld(8) anymore. Read performace is incredibly slow. I have a 2x3z1 pool with 6SAS10krpm spindels. Local ZFS performance doesn't show anything unexpected. But reading from a ctld(8) ZVOL backed target under ESXi6.5 seems to cause a interrupt deadlock – not completely dead, but almost. gstat(8) tells me that all 6 HDDs are idle. top(1) shows no thread consuming CPU cycles, with one exception (besides idle): 12 root         38 -56    -     0K   608K WAIT   -1 569:02 482.78% intr systat(1) shows NICs almost idle (<100irqs/s) and permanent 25% INTR load (one of 4 cores). This is with 11.2 release. It's a ESXi guest, which I used severla years with previous FreeBSD versions without such massive iSCSI performance problems. Using the same /dev/zvol with istgt(1) on the same 11.2-release VM also solves the performance issue. Is anybody using ctld(8) in production post 10.x? If so, without observing a similar regression? Thanks, -harry From owner-freebsd-stable@freebsd.org Sat Aug 25 18:08:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7586E1091C47; Sat, 25 Aug 2018 18:08:33 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 10BAE7B89C; Sat, 25 Aug 2018 18:08:33 +0000 (UTC) (envelope-from des@des.no) Received: from next.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 6F9C58505; Sat, 25 Aug 2018 18:08:32 +0000 (UTC) Received: by next.des.no (Postfix, from userid 1001) id 4D8EB8CAB; Sat, 25 Aug 2018 20:08:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: blubee blubeeme Cc: mmacy@freebsd.org, Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 In-Reply-To: (blubee blubeeme's message of "Sat, 25 Aug 2018 16:44:02 +0800") References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) Date: Sat, 25 Aug 2018 20:08:32 +0200 Message-ID: <86k1oepbdr.fsf@next.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:08:33 -0000 blubee blubeeme writes: > True on both points my tone is just a reflection of attitudes of the > individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. > Some people enjoy making contributions w/o waving a banner constantly > wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. > How far will core FreeBSD bend over backwards to accommodate these > devs. The core team does not decide what goes into the tree or not. The developers do. > This is the beauty of an open source project, we bring the best to the > table, [...] Who exactly is =E2=80=9Cwe=E2=80=9D here? You are not a member of the proj= ect, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@freebsd.org Sat Aug 25 23:23:28 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DBCC1098CA0; Sat, 25 Aug 2018 23:23:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE45858BB; Sat, 25 Aug 2018 23:23:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id l7-v6so9971399iok.6; Sat, 25 Aug 2018 16:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2A2ABcxHpi2b+hEh0wAblF4Aioy0yaAasnFOQ193TZw=; b=cU69nsVSUIAqmyEwkH6HqdmVZ2oesMbIwyD5AKwEsbYPC+MMLWGfMJLhFR3EJGFcpV Ka6US8a3s0TySGPNJgSvk6aa/Nz6fhJ2ICxyii7tF+RWlEF3LDDA9HNT8xqBeCjiIxGR 2kYZyMvR+Z3U4L25dfwDl1edVZLSIlUBv1vfRNWlk2GMmp2zTKr/l38X/wg7ioUxp+my eE7yu49tHrGbqFrE9QFZL06+sOClt0BVWwEQtxwSrXfhz9Zxt2IAuxi4b2jHQFjeIwvF zdH+sQxBCROcymZ8U3FeqfCF6HHD6atWjNqZNiDpNpMRR2fQDURmBn7NtMqEOZRc4ei+ zBBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2A2ABcxHpi2b+hEh0wAblF4Aioy0yaAasnFOQ193TZw=; b=j7E9A8lr8YmhB3p74iRLBa6wborMBq+XBmPgbGgWXaPgjz1G88YzpSWre4WIZmQ8zH Dj2GQ6MJSgH7qsIZpSspbwJoA8SGowJ9p+fFFW10NCncAZqM5ZeBnHAoGDiofABQ5vFI 2lxqWKl2wVTfXcZiFKH7lKg3B+9+LsUh8gmfP2I5ngLIrCWNg6amyF0xDkMmQe7GmpRy u3aiFcjXpM3ObuytPmqLBU+BL9vs6kka1VSra4ze2ALtOdBNRW1E8NPjDJj7jXWZlOQv /hTto+Jg+lPbTfZX5NTCRSpAM4ziNGRwosYQ6xm2aHWZezheTd88UW0s/PLvp4sSTqlO 6Wkg== X-Gm-Message-State: APzg51AeJm6JhKps0aqO8a9lZdaC2bNfCWjM+6RvnwMolqKd9WmwfgkX Lc5S+Tk4AS/vdQNFu2mIrpRmbnsSKwyXprERT1c= X-Google-Smtp-Source: ANB0Vdas6fR9RJaBSIIGVIS/AIN27bAxrep8CcokyQ4B3V5iW4nlu4kqssA40oUPEVQieg+I/tfpxCY8BdeDZdi3KVQ= X-Received: by 2002:a5e:890c:: with SMTP id k12-v6mr5528851ioj.136.1535239407318; Sat, 25 Aug 2018 16:23:27 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <86k1oepbdr.fsf@next.des.no> In-Reply-To: <86k1oepbdr.fsf@next.des.no> From: blubee blubeeme Date: Sun, 26 Aug 2018 07:23:15 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: des@des.no Cc: mmacy@freebsd.org, Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 23:23:28 -0000 On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Sm=C3=B8rgrav wrote= : > blubee blubeeme writes: > > True on both points my tone is just a reflection of attitudes of the > > individuals that I am currently addressing. > > Well, congratulations on alienating absolutely everybody you have > interacted with on this topic. > > > Some people enjoy making contributions w/o waving a banner constantly > > wanting acknowledgement, a pat on the head and good job from everyone. > > The only person I see constantly craving attention and validation from > others here is you. > > > How far will core FreeBSD bend over backwards to accommodate these > > devs. > > The core team does not decide what goes into the tree or not. The > developers do. > > > This is the beauty of an open source project, we bring the best to the > > table, [...] > > Who exactly is =E2=80=9Cwe=E2=80=9D here? You are not a member of the pr= oject, you do > not speak for the project, and after seeing how you treat our fellow > developers, our friends, most of us want nothing to do with you. If > can't live with that, I'm sure you can figure out how to install Linux. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? ---- A little background ---- Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. ----------------------------------- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work?