From owner-freebsd-current@freebsd.org Sun Apr 8 09:36:12 2018 Return-Path: Delivered-To: freebsd-current@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 BF167F93302 for ; Sun, 8 Apr 2018 09:36:12 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5024D8EF7E for ; Sun, 8 Apr 2018 09:36:12 +0000 (UTC) (envelope-from editor@callfortesting.org) Received: by mail-pf0-x22a.google.com with SMTP id c78so3865073pfj.6 for ; Sun, 08 Apr 2018 02:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callfortesting-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=9h3LmD+/czuVcZNc/8KazzVeXYxySJ3mEVIJ2toVVx8=; b=wT7JcXjrXjRnA7zNaNm4z6NQzu/UVWwiupOVk8Yl1tGhjpYWeqbaPr5k9r0NeXktlE T5RaNxBSklsRhFdZARmxOLmwrs+GGpC8n7FqkHYuPB2b/GsHqBGWRoFXSCNLEmLhN8pb 4liO1zWnS5aMtsKSO2FAEb5WwjBsIP7gD+re1KdGPI/zfOUV4cmq8Z6vfAhtZEy/OIW9 4a3+lVtQagnWQzsVFUjTwFTMbF1hZcfm9i7AivnM+jmKaVYithqWs7ar6F590KNhXaZD EWLR7pIqF/r7zzgvw2CTwSEnugGMudkJ04TBSlYKM/0geQuFgJjBGPySI8kFLgNSe0jY +q/A== 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:content-language :content-transfer-encoding; bh=9h3LmD+/czuVcZNc/8KazzVeXYxySJ3mEVIJ2toVVx8=; b=SkPBSOL3T+olFWYGxBcjFh5gBS+5rrbYTuPy/MfxPPcOKHNInHqSNHxD9T/fwQU9vq GO8U3sF5103x2lUAhYaCsaC2ULJPWencLoC7xzVru3w61dmFc+JIhcZBpG6EH+N96lLb mA8JWBb5+zjqOY0j8mQVs4DkL40IdxQbgMVcBsulZ+9+1ypEBLUXpf88z9i88gMpfP8k 7jKVOEI0667tZa9tjMatgk3/5cew1bDdX1k0h4zCKahNzAIlp6jw/img0aDMLkb8JzWF FX8zz3wFsgmNPv3lMrUmau845w1gm8NQNlDifkcA+W3bMZswU+5Y/LHlOkiisCYy8Db/ gnuQ== X-Gm-Message-State: ALQs6tDYcDdqCbb8yi8INFLhtDlwivaiMfrl+ohHChHyOI/BLyt8rkYL jFedXagd7MeJBkak/M9qXt4yOnB0 X-Google-Smtp-Source: AIpwx49bWDMdfrKJ1IXTZRgdxRtZ856sazsPWc4usaaHORc871PFM7+pJ8eBprX3U9eAhrUMuiBbgw== X-Received: by 10.99.125.74 with SMTP id m10mr11174954pgn.80.1523180171409; Sun, 08 Apr 2018 02:36:11 -0700 (PDT) Received: from macbook-2.local (c-67-170-143-17.hsd1.or.comcast.net. [67.170.143.17]) by smtp.gmail.com with ESMTPSA id v7sm21554155pfm.147.2018.04.08.02.36.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 02:36:10 -0700 (PDT) Subject: Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT To: freebsd-current@freebsd.org, "O. Hartmann" References: <20180324103615.7b88c33f@thor.intern.walstatt.dynvpn.de> From: Michael Dexter Message-ID: Date: Sun, 8 Apr 2018 02:36:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180324103615.7b88c33f@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 09:36:12 -0000 On 3/24/18 2:35 AM, O. Hartmann wrote: > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, created via > the classical manual way, no makefs), my recent CURRENT system dumps the > console full of these error messages: > > g_handleattr: md0 bio_length 24 len 31 -> EFAULT > > I do not know what they are supposed to mean and I'd like to ask whether someone could > shed some light on this. I am seeing this on the the latest snapshot when attempting to run option_survey.sh which creates an md-attached disk image. Anyone else seeing this? Michael From owner-freebsd-current@freebsd.org Sun Apr 8 10:53:32 2018 Return-Path: Delivered-To: freebsd-current@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 E5517F98B1E for ; Sun, 8 Apr 2018 10:53:31 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) (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 94CA67106F for ; Sun, 8 Apr 2018 10:53:31 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x2.osted.lan (87-58-223-204-dynamic.dk.customer.tdc.net [87.58.223.204]) by relay01.pair.com (Postfix) with ESMTP id DE1DED00458; Sun, 8 Apr 2018 06:53:24 -0400 (EDT) Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id w38ArLt7055502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Apr 2018 12:53:22 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id w38ArLIs055501; Sun, 8 Apr 2018 12:53:21 +0200 (CEST) (envelope-from pho) Date: Sun, 8 Apr 2018 12:53:21 +0200 From: Peter Holm To: Michael Dexter Cc: freebsd-current@freebsd.org, "O. Hartmann" Subject: Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT Message-ID: <20180408105321.GA55435@x2.osted.lan> References: <20180324103615.7b88c33f@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 10:53:32 -0000 On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote: > On 3/24/18 2:35 AM, O. Hartmann wrote: > > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, created via > > the classical manual way, no makefs), my recent CURRENT system dumps the > > console full of these error messages: > > > > g_handleattr: md0 bio_length 24 len 31 -> EFAULT > > > > I do not know what they are supposed to mean and I'd like to ask whether someone could > > shed some light on this. > > I am seeing this on the the latest snapshot when attempting to run > option_survey.sh which creates an md-attached disk image. > > Anyone else seeing this? > > Michael Yes, I have: [pho@freefall ~/public_html/stress/log]$ grep -a g_handleattr: `ls -rt` numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT [pho@freefall ~/public_html/stress/log]$ -- Peter From owner-freebsd-current@freebsd.org Sun Apr 8 14:37:16 2018 Return-Path: Delivered-To: freebsd-current@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 8E80AF862EA for ; Sun, 8 Apr 2018 14:37:16 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED7016C460; Sun, 8 Apr 2018 14:37:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-wr0-x22a.google.com with SMTP id s18so5901487wrg.9; Sun, 08 Apr 2018 07:37:15 -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=UNf+WHAuEHJhxfwk11tbxyDSmyNmt4lQTGRSVStW3XA=; b=a8+BL4tyIg35a7ftKyOtgZ5P3nbzRN2XmvVPKjvG1niZZhfbl/FlcAqdlyV28cSAPh hNv8eKKKnuwxJGeXTUgHqBbDLM6Vo3d7p2em8Qz+feA2F7y1toHfrTQsRowDybG94hcB Nr11JRSV8v+O8ksrC21U8MfbG4XJwm99YxKTn8uYTeQAWivQeEKzcWepcwwT48vemmh7 jIyvqXMdLFb/B6WKrg04J281NBbiDU6YPMX/MoucKFkbJwIyfmdmMg3v8XA08R8gstgd 0l0JPxhlCxOIF11McwxdM91TERFBvAl7qL0rqKYlbNLRvPx/maLCi0iEgYpKdoBSQmSg HQ6A== 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=UNf+WHAuEHJhxfwk11tbxyDSmyNmt4lQTGRSVStW3XA=; b=JspLyS65+zqxueOSw3OM8bULZxkiRrHcX/qoy5kiWfD8jAQzD4lbAmos/D0dh/hZCf Ss8v7TIHQaxpqR9m1r6R3dleypbPAcp2Wqajr6Dyhg4/S/i9udVqKGo3rlO/UhG/heBe l43iNwTc9Y0/D9I0VsgAXflPgTDvNi47KOGhOM/n4diuXw57EB0GDFB4ZrsJHhqxcytR 72EkAkC/jwoqTLWM5LguY91RZrDsdCuuRTxcQfNQHaj0Fwwa8Kwgptqk7vse0X2DPm88 Wc7iP2t5HuYpZoYVCrMXqXs7PPXsYS/AQBT9fhmtLbWCyZQU4Rgmat3pZz/T2OF7X5I3 e9hg== X-Gm-Message-State: ALQs6tB1RLhNyGpBCUgDEbtMosOCKLpUM9VpBSi32pYd9h1Y6t4VzTDV RjtJmh4a3k1cidfTwPKKRCdEub5t+7yQNxpp2kRuRw== X-Google-Smtp-Source: AIpwx4/nsXliMwDQ0zk/dkfM2V/zGcP3JiUCpLTkZgJAtpiY118beNreNEsQA3/vkTV8o57IQeFmegZn/i1bUlrEUOY= X-Received: by 2002:a19:b2d1:: with SMTP id t78-v6mr20785870lfk.78.1523198234240; Sun, 08 Apr 2018 07:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.150.194 with HTTP; Sun, 8 Apr 2018 07:37:12 -0700 (PDT) In-Reply-To: <20180407194935.GA491@raichu> References: <1fd2b47b-b559-69f8-7e39-665f0f599c8f@FreeBSD.org> <20180404174949.GA12271@raichu> <20180406150814.GB10017@raichu> <20180407194935.GA491@raichu> From: Justin Hibbits Date: Sun, 8 Apr 2018 09:37:12 -0500 Message-ID: Subject: Re: Strange ARC/Swap/CPU on yesterday's -CURRENT To: Mark Johnston Cc: Jeff Roberson , FreeBSD current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:37:16 -0000 Hi Mark, On Sat, Apr 7, 2018 at 2:49 PM, Mark Johnston wrote: > On Sat, Apr 07, 2018 at 02:34:54PM -0500, Justin Hibbits wrote: >> >> I reverted back to r329881, and successfully built world. Updated to >> r329882 and it got stuck with processes in btalloc. >> >> I've seen other reports of r329882 causing problems on powerpc64 as >> well, with other bizarre behaviors. > > Did you try the patch that I had posted? If not, could you? Please also > update zfs_arc_free_target or just apply D14994. I just applied both patches, and head still locks up, but no threads are stuck in btalloc. The thread running when I break into ddb is still vmdaemon. Running 'show all vmem' on ddb shows it pretty low on kernel arena: vmem 0xe000000001202900 'buffer arena' quantum: 4096 size: 775913472 inuse: 152928256 free: 622985216 busy tags: 4668 free tags: 4 inuse size free size 16384 2 32768 0 0 32768 4666 152895488 1 32768 536870912 0 0 1 622952448 vmem 0xe000000005017000 'kernel arena dom' quantum: 4096 size: 775946240 inuse: 772923392 free: 3022848 busy tags: 144749 free tags: 3 inuse size free size 4096 141305 578785280 0 0 8192 243 1990656 0 0 16384 2081 34095104 0 0 20480 290 5939200 0 0 32768 113 3702784 0 0 36864 61 2248704 0 0 65536 80 5242880 0 0 69632 2 139264 1 69632 77824 1 77824 0 0 81920 1 81920 0 0 86016 1 86016 0 0 90112 2 180224 0 0 94208 2 188416 0 0 98304 1 98304 0 0 102400 1 102400 0 0 110592 1 110592 0 0 118784 1 118784 0 0 122880 1 122880 0 0 131072 545 71434240 0 0 262144 2 524288 9 2428928 524288 4 2154496 1 524288 1048576 6 6995968 0 0 2097152 1 2097152 0 0 4194304 1 4194304 0 0 8388608 1 8388608 0 0 16777216 2 43823104 0 0 vmem 0xe000000001202180 'kernel arena' quantum: 4096 size: 2353004544 inuse: 2351603712 free: 1400832 busy tags: 600 free tags: 4 inuse size free size 4096 3 12288 1 4096 24576 0 0 2 49152 28672 0 0 1 28672 36864 415 15298560 1 36864 65536 1 65536 0 0 131072 1 131072 0 0 1048576 0 0 1 1282048 4194304 172 721420288 0 0 8388608 1 8388608 0 0 16777216 2 46137344 0 0 134217728 3 453386240 0 0 268435456 1 297295872 0 0 536870912 1 809467904 0 0 Any other numbers I can gather to debug this? - Justin From owner-freebsd-current@freebsd.org Sun Apr 8 14:48:47 2018 Return-Path: Delivered-To: freebsd-current@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 91007F8723D for ; Sun, 8 Apr 2018 14:48:47 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FDEC72B13 for ; Sun, 8 Apr 2018 14:48:46 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-wm0-f50.google.com with SMTP id r191so12601727wmg.4 for ; Sun, 08 Apr 2018 07:48:46 -0700 (PDT) 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=Gc32mPp+6rrETa8QRkdGXWhjmUO06ARMWbOAMul24sA=; b=O20sroohr86s3ew8q26EDe0QPWllezzoI7tDRHhrn53AHfFq05ihg9WijynN/ByWbe rozY8iVa14RLW8fWMhjUCMX+WjL1KQnlL12LR9z4Fz/vt0htkgbJMmKzM3nM2WVF8f2V K9CD6QHyyItAuppYJ5Ne8c3TXuZdElHsbSbUvbw0e4LQW70Y2JwzleHF2ipQaMTYqJef ZJM6JtxXIg0v4y/FMx/yHjWl/Pozm2IJT50Q3cNjQ2K/Lcn0LIpdjMNKBjpTAcpW0gTQ cO9mW90TVeuMLRYO62vGkNLgEwMwn8kdZRFqQQeSgnrdH2v9f3KnGmLhpuMrtuXcPeqE L0Wg== X-Gm-Message-State: ALQs6tACQ8Z2I0uD679pQ3Gqv/vBPUhDmc2fdkzAkhuyxtLhRp8nDCCG 7FLUiSaZP08h4AtvzZiq8pgxhxbF X-Google-Smtp-Source: AIpwx4920nI/ivtPhFICgayTq9s+laKPOXh7vMOr6qB3sRtQEpX3sNEp/a/FJ7Z9jUgOEmYPVomlNA== X-Received: by 10.80.179.45 with SMTP id q42mr17464420edd.264.1523198919587; Sun, 08 Apr 2018 07:48:39 -0700 (PDT) Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com. [209.85.128.180]) by smtp.gmail.com with ESMTPSA id w4sm8667850edh.56.2018.04.08.07.48.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Apr 2018 07:48:39 -0700 (PDT) Received: by mail-wr0-f180.google.com with SMTP id u11so5919650wri.12 for ; Sun, 08 Apr 2018 07:48:39 -0700 (PDT) X-Received: by 2002:a19:7904:: with SMTP id u4-v6mr20909611lfc.129.1523198919153; Sun, 08 Apr 2018 07:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Sun, 8 Apr 2018 07:48:18 -0700 (PDT) In-Reply-To: <20180408105321.GA55435@x2.osted.lan> References: <20180324103615.7b88c33f@thor.intern.walstatt.dynvpn.de> <20180408105321.GA55435@x2.osted.lan> From: Kyle Evans Date: Sun, 8 Apr 2018 09:48:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT To: Peter Holm Cc: Michael Dexter , FreeBSD Current , "O. Hartmann" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 14:48:47 -0000 On Sun, Apr 8, 2018 at 5:53 AM, Peter Holm wrote: > On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote: >> On 3/24/18 2:35 AM, O. Hartmann wrote: >> > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, created via >> > the classical manual way, no makefs), my recent CURRENT system dumps the >> > console full of these error messages: >> > >> > g_handleattr: md0 bio_length 24 len 31 -> EFAULT >> > >> > I do not know what they are supposed to mean and I'd like to ask whether someone could >> > shed some light on this. >> >> I am seeing this on the the latest snapshot when attempting to run >> option_survey.sh which creates an md-attached disk image. >> >> Anyone else seeing this? >> >> Michael > > Yes, I have: > > [pho@freefall ~/public_html/stress/log]$ grep -a g_handleattr: `ls -rt` > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT > [pho@freefall ~/public_html/stress/log]$ > FYI- this should be fixed by r332070. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Sun Apr 8 16:39:45 2018 Return-Path: Delivered-To: freebsd-current@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 A54A0F8EF27 for ; Sun, 8 Apr 2018 16:39:45 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic303-22.consmr.mail.gq1.yahoo.com (sonic303-22.consmr.mail.gq1.yahoo.com [98.137.64.203]) (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 3000770CD2 for ; Sun, 8 Apr 2018 16:39:45 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: u_Ux55QVM1k4XIc7bIAbet2wS8WhBYeQq1NlNCkjUfQ9dWprhhpwLbH4cuFJozg 7kV9AMEjQC7LniK8U2KIPs5gaI1Dafmdl.SbI8bbjj5n8ZR82tFqvcIHG1lt2dONdwNjpFUkHFgP SF7QgiUpk2JjT4Jh8C1SU1MMz.wrenDoIMTh5ke8PBrFfrzHxx8rQ.R1EQU1btpqeKMc05vRbGax O3tRirwCdJlOgsU8ng.4WooHwNNqVjZZascZug1Tx_Ra0jlaAZk5Z95SRjWtb36SVxV4doz7PBVv zCMnDFUNfmOi34O2KOJQGvqeObKw0tGaloxviCDil9uWFBuStt92zxGUboGzvTC1EzCX1aAJCRv4 Z1hkY76p9Cln5iNNoW0RY4NZtT_n_ZopGTggcNgkGEzCuLtgBmV8pAFyjM5Qipp.o5shTAnrlIbA LPM.y8uv9hekIvw1dnUMqG0keoU.fuy0fn7XK2GOkNoi8w2bPGkldqak0dDILKaqF45CUEAhNQla sUO8BLwY7gqIW7a6tAVSdvGeQrfAKmXml5N36 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 8 Apr 2018 16:39:38 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d9f02034e3b178c021c97b2e13312602; Sun, 08 Apr 2018 16:29:26 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Ryzen Threadripper, Hyper-V, and NUMA vs. DIMMs: 3 DIMMs on each side seems to always be in "Local" mode, not "Distributed" Message-Id: Date: Sun, 8 Apr 2018 09:29:25 -0700 To: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 16:39:45 -0000 Context: Ryzen Threadripper 1950X under Windows 10 Pro with Hyper-V (used to run FreeBSD). In experimenting with switching a Threadripper 1950X to have ECC RAM I discovered: A) The maximum ECC memory it would put to use was 96 GiBytes (3 DIMMs on each side, a 4th on each side was recognized but was ignored/disabled if present). B) AMD Ryzen Master classified the 96 GiByte configurations (with or without the ignored DIMMs) as "Local" without an ability switch to "Distributed". C) The downloaded Windows CoreInfo.exe utility agreed on there being 2 NUMA nodes. D) As did the result of the User Hardware Topology button in the Hyper-V Processor > NUMA settings: On a single virtual non-uniform memory architecture node: Maximum number of processors : 16 Maximum amount of memory (MB) : 48070 Maximum NUMA nodes allowed on a socket: 2 Only 1 socket. E) The CoreInfo.exe quick "Approximate Cross-NUMA Node Access Cost (relative to fastest)" tends to show the 4 numbers varying from 1.0 to 1.7 when retried repeatedly. An oddity is that sometimes the 1.0's are between 00 and 01, in fact this seems usual, and normally at most one 1.0 exists. The 00 row seems to always have the smaller numbers. An example: 00 01 00: 1.2 1.0 01: 1.3 1.5 I had no original intent of playing with NUMA but I figured that the Threadripper could be configured for such, and even has configurations that apparently require such as far as AMD Ryzen Master is concerned, could be of interest and possible use for folks testing FreeBSD NUMA support. Since I'd done nothing to build a kernel with NUMA enabled, FreeBSD 12.0 under Hyper-V did not see the NUMA structure from (D). One thing that did show during booting was getting 4 lines of: "SRAT: Ignoring memory at addr" instead of 2. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Sun Apr 8 19:00:55 2018 Return-Path: Delivered-To: freebsd-current@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 017DEF99FC5 for ; Sun, 8 Apr 2018 19:00:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 825CF7FD7B for ; Sun, 8 Apr 2018 19:00:54 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w38J0qxK014768 for ; Sun, 8 Apr 2018 12:00:52 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w38J0q23014767 for freebsd-current@freebsd.org; Sun, 8 Apr 2018 12:00:52 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804081900.w38J0q23014767@pdx.rh.CN85.dnsmgr.net> Subject: Module compiles looking in /usr/src when alternate src tree is in use To: freebsd-current@freebsd.org Date: Sun, 8 Apr 2018 12:00:52 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 19:00:55 -0000 I am having a compile time issue for a patched that compiled fine on my r329294 system, but now failes to compile with what looks like a wrong header being included. I have wrapped the long line so I can point to a difference between r329294 and r332262 make log of this file. r329294 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ ^^^^^^^^^^^^^^^^^ this is what I would expect -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD \ -MF .depend.vmm.o -MTvmm.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse \ -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv \ -fstack-protector -Wall -Wredundant-decls -Wnested-externs \ -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ \ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas \ -Wno-error-tautological-compare -Wno-error-empty-body \ -Wno-error-parentheses-equality -Wno-error-unused-function \ -Wno-error-pointer-sign -Wno-error-shift-negative-value \ -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src-topo/sys/amd64/vmm/vmm.c -o vmm.o No error, and I get my vmm.ko! r332262 make output: cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src/sys -fno-common \ ^^^^^^^^^^^^ why HERE? -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD \ -MF.depend.vmm.o -MTvmm.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse \ -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv \ -fstack-protector -Wall -Wredundant-decls -Wnested-externs \ -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ \ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas \ -Wno-error-tautological-compare -Wno-error-empty-body \ -Wno-error-parentheses-equality -Wno-error-unused-function \ -Wno-error-pointer-sign -Wno-error-shift-negative-value \ -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 \ -c /usr/src-topo/sys/amd64/vmm/vmm.c -o vmm.o /usr/src-topo/sys/amd64/vmm/vmm.c:476:1: error: no previous prototype for function 'vm_get_topology' [-Werror,-Wmissing-prototypes] vm_get_topology(struct vm *vm, uint16_t *sockets, uint16_t *cores, ^ /usr/src-topo/sys/amd64/vmm/vmm.c:486:1: error: no previous prototype for function 'vm_set_topology' [-Werror,-Wmissing-prototypes] vm_set_topology(struct vm *vm, uint16_t sockets, uint16_t cores, ^ 2 errors generated. *** Error code 1 Stop. make: stopped in /usr/src-topo/sys/modules/vmm UGLY GROSS HACK TO FIX: cp /usr/src-topo/amd64/include/vmm.h /usr/src/sys/amd64/include/vmm.h Regards, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Sun Apr 8 23:53:11 2018 Return-Path: Delivered-To: freebsd-current@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 4235CF8C150 for ; Sun, 8 Apr 2018 23:53:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B42CF815C5 for ; Sun, 8 Apr 2018 23:53:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w38Nr9du094093 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Apr 2018 16:53:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w38Nr92l094092; Sun, 8 Apr 2018 16:53:09 -0700 (PDT) (envelope-from fbsd) Date: Sun, 8 Apr 2018 16:53:09 -0700 From: bob prohaska To: "Rodney W. Grimes" Cc: freebsd-current@freebsd.org Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use Message-ID: <20180408235308.GA93747@www.zefox.net> References: <201804081900.w38J0q23014767@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201804081900.w38J0q23014767@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2018 23:53:11 -0000 On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > I am having a compile time issue for a patched that compiled fine on my > r329294 system, but now failes to compile with what looks like a wrong > header being included. > Might this be a cousin to the problem reported at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ? In that kernel compile (on an RPi3) the compiler complains In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) typedef __int_least16_t int_fast16_t; The reference to /usr/lib/clang/... seems a bit strange; isn't a major purpose of the kernel build procedure to minimize reliance on the host system's (already-stale) software? If the two problems are related, should the subject line on the bug report be changed? Thanks for reading, bob prohaska From owner-freebsd-current@freebsd.org Mon Apr 9 00:41:00 2018 Return-Path: Delivered-To: freebsd-current@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 06B76F8FF94 for ; Mon, 9 Apr 2018 00:41:00 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 7DCEB7B999 for ; Mon, 9 Apr 2018 00:40:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w390et1v016182; Sun, 8 Apr 2018 17:40:55 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w390et36016181; Sun, 8 Apr 2018 17:40:55 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804090040.w390et36016181@pdx.rh.CN85.dnsmgr.net> Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <20180408235308.GA93747@www.zefox.net> To: bob prohaska Date: Sun, 8 Apr 2018 17:40:55 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 00:41:00 -0000 > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > I am having a compile time issue for a patched that compiled fine on my > > r329294 system, but now failes to compile with what looks like a wrong > > header being included. > > > Might this be a cousin to the problem reported at > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ? > > In that kernel compile (on an RPi3) the compiler complains > > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) > typedef __int_least16_t int_fast16_t; > > The reference to /usr/lib/clang/... seems a bit strange; isn't a major > purpose of the kernel build procedure to minimize reliance on the > host system's (already-stale) software? Are you building in /usr/src, or are your sources located some place else? Really need the log that includes the cc command line, as that has the tell tell -I/usr/src/sys in it. That component is totally bogus! At no time should a src tree rooted at /usr/src-topo be trying to use files from /usr/src/. > If the two problems are related, should the subject line on the bug > report be changed? It could be, but more info would be needed. In my case I was able to proove it out as my compile from /usr/src-topo worked just fine after I copied my 3 modified header files to /usr/src. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Apr 9 01:50:44 2018 Return-Path: Delivered-To: freebsd-current@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 A591AF95046 for ; Mon, 9 Apr 2018 01:50:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2572C82445 for ; Mon, 9 Apr 2018 01:50:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w391onXR094361 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Apr 2018 18:50:50 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w391omE6094360; Sun, 8 Apr 2018 18:50:48 -0700 (PDT) (envelope-from fbsd) Date: Sun, 8 Apr 2018 18:50:48 -0700 From: bob prohaska To: "Rodney W. Grimes" Cc: freebsd-current@freebsd.org Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use Message-ID: <20180409015048.GB93747@www.zefox.net> References: <20180408235308.GA93747@www.zefox.net> <201804090040.w390et36016181@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201804090040.w390et36016181@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 01:50:44 -0000 On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote: > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > > I am having a compile time issue for a patched that compiled fine on my > > > r329294 system, but now failes to compile with what looks like a wrong > > > header being included. > > > > > Might this be a cousin to the problem reported at > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ? > > > > In that kernel compile (on an RPi3) the compiler complains > > > > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > > /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) > > typedef __int_least16_t int_fast16_t; > > > > The reference to /usr/lib/clang/... seems a bit strange; isn't a major > > purpose of the kernel build procedure to minimize reliance on the > > host system's (already-stale) software? > > Are you building in /usr/src, or are your sources located some place else? > This is a straightforward self-hosted build on an RPi3. Sources are in /usr/src. There are no modifications to the source directories. > Really need the log that includes the cc command line, as that has the > tell tell -I/usr/src/sys in it. That component is totally bogus! At > no time should a src tree rooted at /usr/src-topo be trying to use files > from /usr/src/. > Should files _outside_ /usr/src or /usr/obj _ever_ be referenced during a world or kernel build? I thought the answer was "no". The line leading up to the error message is: --- armv8_crypto_wrap.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch6 4/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -c -O3 -pipe -fno-strict-al iasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /u sr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/s ys -fno-common -g -fPIC -I/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG - ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kpri ntf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -W no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ ality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-nega tive-value -Wno-error-address-of-packed-member -std=iso9899:1999 -Werror -m arch=armv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: There's a "-I/usr/src/sys" in the fourth line, which in my case makes sense, but where does the reference to /usr/lib/clang/.... come from, and is it appropriate? > > If the two problems are related, should the subject line on the bug > > report be changed? > > It could be, but more info would be needed. > Please let me know what additional information is needed. Thanks for reading, bob prohaska From owner-freebsd-current@freebsd.org Mon Apr 9 03:54:50 2018 Return-Path: Delivered-To: freebsd-current@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 79F41F9DCDD for ; Mon, 9 Apr 2018 03:54:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 EB0A17F603 for ; Mon, 9 Apr 2018 03:54:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w393sjqm016812; Sun, 8 Apr 2018 20:54:45 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w393sjxl016811; Sun, 8 Apr 2018 20:54:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804090354.w393sjxl016811@pdx.rh.CN85.dnsmgr.net> Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <20180409015048.GB93747@www.zefox.net> To: bob prohaska Date: Sun, 8 Apr 2018 20:54:45 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 03:54:50 -0000 > On Sun, Apr 08, 2018 at 05:40:55PM -0700, Rodney W. Grimes wrote: > > > On Sun, Apr 08, 2018 at 12:00:52PM -0700, Rodney W. Grimes wrote: > > > > I am having a compile time issue for a patched that compiled fine on my > > > > r329294 system, but now failes to compile with what looks like a wrong > > > > header being included. > > > > > > > Might this be a cousin to the problem reported at > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227274 ? > > > > > > In that kernel compile (on an RPi3) the compiler complains > > > > > > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > > > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > > > /usr/lib/clang/6.0.0/include/stdint.h:228:25: error: typedef redefinition with different types ('int16_t' (aka 'short') vs '__int_fast16_t' (aka 'int')) > > > typedef __int_least16_t int_fast16_t; > > > > > > The reference to /usr/lib/clang/... seems a bit strange; isn't a major > > > purpose of the kernel build procedure to minimize reliance on the > > > host system's (already-stale) software? > > > > Are you building in /usr/src, or are your sources located some place else? > > > This is a straightforward self-hosted build on an RPi3. Sources are in > /usr/src. There are no modifications to the source directories. > > > > > Really need the log that includes the cc command line, as that has the > > tell tell -I/usr/src/sys in it. That component is totally bogus! At > > no time should a src tree rooted at /usr/src-topo be trying to use files > > from /usr/src/. > > > Should files _outside_ /usr/src or /usr/obj _ever_ be referenced during > a world or kernel build? I thought the answer was "no". Well if your sources are at /usr/src, then rarely, but there are leaks that have happend where /usr/include is refenced. > The line leading up to the error message is: > I am going to split this line up at -I > --- armv8_crypto_wrap.o --- > cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch6 > 4/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -c -O3 -pipe -fno-strict-al > iasing -Werror -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include /u > sr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC ^^^^^^^^^^^ Since your sources are /usr/src, this is fine, my problem is that I am compiling from /usr/src-topo, and I have patches, and these patches are NOT in /usr/src, but I have to put *some* of them in /usr/src to make my /usr/src-topo compile. SO something is broken, but I do not think that is what is effecting you. -I/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-NODEBUG - > ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundan > t-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ar > ith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kpri > ntf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -W > no-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equ > ality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-nega > tive-value -Wno-error-address-of-packed-member -std=iso9899:1999 -Werror -m > arch=armv8-a+crypto /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > In file included from /usr/lib/clang/6.0.0/include/arm_neon.h:31: > > There's a "-I/usr/src/sys" in the fourth line, which in my case makes sense, > but where does the reference to /usr/lib/clang/.... come from, and is it > appropriate? Something for some reason included arm_neon.h? And I do not know why that was found at /usr/lib/clang/... Could it be something in that opt_global.h? Or something trigger by the -target arch, or the -m armv8? > > > If the two problems are related, should the subject line on the bug > > > report be changed? > > > > It could be, but more info would be needed. > > > Please let me know what additional information is needed. Your problem is not the same as mine. You are compiling from /usr/src, which hides the problem I am having. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Apr 9 05:08:47 2018 Return-Path: Delivered-To: freebsd-current@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 5F9F2FA2C94 for ; Mon, 9 Apr 2018 05:08:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D59FA6831A for ; Mon, 9 Apr 2018 05:08:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w3958pRc094846 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Apr 2018 22:08:52 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w3958pFt094845; Sun, 8 Apr 2018 22:08:51 -0700 (PDT) (envelope-from fbsd) Date: Sun, 8 Apr 2018 22:08:51 -0700 From: bob prohaska To: Mark Millard Cc: "Rodney W. Grimes" , FreeBSD Current Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue] Message-ID: <20180409050851.GB94776@www.zefox.net> References: <0A2A8AD5-7B99-4E4C-B856-03FB8C61B567@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A2A8AD5-7B99-4E4C-B856-03FB8C61B567@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 05:08:47 -0000 On Sun, Apr 08, 2018 at 09:51:19PM -0700, Mark Millard wrote: > Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on > Mon Apr 9 03:54:50 UTC 2018 : > > > Something for some reason included arm_neon.h? > > > # grep -r arm_neon.h /usr/src/sys/ | more > /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:#include > > arm_neon.h is something that the kernel source itself has a reference > to. [But the stdint.h that was in the error messages was found were > the it should not exist as far as I can tell, see below.] > > # find /usr/src -name .svn -prune -o -name arm_neon.h -print > > finds nothing. But . . . > > # find /usr/lib -name arm_neon.h -print > /usr/lib/clang/6.0.0/include/arm_neon.h > > This matches the error message report and is the only > copy around in the system areas to find. (Ignoring > ports materials and /usr/local/ .) > > In turn that arm_neon.h has: > > # grep stdint.h /usr/lib/clang/6.0.0/include/arm_neon.h > #include > > Looking in a tree that I have (from an amd64 -> arm64 cross > build for what is a Cortex-A53 intended use): > > /usr/obj/DESTDIRs/clang-cortexA53-installworld/ > > were I did an installworld for arm64: > > # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name stdint.h > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/stdint.h > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/tr1/stdint.h > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/sys/stdint.h > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/stdint.h > > There is no stdint.h under that tree's /usr/lib/ area: > > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/ > > was not listed anywhere. > > For reference relative to arm_neon.h and this tree: > > # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name arm_neon.h | more > /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/clang/6.0.0/include/arm_neon.h > > I conclude that: > > /usr/lib/clang/6.0.0/include/stdint.h > > should not have been created in the first place. > > [Does that stdint.h have file-system dates/times matching > the other files from the build? Or does it look to be > mismatched and possibly just needs to be deleted?] > On my RPi3 root@www:/usr/src # ls -l /usr/lib/clang/6.0.0/include/stdint.h -rw-r--r-- 1 root wheel 23387 Feb 16 07:37 /usr/lib/clang/6.0.0/include/stdint.h Every other file in that directory is dated January 22nd. > > For reference, all the above is based on source for head -r332293: > > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332293M amd64 amd64 1200061 1200061 > > # svnlite info /usr/src | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 332293 > Last Changed Rev: 332293 > > > I do not have an arm64 system that is anywhere near up to > date at this time so the above evidence is not from a > self-hosted build: My context is not a full-match. > Looks like it's close enough 8-) Removing /usr/lib/clang/6.0.0/include/stdint.h has allowed make kernel to proceed past its former point of failure. Thank you! bob prohaska From owner-freebsd-current@freebsd.org Mon Apr 9 05:11:47 2018 Return-Path: Delivered-To: freebsd-current@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 AC16FF800C5 for ; Mon, 9 Apr 2018 05:11:47 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 2F21069E9E for ; Mon, 9 Apr 2018 05:11:46 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: dQyYg3EVM1mvIrtFYO0JqFgBoMVKSmfxxaCCOH1mTYuHVu_PpVTX5d0.XYC5zPq .IsWtD6rQPOuYmLy0qa2QVtDLIboNpE9vFga9bxSIY2D2z6OQDWjuHK6JyPTo_O7eb2NWGxaO49b 3Btl1qhziWU6bf_Lj.QaRpwgPLACIx8QEauhKQ0BSHbPSngkZLd6UC01l1OXDv_JT9uwNzvzj7nV K_wJdMU0BngeOfrrIlZdhmtJAE8C07ypgcvhMOCPOkzKCuy9yxH7AlkkGxivZWefwhZTZJJKxSwE LJ1_fL29Bc9lRBMa.SqecAMtRnqh3uGsWd25wSK4JOv4nttPE9dAgXoQZYnK_d.MFzqe5.M_CT80 nomGWqc_VKyhLjTJBAHgHPkbW.dSWRwxRRn5Slpl1PGvmlupzDNcLC7duW74Adth2vss1Zg3CzH_ Vm2xmRBpJey7kVx_AFfTUtUgAn4DFUUOv_pnGtlbUnGycNkNk.2sz1Y6cYbkxAxlLooYh0hVHrIG 2ZeBpnD_kzpEIdsZk5PSP_WIFym2c5Y_f8HoObCCQTUEbfmvjhA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 9 Apr 2018 05:11:40 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID b2fba2445e6cf2ff6a4bbffc3549ab37; Mon, 09 Apr 2018 04:51:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue] Message-Id: <0A2A8AD5-7B99-4E4C-B856-03FB8C61B567@yahoo.com> Date: Sun, 8 Apr 2018 21:51:19 -0700 To: bob prohaska , "Rodney W. Grimes" , FreeBSD Current X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 05:11:47 -0000 Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on Mon Apr 9 03:54:50 UTC 2018 : > Something for some reason included arm_neon.h? # grep -r arm_neon.h /usr/src/sys/ | more /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:#include arm_neon.h is something that the kernel source itself has a reference to. [But the stdint.h that was in the error messages was found were the it should not exist as far as I can tell, see below.] # find /usr/src -name .svn -prune -o -name arm_neon.h -print finds nothing. But . . . # find /usr/lib -name arm_neon.h -print /usr/lib/clang/6.0.0/include/arm_neon.h This matches the error message report and is the only copy around in the system areas to find. (Ignoring ports materials and /usr/local/ .) In turn that arm_neon.h has: # grep stdint.h /usr/lib/clang/6.0.0/include/arm_neon.h #include Looking in a tree that I have (from an amd64 -> arm64 cross build for what is a Cortex-A53 intended use): /usr/obj/DESTDIRs/clang-cortexA53-installworld/ were I did an installworld for arm64: # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name stdint.h = /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/stdint.h= = /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/c++/v1/tr1/stdi= nt.h /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/sys/stdint.h /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/include/stdint.h There is no stdint.h under that tree's /usr/lib/ area: /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/ was not listed anywhere. For reference relative to arm_neon.h and this tree: # find /usr/obj/DESTDIRs/clang-cortexA53-installworld -name arm_neon.h | = more = /usr/obj/DESTDIRs/clang-cortexA53-installworld/usr/lib/clang/6.0.0/include= /arm_neon.h I conclude that: /usr/lib/clang/6.0.0/include/stdint.h should not have been created in the first place. [Does that stdint.h have file-system dates/times matching the other files from the build? Or does it look to be mismatched and possibly just needs to be deleted?] For reference, all the above is based on source for head -r332293: # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332293M amd64 = amd64 1200061 1200061 # svnlite info /usr/src | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 332293 Last Changed Rev: 332293 I do not have an arm64 system that is anywhere near up to date at this time so the above evidence is not from a self-hosted build: My context is not a full-match. =3D=3D=3D Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Apr 9 08:50:54 2018 Return-Path: Delivered-To: freebsd-current@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 0DA4CF9081C for ; Mon, 9 Apr 2018 08:50:54 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73612824E0 for ; Mon, 9 Apr 2018 08:50:53 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id t67so17310160wmt.0 for ; Mon, 09 Apr 2018 01:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=5ZSY1f1jVzLxmnU32a94Cxm3ha4yb4QkOyRGCns31ko=; b=iZrXJ/78/v5uxZWoqYqsq4elk8eN5m/Vw8p1yN/WLp7y1L4Ui0S3cCbJmh1MxddmfR rmmtBtb+K0R3cOOCJXnHZqH0GGHLZcIEcRmEFx4j7rn2g0NCgM00LBPL85DacceyZ5dZ /o00ezXMFM0ZgksT70DGZ3JKYZWqzhc0U5sausF+BE5BNMlWMva1Xs7VXyI1+RYu4XD7 rk3DFkJqglasmYILJ6wV+9Qqt8YLEwmUjjOgyfTTtJ9a3C4Z5Kcd62P/aDsQBIAl9iP1 xjaQuflgwvMMV4GXEh5Acv5igwrQdRoh21RWXP/mjLXDCZNW0AcWHxOiyoe5pIsfnGnZ GrEA== 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:subject:message-id:mime-version :content-disposition:user-agent; bh=5ZSY1f1jVzLxmnU32a94Cxm3ha4yb4QkOyRGCns31ko=; b=IBuAP7Kv0r+TQablPVv8C1rmW2jiVSeFvwNZ3HQunqm2LRskYZSnYOcm7i9RpSyUHN pkJqDF2MF4t22yIBLAQMWnB5gPozgrY5bjEi+jdVq3s7RzEMLhpXdKMzqrDO/2u32i52 c9sgiNGnXN3RtudBJVQSaXEC027TMI2FeiF6HktmhJ2CorJqoSNo1I0KL0yLrnVVaFNf T3wekiKA8CeMbzTDJZq7d4/tOsSj5iWLCquKVlUTLQVe8A3Dz8sEoV7EFTv3/nBf6ZGd gNTIkeo/SVoWWL4dwby2O04xnNsiTlSvz0aUum+tDg/o+w/npQiS621R8wLuiXE9bW1a xU2A== X-Gm-Message-State: ALQs6tB9gAT6NGlgWAOuKCIivsu3x2zqqNYj3Sk+ruWWqYlNvTcw7UmS BCZVIHOtJjq+ncwXhxQE3lmmcKLB X-Google-Smtp-Source: AIpwx4+reVQB51myGLyHg1UuV8RK9D+isaLZXONdMpLJu7resD85Bf2fdTLArAMbEG90GUkFpdGLlQ== X-Received: by 10.46.145.147 with SMTP id f19mr22337461ljg.134.1523263851825; Mon, 09 Apr 2018 01:50:51 -0700 (PDT) Received: from localhost ([81.19.73.155]) by smtp.gmail.com with ESMTPSA id a1sm2784365ljj.90.2018.04.09.01.50.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 01:50:51 -0700 (PDT) Date: Mon, 9 Apr 2018 11:50:50 +0300 From: Vladimir Zakharov To: freebsd-current@freebsd.org Subject: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found Message-ID: <20180409085050.mjy6itqti6spzbdx@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20180323 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 08:50:54 -0000 Hello! For several days buildworld fails for me with the following error. Cleaning and rebuilding didn't help. ===> tests/sys/netpfil/pf/ioctl (all) --- validation --- (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t PROG=validation ) Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/validation.o --- validation.o --- In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^~~~~~~~~~~~~~~~~ 1 error generated. *** [validation.o] Error code 1 make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl My /etc/src.conf (I have PF switched off): WITHOUT_ACCT= WITHOUT_AMD= WITHOUT_APM= WITHOUT_ATM= WITHOUT_AUTHPF= WITHOUT_BLACKLIST= WITHOUT_BLUETOOTH= WITHOUT_BOOTPARAMD= WITHOUT_BOOTPD= WITHOUT_BSNMP= WITHOUT_CCD= WITHOUT_CROSS_COMPILER= WITHOUT_CTM= WITHOUT_CUSE= WITHOUT_CXGBETOOL= # WITHOUT_DEBUG_FILES= WITHOUT_EE= WITHOUT_FDT= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_FREEBSD_UPDATE= WITHOUT_FTP= WITHOUT_GDB= WITHOUT_GNU_GREP_COMPAT= WITHOUT_HAST= WITHOUT_HTML= WITHOUT_HYPERV= WITHOUT_IPFILTER= WITHOUT_ISCSI= WITHOUT_KVM= WITHOUT_LEGACY_CONSOLE= WITHOUT_LIB32= WITHOUT_LPR= WITHOUT_NDIS= WITHOUT_PC_SYSINSTALL= WITHOUT_PF= WITHOUT_PPP= WITHOUT_QUOTAS= WITHOUT_RADIUS_SUPPORT= WITHOUT_RBOOTD= WITHOUT_SHAREDOCS= WITHOUT_TALK= WITHOUT_TFTP= WITHOUT_TIMED= WITH_BSD_GREP= WITH_CCACHE_BUILD= # WITH_CLANG_EXTRAS= # WITH_CTF= # WITH_DTRACE_TESTS= WITH_SORT_THREADS= WITH_SVN= -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Mon Apr 9 09:28:10 2018 Return-Path: Delivered-To: freebsd-current@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 370F6F9310A for ; Mon, 9 Apr 2018 09:28:10 +0000 (UTC) (envelope-from srs0=wf8v=g6=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9CD576A7C for ; Mon, 9 Apr 2018 09:28:09 +0000 (UTC) (envelope-from srs0=wf8v=g6=sigsegv.be=kristof@codepro.be) Received: from [10.0.2.164] (ptr-8ripyyi8f4g039wrw4k.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:fc3b:1470:3584:ef64]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 9FFA53D417; Mon, 9 Apr 2018 11:28:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1523266087; bh=Ngz6oFozLwJk83iHnR5Y4h+8faG2W/LoyxOCCNBlvVY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=e7z+bGfphxYzQBT74YRSDwiTciwuz0CjMRL4MDy+SQClZWDHiqdP/gn4wwoIz5NVa Km5v40pwJ1VNmY+hzRYTgLNkSy0Pwyr0TXwMyymadSXWUFIl7VJFlvM1XY52h0tdPb QeyHPLoRw7WurFAIMmHfRCmS7oPHgyIs3tAvLWhs= From: "Kristof Provost" To: "Vladimir Zakharov" Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found Date: Mon, 09 Apr 2018 11:28:06 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: In-Reply-To: <20180409085050.mjy6itqti6spzbdx@vzakharov> References: <20180409085050.mjy6itqti6spzbdx@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 09:28:10 -0000 On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: > For several days buildworld fails for me with the following error. > Cleaning and > rebuilding didn't help. > > ===> tests/sys/netpfil/pf/ioctl (all) > --- validation --- > (cd /usr/src/tests/sys/netpfil/pf/ioctl && > DEPENDFILE=.depend.validation NO_SUBDIR=1 make -f > /usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t > PROG=validation ) > Building > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/validation.o > --- validation.o --- > In file included from > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal > error: 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [validation.o] Error code 1 > > make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl > > > My /etc/src.conf (I have PF switched off): Ah, that’s my fault. I didn’t consider people who’d switch off pf when I added the new ioctl tests. You can work around the issue by removing the new tests yourself, or by building pf in anyway (it won’t do anything unless you load the module and activate it). This should be a workaround for you until I can commit a better fix: diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile index c055e6840bd..259e1275d9c 100644 --- a/tests/sys/netpfil/pf/Makefile +++ b/tests/sys/netpfil/pf/Makefile @@ -3,7 +3,6 @@ PACKAGE= tests TESTSDIR= ${TESTSBASE}/sys/netpfil/pf -TESTS_SUBDIRS+= ioctl ATF_TESTS_SH+= pass_block \ forward \ Regards, Kristof From owner-freebsd-current@freebsd.org Mon Apr 9 11:10:15 2018 Return-Path: Delivered-To: freebsd-current@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 DBF56F9A4A3 for ; Mon, 9 Apr 2018 11:10:14 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5175C6E09D for ; Mon, 9 Apr 2018 11:10:14 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id c78-v6so5961010lfh.1 for ; Mon, 09 Apr 2018 04:10:14 -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:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Vzt/N5MBEhsjyA6rJ3Pxaj4DnoJn2vzb+jRijr56/+g=; b=MwJcSkYrwvOSfBHWntVzIczqdCnH7aYTqDlQQ7YRY6GxiAHSaaXjkEtobb2/rxWoh3 q49sntWK4SXssfv/qYe/+LX7P0NVxfh5EmZbp3uXTWsBZp6daIO0oE/KUlMCJ6PiDw3T QdEOVsIoFiW9tS0u0y5KXFGsExqfID69NAR/HV2ImmE9Q201hSTdnhz4022nzAfIf8vF e1urQcpTbD2Ptwf3DBj+RKiO2P+d+q3PAXhVwWck133YR/d85Ca8Y8yIpUAuwWWmxkCJ I8Bx0u8bZS16n8QYUVCaIcDo5xoHy7bx3oakuOQX77foJ21gKuwOl8Rpdf/92PSN5FzK 9oDg== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Vzt/N5MBEhsjyA6rJ3Pxaj4DnoJn2vzb+jRijr56/+g=; b=WYiKtk3bX6IT2pH+SAcHDc9FGjoJxcvZG7M3cc3+LJOC7VfJ28meLIJr8eH9p56r/G 50LXUyQX+rZ9IubeCJp/dCfz6xkj0W3npiiYuF4F7OrZX05BMh7TzIYK80LSEhla4VcJ 0D/OujMIyNZdRDYC5Rn2CqiSCIs7oI39ZtIFOGOuqQB77WVc0+WNx4s+OFE41DluX/yd VDG0QW/T/7v612c6SDbZoAPY7IdUAJtGqXy8jXif9toA5CBGwN5DtGtFCIQ0SvM4ea/q r3sF5W57vdQa8hnjT+y2MOiyhml8P0MfLtLPYd9yBe/WvMu7GB4boyMQ+rwx0fyT6gnT hAcQ== X-Gm-Message-State: ALQs6tChfbaFXs4uD878smvyD0IwnMWkt5bNRbUiN8zCE+r7Ma2X9beW 3zVc5SupLEbKZSvED4kAKmE0tuOd X-Google-Smtp-Source: AIpwx490yY4lfsCt07iY8HQCHnKGAzwCVbxJz2KdzPBdYWi3n0MC3shmLZubZs7clm3kL9PdB1MIBg== X-Received: by 2002:a19:a60a:: with SMTP id p10-v6mr22349483lfe.41.1523272212005; Mon, 09 Apr 2018 04:10:12 -0700 (PDT) Received: from localhost ([81.19.73.155]) by smtp.gmail.com with ESMTPSA id q83-v6sm22556lfg.46.2018.04.09.04.10.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 04:10:11 -0700 (PDT) Date: Mon, 9 Apr 2018 14:10:11 +0300 From: Vladimir Zakharov To: Kristof Provost Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found Message-ID: <20180409111011.5gqhtqtuw6xsg3wq@vzakharov> References: <20180409085050.mjy6itqti6spzbdx@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20180323 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 11:10:15 -0000 On Mon, Apr 09, 2018, Kristof Provost wrote: > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: > > For several days buildworld fails for me with the following error. Cleaning > and > rebuilding didn't help. > > ===> tests/sys/netpfil/pf/ioctl (all) > --- validation --- > (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation > NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile > _RECURSING_PROGS=t PROG=validation ) > Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ > validation.o > --- validation.o --- > In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal > error: 'netpfil/pf/pf.h' file not found > #include > ^~~~~~~~~~~~~~~~~ > 1 error generated. > *** [validation.o] Error code 1 > > make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl > > > My /etc/src.conf (I have PF switched off): > > Ah, that’s my fault. I didn’t consider people who’d switch off pf when I added > the new ioctl tests. > > You can work around the issue by removing the new tests yourself, or by > building pf in anyway (it won’t do anything unless you load the module and > activate it). > > This should be a workaround for you until I can commit a better fix: > > diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile > index c055e6840bd..259e1275d9c 100644 > --- a/tests/sys/netpfil/pf/Makefile > +++ b/tests/sys/netpfil/pf/Makefile > @@ -3,7 +3,6 @@ > PACKAGE= tests > > TESTSDIR= ${TESTSBASE}/sys/netpfil/pf > -TESTS_SUBDIRS+= ioctl > > ATF_TESTS_SH+= pass_block \ > forward \ Thanks. I've applied this fix for now and managed to update. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Mon Apr 9 12:32:30 2018 Return-Path: Delivered-To: freebsd-current@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 0DD48FA0B49 for ; Mon, 9 Apr 2018 12:32:30 +0000 (UTC) (envelope-from ota@j.email.ne.jp) 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 A19047B71A for ; Mon, 9 Apr 2018 12:32:29 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: by mailman.ysv.freebsd.org (Postfix) id 6677FFA0B47; Mon, 9 Apr 2018 12:32:29 +0000 (UTC) Delivered-To: current@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 2BEA9FA0B46; Mon, 9 Apr 2018 12:32:29 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail01.asahi-net.or.jp (mail01.asahi-net.or.jp [202.224.55.13]) by mx1.freebsd.org (Postfix) with ESMTP id B10E67B6F3; Mon, 9 Apr 2018 12:32:27 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-108-53-56-94.nwrknj.fios.verizon.net [108.53.56.94]) (Authenticated sender: NR2Y-OOT) by mail01.asahi-net.or.jp (Postfix) with ESMTPSA id 1056C57F70; Mon, 9 Apr 2018 21:22:40 +0900 (JST) Date: Mon, 9 Apr 2018 08:22:13 -0400 From: Yoshihiro Ota To: Bruce Evans Cc: Dimitry Andric , Konstantin Belousov , current@FreeBSD.org, amd64@FreeBSD.org Subject: Re: i386 4/4 change Message-Id: <20180409082213.1ca1fc0cd589bafa98a4fead@j.email.ne.jp> In-Reply-To: <20180401151124.G893@besplex.bde.org> References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> <20180401151124.G893@besplex.bde.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; i386-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 12:32:30 -0000 What is the current status of this? Based on SVN history, it doesn't look https://reviews.freebsd.org/D14633 has been merged/commited yet. I can try after I recover from disk crahes. I expect I need few more days to restore. Will this retire PAE option? Thanks, Hiro On Sun, 1 Apr 2018 17:05:03 +1000 (EST) Bruce Evans wrote: > > On Sun, 1 Apr 2018, Dimitry Andric wrote: > > > On 31 Mar 2018, at 17:57, Bruce Evans wrote: > >> > >> On Sat, 31 Mar 2018, Konstantin Belousov wrote: > >> > >>> the change to provide full 4G of address space for both kernel and > >>> user on i386 is ready to land. The motivation for the work was to both > >>> mitigate Meltdown on i386, and to give more breazing space for still > >>> used 32bit architecture. The patch was tested by Peter Holm, and I am > >>> satisfied with the code. > >>> > >>> If you use i386 with HEAD, I recommend you to apply the patch from > >>> https://reviews.freebsd.org/D14633 > >>> and report any regressions before the commit, not after. Unless > >>> a significant issue is reported, I plan to commit the change somewhere > >>> at Wed/Thu next week. > >>> > >>> Also I welcome patch comments and reviews. > >> > >> It crashes at boot time in getmemsize() unless booted with loader which > >> I don't want to use. > > > For me, it at least compiles and boots OK, but I'm one of those crazy > > people who use the default boot loader. ;) > > I found a quick fix and sent it to kib. (2 crashes in vm86 code for memory > sizing. This is not called if loader is used && the system has smap. Old > systems don't have smap, so they crash even if loader is used.) > > > I haven't yet run any performance tests, I'll try building world and a > > few large ports tomorrow. General operation from the command line does > > not feel "sluggish" in any way, however. > > Further performance tests: > - reading /dev/zero using tinygrams is 6 times slower > - read/write of a pipe using tinygrams is 25 times slower. It also gives > unexpected values in wait statuses on exit, hopefully just because the > bug is in the test program is exposed by the changed timing (but later > it also gave SIGBUS errors). This does a context switch or 2 for every > read/write. It now runs 7 times slower using 2 4.GHz CPUs than in > FreeBSD-5 using 1 2.0 GHz CPU. The faster CPUs and 2 of them used to > make it run 4 times faster. It shows another slowdown since FreeBSD-5, > and much larger slowdowns since FreeBSD-1: > > 1996 FreeBSD on P1 133MHz: 72k/s > 1997 FreeBSD on P1 133MHz: 44k/s (after dyson's opts for large sizes) > 1997 Linux on P1 133MHz: 93k/s (simpler is faster for small sizes) > 1999 FreeBSD on K6 266MHz: 129k/s > 2018 FBSD-~5 on AthXP 2GHz: 696k/s > 2018 FreeBSD on i7 2x4GHz: 2900k/s > 2018 FBSD4+4 on i7 2x4GHz: 113k/s (faster than Linux on a P1 133MHz!!) > > Netblast to localhost has much the same 6 times slowness as reading > /dev/zero using tinygrams. This is the slowdown for syscalls. > Tinygrams are hard to avoid for UDP. Even 1500 bytes is a tinygram > for /dev/zero. Without 4+4, localhost is very slow because it does > a context switch or 2 for every packet (even with 2 CPUs when there is > no need to switch). Without 4+4 this used to cost much the same as the > context switches for the pipe benchmark. Now it costs relatively much > less since (for netblast to localhost) all of the context switches are > between kernel threads. > > The pipe benchmark uses select() to avoid busy-waiting. That was good > for UP. But for SMP with just 2 CPUs, it is better to busy-wait and > poll in the reader and writer. > > netblast already uses busy-waiting. It used to be a bug that select() > doesn't work on sockets, at least for UDP, so blasting using busy-waiting > is the only possible method (timeouts are usually too coarse-grained to > go as fast as blasting, and if they are fine-grained enough to go fast > then they are not much better than busy-waiting with time wasted for > setting up timeouts). SMP makes this a feature. It forces use of busy- > waiting, which is best if you have a CPU free to run it and this method > doesn't take to much power. > > Context switches to task queues give similar slowness. This won't be > affected by 4+4 since task queues are in the kernel. I don't like > networking in userland since it has large syscall and context switch > costs. Increasing these by factors of 6 and 25 doesn't help. It > can only be better by combining i/o in a way that the kernel neglects > to do or which is imposed by per-packet APIs. Slowdown factors of 6 > or 25 require the combined i/o to be 6 or 25 larger to amortise the costs. > > Bruce > _______________________________________________ > 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-current@freebsd.org Mon Apr 9 12:52:02 2018 Return-Path: Delivered-To: freebsd-current@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 695CBFA1E58 for ; Mon, 9 Apr 2018 12:52:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EFDFE861D2 for ; Mon, 9 Apr 2018 12:52:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id AFDEBFA1E54; Mon, 9 Apr 2018 12:52:01 +0000 (UTC) Delivered-To: current@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 9C129FA1E52; Mon, 9 Apr 2018 12:52:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 11A4E861AF; Mon, 9 Apr 2018 12:52:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w39Cpnmt097720 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Apr 2018 15:51:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w39Cpnmt097720 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w39CpnRg097719; Mon, 9 Apr 2018 15:51:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 9 Apr 2018 15:51:49 +0300 From: Konstantin Belousov To: Yoshihiro Ota Cc: Bruce Evans , Dimitry Andric , current@FreeBSD.org, amd64@FreeBSD.org Subject: Re: i386 4/4 change Message-ID: <20180409125149.GA1774@kib.kiev.ua> References: <20180331102901.GN1774@kib.kiev.ua> <20180401004833.L3296@besplex.bde.org> <3FAD36FD-FA90-49F6-9141-B9CCCCA2BF00@FreeBSD.org> <20180401151124.G893@besplex.bde.org> <20180409082213.1ca1fc0cd589bafa98a4fead@j.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180409082213.1ca1fc0cd589bafa98a4fead@j.email.ne.jp> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 12:52:02 -0000 On Mon, Apr 09, 2018 at 08:22:13AM -0400, Yoshihiro Ota wrote: > What is the current status of this? > > Based on SVN history, it doesn't look https://reviews.freebsd.org/D14633 has been merged/commited yet. I fixed bugs reported by Bruce. Right now the patch is waiting for some other testing to finish, before the final retest. > > I can try after I recover from disk crahes. > I expect I need few more days to restore. > > Will this retire PAE option? The patch is ortogonal to PAE. From owner-freebsd-current@freebsd.org Mon Apr 9 13:04:29 2018 Return-Path: Delivered-To: freebsd-current@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 310CAFA2C4E for ; Mon, 9 Apr 2018 13:04:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com [74.6.129.82]) (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 C99A86D37F for ; Mon, 9 Apr 2018 13:04:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ZMvUUAsVM1nWJcAwtfl5D2OP24HOLyHzuzHtOKI5AOxt9CshaOwY.uzb_.rFzAV XHD23zd_zncn.Cd3dukePpxshjNxGbqjj4opHP36A2haAqRJkaMHVSmazNr5pTFuyJFy9Jil0JyH 1Lgl8iAnGHHIAxxQ18EB_x_1uhazNC74Hh8wMBMBVopmgUXzzbFJAOxZndGe_Y9vxDpZkttgz4NK K_QVCU3lrTzbIaV6ouPMC8vWN.tOBXlCNQYQUa2H1E5IvoZmVQZmujfvkncnvuuQ8ELldC2wOyZp eqSDwhHN7y5cUxmBNEEHynlbziFbNJqm2h48ldxPt0Z5t_xFH8OEilIksr19biZumXpXcer8NhP2 h8_lG3MrL_Ax2xTLgQJ3btjj3fY8_pZ8_5aSY2fhkUN.dVM6B7BOozSS2hYIhNdIrMN2sDWufTMg 70Iku78zY3arqqftLFoKfWaXSpDgxy2mDRO389SCpcvUCwKFu49iSvDAD37LcqApwmFxP2ijQ4u2 6_.OCZZrRANMScvD88FdihEostYTFOJk7fitG Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Mon, 9 Apr 2018 13:04:27 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d2c3081c582950bb21563c6e3688df75; Mon, 09 Apr 2018 13:04:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue] From: Mark Millard In-Reply-To: <20180409050851.GB94776@www.zefox.net> Date: Mon, 9 Apr 2018 06:04:24 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8C550781-A8EA-4DC7-B719-E62EE71EC0E7@yahoo.com> References: <0A2A8AD5-7B99-4E4C-B856-03FB8C61B567@yahoo.com> <20180409050851.GB94776@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 13:04:29 -0000 On 2018-Apr-8, at 10:08 PM, bob prohaska wrote: >> . . . > On my RPi3=20 > root@www:/usr/src # ls -l /usr/lib/clang/6.0.0/include/stdint.h > -rw-r--r-- 1 root wheel 23387 Feb 16 07:37 = /usr/lib/clang/6.0.0/include/stdint.h >=20 > Every other file in that directory is dated January 22nd. >=20 >=20 >> . . . >=20 > Looks like it's close enough 8-) > Removing /usr/lib/clang/6.0.0/include/stdint.h has allowed make kernel > to proceed past its former point of failure.=20 >=20 Looks like you copied the file there. Its presence is not a build problem. See below. =46rom Feb 16 Email from you: From: bob prohaska Subject: Re: RPI3 can't build kernel-toolchain Date: February 16, 2018 at 9:09:27 AM PST To: Mark Millard Cc: freebsd-arm at freebsd.org, bob prohaska . . . Running cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h = /usr/lib/clang/6.0.0/include didn't solve the problem.=20 Using cp /usr/lib/include/stdint.h = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/ does seem to be working. Since this is a self-hosted compile there's = hope the resulting kernel will be more stable than r328935. . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Apr 9 15:08:20 2018 Return-Path: Delivered-To: freebsd-current@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 724BDF87583 for ; Mon, 9 Apr 2018 15:08:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB6C572F20 for ; Mon, 9 Apr 2018 15:08:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w39F8OhB097079 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Apr 2018 08:08:25 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w39F8OcM097078; Mon, 9 Apr 2018 08:08:24 -0700 (PDT) (envelope-from fbsd) Date: Mon, 9 Apr 2018 08:08:24 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD Current Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use [actually the arm_neon.h and stdint.h issue] Message-ID: <20180409150824.GA94953@www.zefox.net> References: <0A2A8AD5-7B99-4E4C-B856-03FB8C61B567@yahoo.com> <20180409050851.GB94776@www.zefox.net> <8C550781-A8EA-4DC7-B719-E62EE71EC0E7@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C550781-A8EA-4DC7-B719-E62EE71EC0E7@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 15:08:20 -0000 On Mon, Apr 09, 2018 at 06:04:24AM -0700, Mark Millard wrote: > On 2018-Apr-8, at 10:08 PM, bob prohaska wrote: > >> . . . > > On my RPi3 > > root@www:/usr/src # ls -l /usr/lib/clang/6.0.0/include/stdint.h > > -rw-r--r-- 1 root wheel 23387 Feb 16 07:37 /usr/lib/clang/6.0.0/include/stdint.h > > > > Every other file in that directory is dated January 22nd. > > > > > >> . . . > > > > Looks like it's close enough 8-) > > Removing /usr/lib/clang/6.0.0/include/stdint.h has allowed make kernel > > to proceed past its former point of failure. > > > > Looks like you copied the file there. Its presence is not a > build problem. See below. > > >From Feb 16 Email from you: > > From: bob prohaska > Subject: Re: RPI3 can't build kernel-toolchain > Date: February 16, 2018 at 9:09:27 AM PST > To: Mark Millard > Cc: freebsd-arm at freebsd.org, bob prohaska > . . . > Running > cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h /usr/lib/clang/6.0.0/include > didn't solve the problem. > I remembered the experiment that worked, and forgot the one that didn't. Thank you! bob prohaska From owner-freebsd-current@freebsd.org Mon Apr 9 19:52:43 2018 Return-Path: Delivered-To: freebsd-current@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 627BFF9E27B for ; Mon, 9 Apr 2018 19:52:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC5F6EB7B; Mon, 9 Apr 2018 19:52:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 330D710AFD4; Mon, 9 Apr 2018 15:52:42 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, sgk@troutmask.apl.washington.edu Cc: Ed Maste Subject: Re: Can't load linux64.ko module Date: Mon, 09 Apr 2018 12:41:07 -0700 Message-ID: <1705675.KsztJEaACH@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180404213453.GA35165@troutmask.apl.washington.edu> References: <20180403162600.GA23894@troutmask.apl.washington.edu> <20180404211315.GA35006@troutmask.apl.washington.edu> <20180404213453.GA35165@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 09 Apr 2018 15:52:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 19:52:43 -0000 On Wednesday, April 04, 2018 02:34:53 PM Steve Kargl wrote: > On Wed, Apr 04, 2018 at 02:13:15PM -0700, Steve Kargl wrote: > > > > OK, so where is elf64_linux_vdso_fixup suppose to come from? > > > > The answer is compat/linux/linux_vdso.c where we find > > #if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) > #define __ELF_WORD_SIZE 32 > #else > #define __ELF_WORD_SIZE 64 > #endif > > having COMPAT_LINUX32 in my kernel config file gives me > elf32_linux_vdso_fixup. It seems that one cannot have > a kernel that supports both 32 and 64-bit linux software. > > linux(4) states > > for an amd64 kernel use: > > options COMPAT_LINUX32 > > Alternatively, to load the ABI as a module at boot time, place the > following line in loader.conf(5): > > linux_load="YES" > > It turns out that I have 'linux_load=YES" in /etc/loader.conf. > When I boot the kernel built with COMPAT_LINUX32 prevents > the kldload of linux64.ko. > > Oh well, learn something new everyday. The Right Way to fix this is probably to have linux_vdso32.c and linux_vdso64.c that #include linux_vdso.c after setting ELF_WORD_SIZE similar to how sys/kern/imgact_elf.c works. Then the COMPAT_LINUX and linux64.ko modules would include linux_vdso64.c and COMPAT_LINUX32 and linux32.ko modules (and linux.ko on i386) would include linux_vdso32.c. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Apr 9 19:52:44 2018 Return-Path: Delivered-To: freebsd-current@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 C3020F9E28B; Mon, 9 Apr 2018 19:52:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66A476EB7F; Mon, 9 Apr 2018 19:52:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 9053110AFD6; Mon, 9 Apr 2018 15:52:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: Mark Millard , FreeBSD Hackers , freebsd-amd64@freebsd.org Subject: Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? Date: Mon, 09 Apr 2018 12:37:26 -0700 Message-ID: <2644434.8Ktpdmy6i5@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> References: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 09 Apr 2018 15:52:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 19:52:44 -0000 On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote: > For: > > # uname -apKU > FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 > > I get: > > . . . > pci0: at device 7.3 (no driver attached) > . . . > intsmb0: at device 7.3 on pci0 > intsmb0: Could not allocate I/O space > device_attach: intsmb0 attach returned 6 > > on a Ryzen Threadripper 1950X where FreeBSD is being run under > Hyper-V (on a Windows 10 Pro machine). > > Is this expected? Did I misconfigure something in Hyper-V? That seems like an odd device to have for an AMD machine. I suspect that this has never worked and the module started auto-loading due to devmatch. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Apr 9 20:29:52 2018 Return-Path: Delivered-To: freebsd-current@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 B2048FA0F03 for ; Mon, 9 Apr 2018 20:29:52 +0000 (UTC) (envelope-from jhb@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 5659E78B2D for ; Mon, 9 Apr 2018 20:29:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 17352FA0F01; Mon, 9 Apr 2018 20:29:52 +0000 (UTC) Delivered-To: current@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 04B52FA0F00 for ; Mon, 9 Apr 2018 20:29:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5DB078B24; Mon, 9 Apr 2018 20:29:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 5378310AFD3; Mon, 9 Apr 2018 16:29:50 -0400 (EDT) From: John Baldwin To: current@freebsd.org, mjg@freebsd.org, oshogbo@freebsd.org Subject: Duplicate free in of file caps data Date: Mon, 09 Apr 2018 13:25:33 -0700 Message-ID: <4163881.eBQ6x7P6Ym@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 09 Apr 2018 16:29:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 20:29:52 -0000 I updated my laptop to HEAD as of Friday and got the following panic after a bhyve process using capabilities exited: panic: Duplicate free of 0xfffff8039515eba0 from zone 0xfffff8000200e540(16) slab 0xfffff8039515ef90(186) ... (kgdb) where #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:361 #2 0xffffffff805e42e2 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 #3 0xffffffff805e484d in vpanic (fmt=, ap=0xfffffe008b2f4700) at /usr/src/sys/kern/kern_shutdown.c:837 #4 0xffffffff805e4893 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:764 #5 0xffffffff80862a37 in uma_dbg_free (zone=0xfffff8000200e540, slab=0xfffff8039515ef90, item=0xfffff8039515eba0) at /usr/src/sys/vm/uma_core.c:3931 #6 0xffffffff80862247 in uma_zfree_arg (zone=0xfffff8000200e540, item=, udata=0xfffff8039515ef90) at /usr/src/sys/vm/uma_core.c:2876 #7 0xffffffff805bf715 in free (addr=0xfffff8039515eba0, mtp=0xffffffff80c95ec0 ) at /usr/src/sys/kern/kern_malloc.c:711 #8 0xffffffff805923ba in filecaps_free (fcaps=) at /usr/src/sys/kern/kern_descrip.c:1580 #9 fdefree_last (fde=) at /usr/src/sys/kern/kern_descrip.c:297 #10 fdescfree_fds (td=0xfffff8039a484000, fdp=0xfffff8039acfe000, needclose=true) at /usr/src/sys/kern/kern_descrip.c:2242 #11 0xffffffff80591f00 in fdescfree (td=0xfffff8039a484000) at /usr/src/sys/kern/kern_descrip.c:2307 #12 0xffffffff805a0940 in exit1 (td=0xfffff8039a484000, rval=, signo=0) at /usr/src/sys/kern/kern_exit.c:378 #13 0xffffffff805a044d in sys_sys_exit (td=, uap=) at /usr/src/sys/kern/kern_exit.c:180 #14 0xffffffff808bd2e9 in syscallenter (td=0xfffff8039a484000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134 #15 amd64_syscall (td=0xfffff8039a484000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:936 #16 #17 0x0000000800ae3eda in ?? () (kgdb) frame 8 #8 0xffffffff805923ba in filecaps_free (fcaps=) at /usr/src/sys/kern/kern_descrip.c:1580 1580 free(fcaps->fc_ioctls, M_FILECAPS); Note that I am using a patched bhyve that uses cap_ioctls_limit() on a listen socket (so the caps will be copied to the new socket during accept()). I'll see if I can't come up with a simpler program to reproduce this. -- John Baldwin From owner-freebsd-current@freebsd.org Mon Apr 9 22:29:14 2018 Return-Path: Delivered-To: freebsd-current@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 669F2F83C95 for ; Mon, 9 Apr 2018 22:29:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E848276C51; Mon, 9 Apr 2018 22:29:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-20-68.dyn.iinet.net.au [115.166.20.68]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w39MT1Ai086220 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2018 15:29:04 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: g_handleattr: md0 bio_length 24 len 31 -> EFAULT To: Kyle Evans , Peter Holm Cc: Michael Dexter , FreeBSD Current , "O. Hartmann" References: <20180324103615.7b88c33f@thor.intern.walstatt.dynvpn.de> <20180408105321.GA55435@x2.osted.lan> From: Julian Elischer Message-ID: <0181f13e-7451-7d13-6605-9116fdb387c8@freebsd.org> Date: Tue, 10 Apr 2018 06:28:55 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 22:29:14 -0000 On 8/4/18 10:48 pm, Kyle Evans wrote: > On Sun, Apr 8, 2018 at 5:53 AM, Peter Holm wrote: >> On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote: >>> On 3/24/18 2:35 AM, O. Hartmann wrote: >>>> Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, created via >>>> the classical manual way, no makefs), my recent CURRENT system dumps the >>>> console full of these error messages: >>>> >>>> g_handleattr: md0 bio_length 24 len 31 -> EFAULT >>>> >>>> I do not know what they are supposed to mean and I'd like to ask whether someone could >>>> shed some light on this. >>> I am seeing this on the the latest snapshot when attempting to run >>> option_survey.sh which creates an md-attached disk image. >>> >>> Anyone else seeing this? >>> >>> Michael >> Yes, I have: >> >> [pho@freefall ~/public_html/stress/log]$ grep -a g_handleattr: `ls -rt` >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT >> [pho@freefall ~/public_html/stress/log]$ >> > FYI- this should be fixed by r332070. > > Thanks, > > Kyle Evans > _______________________________________________ > 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" > so I think current has other issues I want to avoid can I just pull that commit and have have svn know how to upgrade past it later? From owner-freebsd-current@freebsd.org Mon Apr 9 23:17:48 2018 Return-Path: Delivered-To: freebsd-current@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 C114BF86EFB for ; Mon, 9 Apr 2018 23:17:48 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (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 6B18B829FB for ; Mon, 9 Apr 2018 23:17:48 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.3] (c-73-216-227-39.hsd1.va.comcast.net [73.216.227.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 4C17027000AB for ; Mon, 9 Apr 2018 19:11:51 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 4C17027000AB Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1523315511; bh=rrrRRfF5tx9GyCfn1G2OjiZ1ko0Dv4JH8hMvJwaC7Z8=; h=To:From:Subject:Date:From; b=JqrVWiutfmC8cF3bXyDyWac0q9UtpfLEXrcv4PNHLlyRp3jRlWFSYgsAhEtyZThBh +qj+709hftSuojavmDm0WBY3J1lb8FIGrPRhsMB4NSP88BOiXEi0ae4QNe1zkAM/1P nuKQbqJ/hw7WuHL1xcWZW6Zkmr4k55ge5F4DvvpfPYT403nCLCYLAzy5f/FM/GdGbV OUzazD+8sFcpkKN6nwAzsCtTyaspOZNWc5kgxAyADyBp4HG7touWtD9kWmAl91yXn8 LUxFumegZpUTpLCYFLO2LTtwtE7I+vXUM+vagpTMnH7hVMIimFE8xFoivYyH80YeYK SgqthrYr1P/ww== To: freebsd-current@freebsd.org From: Andrew Gallatin Subject: Odd ZFS boot module issue on r332158 Message-ID: Date: Mon, 9 Apr 2018 19:11:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 23:17:49 -0000 I updated my main amd64 workstation to r332158 from something much earlier (mid Jan). Upon reboot, all seemed well. However, I later realized that the vmm.ko module was not loaded at boot, because bhyve PCI passthru did not work. My loader.conf looks like (I'm passing a USB interface through): ####### vmm_load="YES" opensolaris_load="YES" zfs_load="YES" nvidia_load="YES" nvidia-modeset_load="YES" # Tune ZFS Arc Size - Change to adjust memory used for disk cache vfs.zfs.arc_max="4096M" hint.xhci.2.disabled="1" pptdevs="8/0/0" hw.dmar.enable="0" cuse_load="YES" ####### The problem seems "random". I rebooted into single-user to see if somehow, vmm.ko was loaded at boot and something was unloading vmm.ko. However, on this boot it was loaded. I then ^D'ed and continued to multi-user, where X failed to start because this time, the nvidia modules were not loaded. (but nvidia had been loaded on the 1st boot). So it *seems* like different modules are randomly not loaded by the loader, at boot. The ZFS config is: config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0p2 ONLINE 0 0 0 da3p2 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 ada1p2 ONLINE 0 0 0 da0p2 ONLINE 0 0 0 cache da2s1d ONLINE 0 0 0 The data drives in the pool are all exactly like this: => 34 9767541101 ada0 GPT (4.5T) 34 6 - free - (3.0K) 40 204800 1 efi (100M) 204840 9763209216 2 freebsd-zfs (4.5T) 9763414056 4096000 3 freebsd-swap (2.0G) 9767510056 31079 - free - (15M) There is about 1.44T used in the pool. I have no idea how ZFS mirrors work, but I'm wondering if somehow this is a 2T problem, and there are issues with blocks on difference sides of the mirror being across the 2T boundary. Sorry to be so vague.. but this is the one machine I *don't* have a serial console on, so I don't have good logs. Drew From owner-freebsd-current@freebsd.org Tue Apr 10 03:33:13 2018 Return-Path: Delivered-To: freebsd-current@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 97186F99461 for ; Tue, 10 Apr 2018 03:33:13 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 46447838BB for ; Tue, 10 Apr 2018 03:33:13 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 71C7914FCC for ; Tue, 10 Apr 2018 03:33:12 +0000 (UTC) Subject: Re: Odd ZFS boot module issue on r332158 To: freebsd-current@freebsd.org References: From: Allan Jude Openpgp: preference=signencrypt Message-ID: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> Date: Mon, 9 Apr 2018 23:33:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GJGpJoZeIZ30FlmN3X4bEmNmIDvTY4DjL" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 03:33:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GJGpJoZeIZ30FlmN3X4bEmNmIDvTY4DjL Content-Type: multipart/mixed; boundary="JvzDtnG2I0n6zmhhiKQVAjGsOQ4Sncttc"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> Subject: Re: Odd ZFS boot module issue on r332158 References: In-Reply-To: --JvzDtnG2I0n6zmhhiKQVAjGsOQ4Sncttc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-04-09 19:11, Andrew Gallatin wrote: > I updated my main amd64 workstation to r332158 from something much > earlier (mid Jan). >=20 > Upon reboot, all seemed well.=C2=A0 However, I later realized that the = vmm.ko > module was not loaded at boot, because bhyve PCI passthru did not > work.=C2=A0 My loader.conf looks like (I'm passing a USB interface thro= ugh): >=20 > ####### > vmm_load=3D"YES" > opensolaris_load=3D"YES" > zfs_load=3D"YES" > nvidia_load=3D"YES" > nvidia-modeset_load=3D"YES" >=20 > # Tune ZFS Arc Size - Change to adjust memory used for disk cache > vfs.zfs.arc_max=3D"4096M" > hint.xhci.2.disabled=3D"1" > pptdevs=3D"8/0/0" > hw.dmar.enable=3D"0" > cuse_load=3D"YES" > ####### >=20 > The problem seems "random".=C2=A0 I rebooted into single-user to > see if somehow, vmm.ko was loaded at boot and something > was unloading vmm.ko.=C2=A0 However, on this boot it was loaded.=C2=A0 = I then > ^D'ed and continued to multi-user, where X failed to start because > this time, the nvidia modules were not loaded.=C2=A0 (but nvidia had > been loaded on the 1st boot). >=20 > So it *seems* like different modules are randomly not loaded by the > loader, at boot.=C2=A0=C2=A0 The ZFS config is: >=20 > config: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NAME=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 STATE=C2=A0=C2=A0=C2=A0=C2=A0 READ WRITE CKSUM > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tank=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0= =C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mirror-0=C2=A0 O= NLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0= =C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ada0= p2=C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2= =A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 da3p= 2=C2=A0=C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2= =A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mirror-1=C2=A0 O= NLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0= =C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ada1= p2=C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2= =A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 da0p= 2=C2=A0=C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2= =A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0 0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cache > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 da2s1d=C2=A0=C2=A0= =C2=A0 ONLINE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0=C2=A0= 0=C2=A0=C2=A0=C2=A0=C2=A0 0 >=20 > The data drives in the pool are all exactly like this: >=20 > =3D>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34=C2=A0 9767541101=C2=A0= ada0=C2=A0 GPT=C2=A0 (4.5T) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 - free -=C2=A0 (3.0K) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 40=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 204800=C2=A0=C2=A0=C2=A0=C2=A0 1=C2=A0 efi=C2=A0 (100M) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 204840=C2=A0 9763209216=C2=A0=C2=A0=C2=A0= =C2=A0 2=C2=A0 freebsd-zfs=C2=A0 (4.5T) > =C2=A0 9763414056=C2=A0=C2=A0=C2=A0=C2=A0 4096000=C2=A0=C2=A0=C2=A0=C2=A0= 3=C2=A0 freebsd-swap=C2=A0 (2.0G) > =C2=A0 9767510056=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 31079=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - free -=C2=A0 (15M) >=20 >=20 > There is about 1.44T used in the pool.=C2=A0 I have no idea > how ZFS mirrors work, but I'm wondering if somehow this > is a 2T problem, and there are issues with blocks on > difference sides of the mirror being across the 2T boundary. >=20 > Sorry to be so vague.. but this is the one machine I *don't* have > a serial console on, so I don't have good logs. >=20 > Drew >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" What makes you think it is related to ZFS? Are there any error messages when the nvidia module did not load? --=20 Allan Jude --JvzDtnG2I0n6zmhhiKQVAjGsOQ4Sncttc-- --GJGpJoZeIZ30FlmN3X4bEmNmIDvTY4DjL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJazDB3AAoJEBmVNT4SmAt+ymMQANMJJAfQ1M8nmX99hWOFIZI0 28ufaHxQ54tVuz7aOxYAb0ZappGmNIQ1WQbsoajPzlGMfs2NM3YSCGqOGaYWvYUn z313Umh2MeXRoApCykVN33RgI1nB5AfNRB+3H/xUAUiEO6acjqlEV7h7S//+YXDZ nqGTGNk8SS6Tgwuut61Sd25Tl+OSBothreed4CgQX/CtugOq4s4nb2vUvcn3skg4 uVPXG99GjMKby5ySBYVaaUeuyMuZnG+CxXUfWvsA+CsV0J5/UXxEUpM4AdHxWj98 gfw6WNJ35TBKt7zcfTsU+Hv2PAi+retOwkOMWBFhllyXlYidYFHu5uZz331MRg1A r8Bd1qEdjaHcZX2WrXHq6jAgl0eQJF+123qb9bf6zs9KjbT7flnO7gGeesqnE7pX iFi5nigDnEan0rCoeCkrbjvNlSnuE//DgKObdjPeJNhTpeKz+iL2sktk4FHLpNNo Kv4Zq2MQvHPyW3ozofBLEL5CR3/LNjnul2k6bX0MbvXv8Z7buYZl773ukob0AS4A CK+48I0rjD4mw2mEuJdwihhgK5g/chk45ZksdggFJmxRcxsV/8NEAmsm6VXCA0CL 0mkGIlHRMgAuEildDhePEMSSiwiPCkGlxbyTOAWLHjEYwf/N8BxxEkMHPrrmbDgC UF26atezGKruhx648P0h =bvCR -----END PGP SIGNATURE----- --GJGpJoZeIZ30FlmN3X4bEmNmIDvTY4DjL-- From owner-freebsd-current@freebsd.org Tue Apr 10 05:32:24 2018 Return-Path: Delivered-To: freebsd-current@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 0E2E3FA2001; Tue, 10 Apr 2018 05:32:24 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C8EC7ED3F; Tue, 10 Apr 2018 05:32:23 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f65.google.com with SMTP id v207-v6so9811927lfa.10; Mon, 09 Apr 2018 22:32:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=6KRrdrSy1hA/sVZKmDI4gfDh7/MsBVWBc20gVbAOczM=; b=nyk2/O+3Biv6OMA2C9A8I7Ea9r2uSZbwn4mulBOb6aZS84DhHw8s+RATfYNMj/Q5Bb CPNHCi9zdfkIbmORcwK09clCl2DruhTIPGDyvnXV/4W/SPKEUcMFvH/NY55NgKF5eNHH L/0Xa0rlk4kPIOXE6DiWvtBIXQbyM7DJVQM8Cnf6R+is7mq7ZxGb44fIOckiyKcemo1T 9cDWLGBr+ebyhC3Wvf71XROrAjo/v6Xgdj3X7q0B0P4YoGF1eNnQWm+l/YBaVhLl18ob 4tBsp4pL++jmJG/guU3irtCKa2F9tUpDWFV2UAyRyZz+X7dcvkEEy1rxtP6/g8sqyzJO bkuA== X-Gm-Message-State: ALQs6tCABQ0Vtjvh6otFb6OyNcy9R3J2+vh3oKVKyLtXB1obCeSuoXle naz8AEkKxN9rWhqx1qBFq6fqC4oq X-Google-Smtp-Source: AIpwx49LJkG5AU+7I3pvO6tMLkBC4D8Ooh0oS49+1/MUPGtE47WIRHFwv5EkxRjHyzHQKi/H7Cuo8w== X-Received: by 2002:a19:d9d4:: with SMTP id s81-v6mr1011002lfi.49.1523338336228; Mon, 09 Apr 2018 22:32:16 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id r25sm335527ljc.8.2018.04.09.22.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 22:32:15 -0700 (PDT) Subject: Re: "Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected? To: John Baldwin , freebsd-current@freebsd.org Cc: FreeBSD Hackers , freebsd-amd64@freebsd.org References: <621E84E6-D42C-4778-B028-AF3E1042CE7D@yahoo.com> <2644434.8Ktpdmy6i5@ralph.baldwin.cx> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <2a03f32b-34f9-7fcb-8d4d-94bd7a8d4290@FreeBSD.org> Date: Tue, 10 Apr 2018 08:32:13 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2644434.8Ktpdmy6i5@ralph.baldwin.cx> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 05:32:24 -0000 On 09/04/2018 22:37, John Baldwin wrote: > On Sunday, April 01, 2018 02:23:36 PM Mark Millard wrote: >> For: >> >> # uname -apKU >> FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT r331831M amd64 amd64 1200060 1200060 >> >> I get: >> >> . . . >> pci0: at device 7.3 (no driver attached) >> . . . >> intsmb0: at device 7.3 on pci0 >> intsmb0: Could not allocate I/O space >> device_attach: intsmb0 attach returned 6 >> >> on a Ryzen Threadripper 1950X where FreeBSD is being run under >> Hyper-V (on a Windows 10 Pro machine). Note the above. >> Is this expected? Did I misconfigure something in Hyper-V? > > That seems like an odd device to have for an AMD machine. Except that this is not an AMD machine but a Hyper-V? (And even if that were a physical AMD machine the driver would not be odd for it as the driver supports AMD chipsets that provide SMBus controllers compatible with PIIX4). Mark provided the following information in his post: >> # pciconf -l -v 0:0:7:3 >> none0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82371AB/EB/MB PIIX4 ACPI' >> class = bridge My guess is that Hyper-V's emulation of PIIX4 is not complete or correct with respect to the SMBus controller. And, as I am sure that Hyper-V does not emulate any SMBus slaves anyway, it would be completely useless. > I suspect that this has never > worked and the module started auto-loading due to devmatch. This must be true. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Apr 10 12:27:59 2018 Return-Path: Delivered-To: freebsd-current@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 11634F98759 for ; Tue, 10 Apr 2018 12:27:59 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (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 9F1917D25B; Tue, 10 Apr 2018 12:27:58 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.3] (c-73-216-227-39.hsd1.va.comcast.net [73.216.227.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 8664127000A7; Tue, 10 Apr 2018 08:27:57 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 8664127000A7 Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1523363277; bh=mcusF5JafEU6qRtouVtsmwiafH5uCkM52/G6WIsAgrs=; h=Subject:To:From:Date:From; b=e/z9zk3yEULuJTVGPgqz7qHAmxboYBH8hwCO/CqRWk9PUT2FyZAwpyNUS7352Jcub oycYEeDBQ9bsXrKgkSoW0f7EOf/pyCbrpoNE+dQgakN+aVgS5H050VPw7m31QMl+0H eilyxyX1nwF+xfd9PmgxfZ0UPaeT9dHX/bHG3unn3MNmb9Hobn4OaH3WeQtDa1HNED ItozY3ulGImgPG1bC3YNXsls9A//GNc28OOQCoPbSfy+rGWMQg2nzzBRmRciY0ejVg YiFwsSnMmgogtLTcTKoq4BsD/FthzXfSziq0W1wz28AXDHNsBZlcImnD+4y0CFPQnz JO5UPsEu6v1xQ== Subject: Re: Re: Odd ZFS boot module issue on r332158 To: Allan Jude , freebsd-current@freebsd.org References: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> From: Andrew Gallatin Message-ID: <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> Date: Tue, 10 Apr 2018 08:27:56 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 12:27:59 -0000 On 04/09/18 23:33, Allan Jude wrote: > On 2018-04-09 19:11, Andrew Gallatin wrote: >> I updated my main amd64 workstation to r332158 from something much >> earlier (mid Jan). >> >> Upon reboot, all seemed well.  However, I later realized that the vmm.ko >> module was not loaded at boot, because bhyve PCI passthru did not >> work.  My loader.conf looks like (I'm passing a USB interface through): >> >> ####### >> vmm_load="YES" >> opensolaris_load="YES" >> zfs_load="YES" >> nvidia_load="YES" >> nvidia-modeset_load="YES" >> >> # Tune ZFS Arc Size - Change to adjust memory used for disk cache >> vfs.zfs.arc_max="4096M" >> hint.xhci.2.disabled="1" >> pptdevs="8/0/0" >> hw.dmar.enable="0" >> cuse_load="YES" >> ####### >> >> The problem seems "random".  I rebooted into single-user to >> see if somehow, vmm.ko was loaded at boot and something >> was unloading vmm.ko.  However, on this boot it was loaded.  I then >> ^D'ed and continued to multi-user, where X failed to start because >> this time, the nvidia modules were not loaded.  (but nvidia had >> been loaded on the 1st boot). >> >> So it *seems* like different modules are randomly not loaded by the >> loader, at boot.   The ZFS config is: >> >> config: >> >>         NAME        STATE     READ WRITE CKSUM >>         tank        ONLINE       0     0     0 >>           mirror-0  ONLINE       0     0     0 >>             ada0p2  ONLINE       0     0     0 >>             da3p2   ONLINE       0     0     0 >>           mirror-1  ONLINE       0     0     0 >>             ada1p2  ONLINE       0     0     0 >>             da0p2   ONLINE       0     0     0 >>         cache >>           da2s1d    ONLINE       0     0     0 >> >> The data drives in the pool are all exactly like this: >> >> =>        34  9767541101  ada0  GPT  (4.5T) >>           34           6        - free -  (3.0K) >>           40      204800     1  efi  (100M) >>       204840  9763209216     2  freebsd-zfs  (4.5T) >>   9763414056     4096000     3  freebsd-swap  (2.0G) >>   9767510056       31079        - free -  (15M) >> >> >> There is about 1.44T used in the pool.  I have no idea >> how ZFS mirrors work, but I'm wondering if somehow this >> is a 2T problem, and there are issues with blocks on >> difference sides of the mirror being across the 2T boundary. >> >> Sorry to be so vague.. but this is the one machine I *don't* have >> a serial console on, so I don't have good logs. >> >> Drew >> >> _______________________________________________ >> 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" > > What makes you think it is related to ZFS? > > Are there any error messages when the nvidia module did not load? > I think it is related to ZFS simply because I'm booting from ZFS and it is not working reliably. Our systems at work, booting from UFS on roughly the same svn rev seem to still load modules reliably from the loader. I know there has been a lot of work on the loader recently, and in a UEFE + UFS context, I've seen it fail to boot the right partition, etc. However, I've never seen it fail to load just some modules. The one difference between what I run at home and what we run at work is ZFS vs UFS. Given that it is a glass console, I have no confidence in my ability to log error messages. However, I could have sworn that I saw something like "io error" when it failed to load vmm.ko (I actually rebooted several times when I was diagnosing it.. at first I thought xhci was holding on to the pass-thru device) I vaguely remembered reading something about this recently. I just tracked it down to the "ZFS i/o error in recent 12.0" thread from last month, and this message in particular: https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068890.html I'm booting via UEFI into a ZFS system with a FS that extends across 2TB.. Is there something like tools/diag/prtblknos for ZFS? Drew From owner-freebsd-current@freebsd.org Tue Apr 10 12:46:34 2018 Return-Path: Delivered-To: freebsd-current@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 43646F99AFA for ; Tue, 10 Apr 2018 12:46:34 +0000 (UTC) (envelope-from srs0=rjtr=g7=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D573980628 for ; Tue, 10 Apr 2018 12:46:33 +0000 (UTC) (envelope-from srs0=rjtr=g7=sigsegv.be=kristof@codepro.be) Received: from [172.20.10.3] (unknown [188.188.16.6]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 5DC503FA6F; Tue, 10 Apr 2018 14:46:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1523364391; bh=RFylzuCXMjEYjI/Zx8+ZHDtqJR+RkD21sV/OZpnIvmg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=XtCiuH37x3L3otca9xubpOGrHFt4SYn6trf1MVxyuiE8xgmxYBanPlBVelaSFYihi a9tIjIMZL48pZwMntTjUAr7s0fNlzv3+r6oBx/QT7v4exQDP75rAG6HBoD6vyLOfMw i7mFZS5muQOXdZEHU2gYzhU2nYaeEiK/lel1bLAo= From: "Kristof Provost" To: "Vladimir Zakharov" Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found Date: Tue, 10 Apr 2018 14:46:53 +0200 X-Mailer: MailMate (2.0BETAr6108) Message-ID: <33EDB48E-A330-4F5E-9328-AE3EE1E66B95@sigsegv.be> In-Reply-To: <20180409111011.5gqhtqtuw6xsg3wq@vzakharov> References: <20180409085050.mjy6itqti6spzbdx@vzakharov> <20180409111011.5gqhtqtuw6xsg3wq@vzakharov> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 12:46:34 -0000 On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: > On Mon, Apr 09, 2018, Kristof Provost wrote: >> On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: >> >> For several days buildworld fails for me with the following >> error. Cleaning >> and >> rebuilding didn't help. >> >> ===> tests/sys/netpfil/pf/ioctl (all) >> --- validation --- >> (cd /usr/src/tests/sys/netpfil/pf/ioctl && >> DEPENDFILE=.depend.validation >> NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile >> _RECURSING_PROGS=t PROG=validation ) >> Building >> /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ >> validation.o >> --- validation.o --- >> In file included from >> /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: >> /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: >> fatal >> error: 'netpfil/pf/pf.h' file not found >> #include >> ^~~~~~~~~~~~~~~~~ It should be fully fixed as of r332358. Thanks for the report. Regards, Kristof From owner-freebsd-current@freebsd.org Tue Apr 10 15:25:56 2018 Return-Path: Delivered-To: freebsd-current@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 367F0F809A6 for ; Tue, 10 Apr 2018 15:25:56 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 627EB683F4; Tue, 10 Apr 2018 15:25:55 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f48.google.com with SMTP id x70-v6so12260283lfa.0; Tue, 10 Apr 2018 08:25:55 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CJXKGiJcT9k4yO1vpMocTlcy3ptEI/tSaoGJnksImJ0=; b=bgrBJHvPJPYY1lwwmyWJ4OpyggcxCE/NzcXU0hXy4NZZpqtqIc4/bl/d+cnKaCfrxV mZK4FFKeogsq/N88eWNutNf/lOy8SsratT4HOhkJCyvHt1Bv6u2IRnQQAJcclD306Gjm Ae0AF0xaY5SP9tiIHI5wCJM6/RZz1CgH6RG2l8b2Xs0uzuobUXyva0ve5R+dITWnQbcS BLUNFDEcfphCtHO+7ZMOUcro4G3cRkm87swI4irAFCFvgJMT9px8tXpwUePOvoLPmiSu xpfOTU6itdIxqWDJ1dmjWyqRzJC3dLOr78e9o5ZUnCTFZxWKKNlHovUzG+u5d7tqcL9S HHpg== X-Gm-Message-State: ALQs6tAGXYH9+f+uOqQAWTF6eS9nRp3fJqB59yWjSzuTdV4Dl/ZYuLt8 Oxoidh34O286Q21AaN3DE1h92ZtL X-Google-Smtp-Source: AIpwx4/SYf91s4Kl4FYtC46rujr2z8lOQLamO8ME9fORgp7xGlElzFUx4gjDUOs0Busg1lpYUPyVpw== X-Received: by 10.46.25.134 with SMTP id 6mr562673ljz.14.1523373947451; Tue, 10 Apr 2018 08:25:47 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id c64-v6sm616515lfc.67.2018.04.10.08.25.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 08:25:46 -0700 (PDT) Subject: Re: Odd ZFS boot module issue on r332158 To: Andrew Gallatin , Allan Jude , freebsd-current@freebsd.org References: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <00fd72d0-cb41-eaf7-347e-6f3423bb6008@FreeBSD.org> Date: Tue, 10 Apr 2018 18:25:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 15:25:56 -0000 On 10/04/2018 15:27, Andrew Gallatin wrote: > Is there something like tools/diag/prtblknos for ZFS? zdb. It has a manual page, but in the case like this you typically want to run zdb -d[d*] Add d-s until you get all the information you want. It looks like five d-s is needed to get individual blocks reported. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Apr 10 15:54:25 2018 Return-Path: Delivered-To: freebsd-current@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 411F8F82A0B for ; Tue, 10 Apr 2018 15:54:25 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 DAE7C7071E; Tue, 10 Apr 2018 15:54:24 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P6Z0060019THO00@st13p35im-asmtp002.me.com>; Tue, 10 Apr 2018 14:54:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1523372057; bh=XXgXxf9eaLrZguholz1KLLhDYAhErN7uJktGjRKSoVM=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=kxSEaLzvN4xMQHcNjJyaSrIoLZ5dSBAJYzkJqHaqQPZ5g7u8eGP/TCu1VaLUrdunR /AqyaO/F2TnpsYBY06RURGma29ZyDfraKI1y2uoGBWy74trGbg9l7hFMtnDMQPE9ra CxJNf9Fdr+GoNE4Ci7Mm9Jt5MiMNuRufpDvUcVigKUX6AdCYd4NhtS6A90PmjngqgZ AEEVawTUvY2gDVt3m+N8ohsU0Tmo7ylX3vFjqSTW8LjupPOWSQWK+Tyd6lNq4vzuRU FIB0B2VHIYpxUpm7BGgAITZcjna0+iRyZ7Upy2QiiT5czXuT7MXRnGwSZDUABgwHWD BPQvXoZrFxj7Q== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P6Z0052V5EB1B30@st13p35im-asmtp002.me.com>; Tue, 10 Apr 2018 14:54:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-04-10_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=27 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1804100146 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Odd ZFS boot module issue on r332158 From: Toomas Soome In-reply-to: <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> Date: Tue, 10 Apr 2018 17:54:10 +0300 Cc: Allan Jude , freebsd-current@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <3DC3DAEB-A627-4488-873E-0AB6EA124D3F@me.com> References: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> To: Andrew Gallatin X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 15:54:25 -0000 > On 10 Apr 2018, at 15:27, Andrew Gallatin = wrote: >=20 > On 04/09/18 23:33, Allan Jude wrote: >> On 2018-04-09 19:11, Andrew Gallatin wrote: >>> I updated my main amd64 workstation to r332158 from something much >>> earlier (mid Jan). >>>=20 >>> Upon reboot, all seemed well. However, I later realized that the = vmm.ko >>> module was not loaded at boot, because bhyve PCI passthru did not >>> work. My loader.conf looks like (I'm passing a USB interface = through): >>>=20 >>> ####### >>> vmm_load=3D"YES" >>> opensolaris_load=3D"YES" >>> zfs_load=3D"YES" >>> nvidia_load=3D"YES" >>> nvidia-modeset_load=3D"YES" >>>=20 >>> # Tune ZFS Arc Size - Change to adjust memory used for disk cache >>> vfs.zfs.arc_max=3D"4096M" >>> hint.xhci.2.disabled=3D"1" >>> pptdevs=3D"8/0/0" >>> hw.dmar.enable=3D"0" >>> cuse_load=3D"YES" >>> ####### >>>=20 >>> The problem seems "random". I rebooted into single-user to >>> see if somehow, vmm.ko was loaded at boot and something >>> was unloading vmm.ko. However, on this boot it was loaded. I then >>> ^D'ed and continued to multi-user, where X failed to start because >>> this time, the nvidia modules were not loaded. (but nvidia had >>> been loaded on the 1st boot). >>>=20 >>> So it *seems* like different modules are randomly not loaded by the >>> loader, at boot. The ZFS config is: >>>=20 >>> config: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> tank ONLINE 0 0 0 >>> mirror-0 ONLINE 0 0 0 >>> ada0p2 ONLINE 0 0 0 >>> da3p2 ONLINE 0 0 0 >>> mirror-1 ONLINE 0 0 0 >>> ada1p2 ONLINE 0 0 0 >>> da0p2 ONLINE 0 0 0 >>> cache >>> da2s1d ONLINE 0 0 0 >>>=20 >>> The data drives in the pool are all exactly like this: >>>=20 >>> =3D> 34 9767541101 ada0 GPT (4.5T) >>> 34 6 - free - (3.0K) >>> 40 204800 1 efi (100M) >>> 204840 9763209216 2 freebsd-zfs (4.5T) >>> 9763414056 4096000 3 freebsd-swap (2.0G) >>> 9767510056 31079 - free - (15M) >>>=20 >>>=20 >>> There is about 1.44T used in the pool. I have no idea >>> how ZFS mirrors work, but I'm wondering if somehow this >>> is a 2T problem, and there are issues with blocks on >>> difference sides of the mirror being across the 2T boundary. >>>=20 >>> Sorry to be so vague.. but this is the one machine I *don't* have >>> a serial console on, so I don't have good logs. >>>=20 >>> Drew >>>=20 >>> _______________________________________________ >>> 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" >> What makes you think it is related to ZFS? >> Are there any error messages when the nvidia module did not load? >=20 > I think it is related to ZFS simply because I'm booting from ZFS and > it is not working reliably. Our systems at work, booting from UFS on > roughly the same svn rev seem to still load modules reliably from > the loader. I know there has been a lot of work on the loader > recently, and in a UEFE + UFS context, I've seen it fail to boot > the right partition, etc. However, I've never seen it fail to load > just some modules. The one difference between what I run at home > and what we run at work is ZFS vs UFS. >=20 > Given that it is a glass console, I have no confidence in my ability > to log error messages. However, I could have sworn that I saw > something like "io error" when it failed to load vmm.ko > (I actually rebooted several times when I was diagnosing it.. > at first I thought xhci was holding on to the pass-thru device) >=20 > I vaguely remembered reading something about this recently. > I just tracked it down to the "ZFS i/o error in recent 12.0" > thread from last month, and this message in particular: >=20 > = https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068890.html= >=20 > I'm booting via UEFI into a ZFS system with a FS that > extends across 2TB.. >=20 > Is there something like tools/diag/prtblknos for ZFS? >=20 run zpool scrub first, however, if you were able to load that module = manually from OS, there is no reason to suspect the zfs corruption. But if you really are getting IO errors, I would actually suspect that = the firmware is is buggy and can not really read past 2TB, so the = obvious second suggestion is to check for firmware update. The ZFS = reader code does try all block copies before giving up on the block, so = the third option you can test is: 1. reboot 2. press esc when the boot menu is up to get to OK prompt 3. enter: start this would load the configured files and you will get the error = messages. Also once you have kernel loaded, you can try to load modules = manually with load command. If still nothing, the only way to ensure your data is below 2TB line is = to create separate partition for boot pool or use smaller disks for OS. rgds, toomas= From owner-freebsd-current@freebsd.org Tue Apr 10 19:48:40 2018 Return-Path: Delivered-To: freebsd-current@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 E16DCF93E99 for ; Tue, 10 Apr 2018 19:48:39 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (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 86E4A6B924; Tue, 10 Apr 2018 19:48:39 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.3] (c-73-216-227-39.hsd1.va.comcast.net [73.216.227.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id AA4252700318; Tue, 10 Apr 2018 15:48:38 -0400 (EDT) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu AA4252700318 Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1523389718; bh=E/3KQF18bKbDI/E8EvjEvf441afuWThs9TMn5fUJUXE=; h=Subject:To:From:Date:From; b=PMXKiD/K44nSsQGh2dQYSiXxKtWYgjwBoMIyY4ebTcKqm2Ln3F/K9Lv3untbk6WBv ZyKI2zyW9/tHGSfkeCFmOWmuCTzgV26SkLbQr2xaiifJFxtdb2rtdxNL+gvUY+xOQy lVJjuZwsCD6mAK0UffvpeAimA1xurOLsTe9JHDlSoc48Pr6Ss5YjNehglI8xwwveE5 XC6E51CDGby/ZXD2txbAUm+CrqhQZBqCHNROXl+chAtQ7pfGuk6cGclzhk8Pfoqi1f k4iBd+CpOEOYClzqbBiZnQAx4xdLHV9HHlo0bVJlEnIrkq5uA8r0rccs1/yd4YcUoU vADJNcnm3ocwQ== Subject: Re: Odd ZFS boot module issue on r332158 To: Andriy Gapon , Allan Jude , freebsd-current@freebsd.org References: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> <00fd72d0-cb41-eaf7-347e-6f3423bb6008@FreeBSD.org> From: Andrew Gallatin Message-ID: Date: Tue, 10 Apr 2018 15:48:38 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <00fd72d0-cb41-eaf7-347e-6f3423bb6008@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 19:48:40 -0000 On 04/10/18 11:25, Andriy Gapon wrote: > On 10/04/2018 15:27, Andrew Gallatin wrote: >> Is there something like tools/diag/prtblknos for ZFS? > > zdb. > > It has a manual page, but in the case like this you typically want to run > zdb -d[d*] > Add d-s until you get all the information you want. > > It looks like five d-s is needed to get individual blocks reported. > Thanks for the instructions! How do I interpret this output: <3:45pm>viserion/gallatin:~>ls -li /boot//kernel/vmm.ko 231484 -r-xr-xr-x 1 root wheel 371168 Apr 7 15:05 /boot//kernel/vmm.ko* <3:46pm>viserion/gallatin:src>sudo zdb -ddddd tank/ROOT/12.0-CURRENT-20180407.104009 231484 Dataset tank/ROOT/12.0-CURRENT-20180407.104009 [ZPL], ID 260, cr_txg 16768182, 19.9G, 292309 objects, rootbp DVA[0]=<0:4565c5a5000:1000> DVA[1]=<1:1f1ba52b000:1000> [L0 DMU objset] fletcher4 uncompressed LE contiguous unique double size=800L/800P birth=16821145L/16821145P fill=292309 cksum=f1c0930f9:12c49ea8e701:e036d6305e6ca:79eca698e0476d9 Object lvl iblk dblk dsize lsize %full type 231484 2 128K 128K 392K 384K 100.00 ZFS plain file 168 bonus System attributes dnode flags: USED_BYTES USERUSED_ACCOUNTED dnode maxblkid: 2 path /boot/kernel/vmm.ko uid 0 gid 0 atime Sat Apr 7 17:06:06 2018 mtime Sat Apr 7 15:05:48 2018 ctime Sat Apr 7 15:05:48 2018 crtime Sat Apr 7 14:08:21 2018 gen 16768195 mode 100555 size 371168 parent 229378 links 1 pflags 40800000104 Indirect blocks: 0 L1 1:1f01016c000:1000 20000L/1000P F=3 B=16769122/16769122 0 L0 1:1f00f9e3000:20000 20000L/20000P F=1 B=16769122/16769122 20000 L0 1:1f00fa03000:20000 20000L/20000P F=1 B=16769122/16769122 40000 L0 1:1f00fa23000:20000 20000L/20000P F=1 B=16769122/16769122 segment [0000000000000000, 0000000000060000) size 384K Thanks, Drew From owner-freebsd-current@freebsd.org Tue Apr 10 20:59:20 2018 Return-Path: Delivered-To: freebsd-current@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 832C8F98C99 for ; Tue, 10 Apr 2018 20:59:20 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5EB77BE8C; Tue, 10 Apr 2018 20:59:19 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id b189-v6so3642220lfe.2; Tue, 10 Apr 2018 13:59:19 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=QIVxOkMTGIelijBlXPMRShMf60/xtfokPglz87ONZ3k=; b=cBNcHeJ9gaSezvxhCnc5YTyOu5Enc1zPD+DTzFES98aXWR5t2uRpZyW4G//TjbYDYx GpXKwuFcWcpz3D7w90MZxaaUk6uLlzD4PnuuYWt8w4BbCJ8kzQqp4RIKptfvAmPYpRYv BUUhkSKnH/wYw8ma/cXcSWN5UtgdTISoRy11gA25LGOuqqbveSf71XsZ3r85ExypQ3mL WHzyUZqWzKBbcd2pSHvrX3qAGr/kACju4ilEw8QJvGzfla6jnEJz+KliO4zWm9LdpiKm +050F/dZG1DAVBkLPAgiPU9orm8JA6L240BBOxkUEWoQf/CzMo+GHR4HMBed6NDEoDKW 0Rlw== X-Gm-Message-State: ALQs6tDNKExAqES8T/V9QUvr6MCJ9HADaWI6yIQN/SBQRTL1QU9OBtUR yOXuPtGt5DSkRo84hfSXkMLz2lMr X-Google-Smtp-Source: AIpwx4+67F4PjLDW1KGUpylbA+duir/sL3D8/FgVpM00SDe22ihnfJEv40GNxDgoFxJ337b4gOi4/Q== X-Received: by 10.46.145.4 with SMTP id m4mr1136096ljg.73.1523393471445; Tue, 10 Apr 2018 13:51:11 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id f133-v6sm727909lfg.28.2018.04.10.13.51.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 13:51:10 -0700 (PDT) Subject: Re: Odd ZFS boot module issue on r332158 To: Andrew Gallatin , Allan Jude , freebsd-current@FreeBSD.org References: <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> <00fd72d0-cb41-eaf7-347e-6f3423bb6008@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Tue, 10 Apr 2018 23:51:09 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 20:59:20 -0000 On 10/04/2018 22:48, Andrew Gallatin wrote: > On 04/10/18 11:25, Andriy Gapon wrote: >> On 10/04/2018 15:27, Andrew Gallatin wrote: >>> Is there something like tools/diag/prtblknos for ZFS? >> >> zdb. >> >> It has a manual page, but in the case like this you typically want to run >> zdb -d[d*] >> Add d-s until you get all the information you want. >> >> It looks like five d-s is needed to get individual blocks reported. >> > > Thanks for the instructions! > > How do I interpret this output: [snip] >                0 L1  1:1f01016c000:1000 20000L/1000P F=3 B=16769122/16769122 >                0  L0 1:1f00f9e3000:20000 20000L/20000P F=1 B=16769122/16769122 >            20000  L0 1:1f00fa03000:20000 20000L/20000P F=1 B=16769122/16769122 >            40000  L0 1:1f00fa23000:20000 20000L/20000P F=1 B=16769122/16769122 The first number is an offset within the file (hex); Lx is a block level where L0 is a data block, L1 is an indirect block just above data blocks, etc; x:y:z is a (top-level) vdev number, a block offset on disk (hex) and a block size on disk(hex); the rest is not as important. The quoted offsets appear to be just below 2TB. -- Andriy Gapon From owner-freebsd-current@freebsd.org Tue Apr 10 23:59:58 2018 Return-Path: Delivered-To: freebsd-current@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 E75A5F8038F for ; Tue, 10 Apr 2018 23:59:57 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45B1985914 for ; Tue, 10 Apr 2018 23:59:56 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3ANxaOT023587; Tue, 10 Apr 2018 16:59:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : content-transfer-encoding : date : message-id; s=PPS1017; bh=FrvN+t8xZ/pLaxRE77jaHFdL8x7RPY4Xh38WZGP1REs=; b=hgKLppSKoUm6BvrAym4dVOxzIS5Q+dY2t9xn9e3fzfNyO8bqdK8cMUyiLMZTmiEYOfbJ 7PzmlBa826yz6Kh4PAa2zo5fM4RlwUmaXb/wOgQaSDBsresiXJ+xgB1ZgE3bXyazv+cp WDiOW/SXX+AfNEdxyTWHhx27uLl3q3eUknD/8PcUvCghdtUOXfciQnKelLbH+MGsJKAm 9282YnZEENy3zNRBXY1AzEtaEVvG/waXem42pvxIVnVAtUaffe7LDrfFR2toJZfqHe83 9JTdyGqn+oNRK0wuHq2xh6H2iZLnuFOk7Y9DzqAKVdCAdPJseQEEMgoQROKWAyMaHCFn bg== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0a-00273201.pphosted.com with ESMTP id 2h906m909m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Apr 2018 16:59:55 -0700 Received: from SN4PR0501CA0061.namprd05.prod.outlook.com (2603:10b6:803:41::38) by BN3PR05MB2434.namprd05.prod.outlook.com (2a01:111:e400:7bb4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.3; Tue, 10 Apr 2018 23:59:47 +0000 Received: from BY2NAM05FT019.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by SN4PR0501CA0061.outlook.office365.com (2603:10b6:803:41::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.675.4 via Frontend Transport; Tue, 10 Apr 2018 23:59:46 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT019.mail.protection.outlook.com (10.152.100.156) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.653.8 via Frontend Transport; Tue, 10 Apr 2018 23:59:46 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Apr 2018 16:56:41 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w3ANue57007195; Tue, 10 Apr 2018 16:56:40 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id DB79C5532B; Tue, 10 Apr 2018 16:56:37 -0700 (PDT) To: "Rodney W. Grimes" CC: , Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <201804081900.w38J0q23014767@pdx.rh.CN85.dnsmgr.net> References: <201804081900.w38J0q23014767@pdx.rh.CN85.dnsmgr.net> Comments: In-reply-to: "Rodney W. Grimes" message dated "Sun, 08 Apr 2018 12:00:52 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <436.1523404597.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2018 16:56:37 -0700 Message-ID: <3030.1523404597@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39380400002)(376002)(346002)(39860400002)(396003)(2980300002)(199004)(189003)(7126003)(97876018)(446003)(11346002)(9686003)(97736004)(69596002)(23726003)(305945005)(53936002)(6246003)(53416004)(76176011)(107886003)(476003)(486006)(76506005)(105596002)(356003)(478600001)(336012)(46406003)(55016002)(6266002)(126002)(7696005)(77096007)(5660300001)(47776003)(2906002)(4326008)(50466002)(86362001)(186003)(26005)(316002)(8746002)(68736007)(81156014)(81166006)(8936002)(8676002)(2810700001)(50226002)(54906003)(6916009)(106466001)(117636001)(97756001)(229853002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2434; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT019; 1:fTrGHBTdJN04gUlkKwuZ1f1OepvQIQPDbOKHC1sFV8wALyCUr2bg/WCh1y8F4w3uJVluSvrJkni4n5f6SqyJh99El01kQmELM3m4q1TuEL98pKpyg+tegdFdVNCx+HPe X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060); SRVR:BN3PR05MB2434; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2434; 3:b4BVy0J0xwIryAUKDyg0cxosc7VzubvRfmZH1m0yZkJPUo9rwmHy6GHn8qGAzg9U5tmm+wdW5OZnYxrbCwdFoxl5ew8vM6bDoJz75/xYidsBoafssrgIkVuRtm+vtHnYtS9MiTx5ydjrB0g74qOoHTVzKocl1hpLOUtmU/bfHpD/hI1dz0ZB2UWFb+QRGnFA1TRDoSXs8jdfvrfn3hPgMk+URRdSYiqwl4AaD3vmwl7zgH0sGVegI5bhoIbK47jPirQ1K8lnwOiVMCMv1HcwglUl+Gkt/heITKruZWYjpzmz97gk+laWIRc6oJY4akFZaBy7B1UR58u7uTT3J0iL14UPOrzNaf/dC3rIhJxutsc=; 25:eVxWnfsk8aAAT4Lrr0GRqyYdPm3oHauTIateVkq60LjIgAaVho6pmReJ42/DV7aKyqWsI28beAKeqitBy4eaW6FENywXP5O7wDFEggKVwzlhJdLXztzmatqxOo5Sk9BRqQkAtMmRBGGfLBZZAh8WJQ+S9HnoAzwLbZBtmtK3M7IDPbAW1lulSHFPvyQNMtENKu/YSMJSbBOE7nmIHwG5n7ljJxBdm0cHNhkioatjqGCwPiDS+reqbbuHlQuGi9vxbxvMUqjQmDRer68sfAzCHOuMfUzuCKh3cfSTQX4jmfpL2zhgJ/4HYhmLydlVyFMUYKvPexn68l62VpqFqsSpLA== X-MS-TrafficTypeDiagnostic: BN3PR05MB2434: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2434; 31:3aYK0R8uXuGtHtoqxoAl5Ub2//iSj8aS/qnVkKCBPSo+SgKr3yMUVZsqhSnvmzR2Au6ut+QvhtOwSIyork8/4AMRWyRt7AHJ7mIVAzF0aF17e/xQmAjJPvB/VCGs94MSABgWaRxDoHVQ9nCccQ2FqFgDChtJ1WGlgEExggul2bZIi92HZDYWmIqfVCqjmX0GF+m/E3alpEpQwukJlhbOYFCIb++24SH7zKrCdK2altk=; 20:fspuYU31CCQcdRLsv0Ydlfzo5tjs7Vw+S6iuzMr8p6qgndizfn1rN/vIGexEI5lBeFTkJNxI4VbP4H2vW41G/RcBML5MI+feGtPsskIYwMir3N0q76EFTRKFjSVq5pPowiox6oJuMXTELc1RRv77tMPv7u7OufgktYo8GhC31JG8S30Dd21Gj6CXkKD+cVEuNX1sgUCuWPQ5boLlyroT8nLJNGID1bKrRrFi+SSWGAbMM5BwajjBbslxqAHMyG29zblkMwv2S5L/ubK+BIh+GNukpBolJ+2v8lZeNlLsi03y9M+cpU9t/UhAdvfyXLpTnxAiZ9BLVJnlCgyDBHXXTY9uY1m6Wdb067I5RVeBjSmDmJEjhOAZi4aEfQZPcU4+PeB8dDj/K4W81uMZsH4o3LqfXQeky4Adn7zxt78ksMFHhwuG4Uo/uscajcMXpHtknkWnhZAdo8MSfNhyDN550A+dV+mU6jKWh3cVnpRdLu/Efb0s0rCwVUHfrTQU3U2u X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501327)(52105095)(93006095)(93003095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN3PR05MB2434; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2434; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2434; 4:fb+sCM7fEm1MkH0l7OweXJfnOV6ZQva0ktP3EbAwg9L1WSlDuzLY5Qik9eoCyOWsDprASFoqvEi9iafjJxhIw0LPwIMGRX6K7pWVqsCMwaPq61QCxucVZHhJJw+/PN02bffj9774iZUNhwPOv7glacKWAs4Rf8QSkLTe4cIifYJFBD79fXCdl3kygBMKy8fWVwTVdegqyU152LgkhQqyd68enlLHGX/0+19lDSu/FS8ML4P7iL3Rf9UayWxdHOXNF4ewxUZ5eeMQR/Qw2DKKHg== X-Forefront-PRVS: 0638FD5066 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2434; 23:3hXPYvPM2xoldDol++tUoq4WYvfkIU2SlUKCTC1dq?= =?us-ascii?Q?0AJ7aAu9qCF2B1bQXZn5mchDU4ybSlJbxy0HFOAIY+KiczK9c0/kpifs3Mg2?= =?us-ascii?Q?yQEs/b9PnUoEQmmK6Q00hi170klU5S/ppW6QzF5JIFgWONoSLEORAyan62nN?= =?us-ascii?Q?S9soCN6MjpU1Ir191DqQ+DpDGDNIjQ3tNCtumdxCWQkoLoLdokVdPeXCgcgx?= =?us-ascii?Q?daYN1wEzUcrDZwoJLvAhc6OMa3725Rgr2dt1Q8LyUmMlsjWd3OKt/BNb6dN2?= =?us-ascii?Q?qbjELqvw9cHf4gRwZ6/BY6jsuB/XnMPgVElC+0goEXxRxElDtgeswuTiFe4z?= =?us-ascii?Q?Xdd09eYQmLU1hUYqSX66hNyuq8LbDZuKhpVPLDnlE9zfsiPwNJYVvQDo7PeB?= =?us-ascii?Q?wv0dX5Wnw9YXcyjdNCbv+JeUctg1EgibV+cqk9ONb+FBLf5vF8ogM19cpR9T?= =?us-ascii?Q?yeukjd7Ilf02Vq9I4hKyvUbYc+FaQNrISd4SKJe/vpjZko7IQabnuiYvTMB7?= =?us-ascii?Q?aihouN0mMZhZfrja6K/ziPu8Ml0dBOiNNM234dYN7vkBKgCLzMOeLuPGlv74?= =?us-ascii?Q?t3IUPGFQDfpX3/YXFZUkhic1jAjUwQA3DM6bXaeLq/+QFn5fX7TkbCJCXMsq?= =?us-ascii?Q?DuBnn+++nYF8QP0R0XRt6BNHCecSMMEk2fDFETGAdQd7ejtufWXA8s3OevSj?= =?us-ascii?Q?TOzb3EFEQnP00gUwo9d8YCTjjewI7bb5Yijk/u4EEurZD8K78WcIVlNqe6A+?= =?us-ascii?Q?XAxbYfRxVg0fdQQq9h4i+O+cPF4Db3QS8FYbFxpKiX9JM5BwiiLV2ddXQnyW?= =?us-ascii?Q?gjmyUmIMDpMgFuC7XU20CMVb/4tHMzTfOKOVd25N0j4XTbkzp8/cnOHTNGvn?= =?us-ascii?Q?AnZrCMi7w8n/0/oDh2o2FPx2hSOpCbOFXAkIFUnC+HmmrE2D3jUmWBYjHRyn?= =?us-ascii?Q?98k4Vq6KQsdwlF9FjBG3tMZiy64s3Oj8Yf0Y2IqzAQUrovEK8/GAC+i2TCpI?= =?us-ascii?Q?GrDXGw/RUesCnJymJSlWCaogIZapCREg4geVX8Y+0MLc7vIgh5jXsgtMXWuL?= =?us-ascii?Q?QzuGrMbUHgIe3Fflq6qUmltc9dB4E+B1IdLIqGGOrWVXUjywOsMKtxdozyeX?= =?us-ascii?Q?zaHbrGvqyC873pMH2XOgld65zp0upobeWNFRrF7wM2kBAVtHCNSXD2wUgxuj?= =?us-ascii?Q?/Q1DhTfti0Zgn0ByoRPeBvIlyOSMk/nLt72Gvkzg7t4wqZaWAXiDG/f5aQAj?= =?us-ascii?Q?NFFFnYu33uDbFgkn1kNIookhNGI5umrSbYj/9HDUQv19Aq1n1xK7u7K84oBX?= =?us-ascii?Q?aCH1Ytf08fgzPU6tsAZk4c=3D?= X-Microsoft-Antispam-Message-Info: /AeeBA8bG7j6zoM3XjHgebPTjMzIsTKwjMjKIIKqiZ2CP0FSJ14oJoZ492l4y4DCiiYPtIM3y/dt7z8eyuRKVI3B/6ozJoUW+wPT0EUQfIld90vNvyXuxT/CV8KaMDYk6gvEqtIvl6F1tLKeHzTYsCiGJnG9f172gZcAFO0QRBGJ32sT01yuGfXlP12VCoeZ X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2434; 6:a9O2Q6BaQO+gMNIArJbsqTPzENMK4sFxTG+iv4UxO6IkIUVxUNLWF15rbMBDa/uQL/tpW58BM5C5hgQZx/yZw1LbHLZPykHmZSt8W+ERPgXtGU7B823teSsnMbfENwpAgLruzQxwr7p3zaEsC6W4B1VRzHKkvaPSNymt+ufOxaIGIGCXWvs+5is56b6b/UUI6935W7CG/wvJ1pF8+iELnxBEFh8kUI6Ip0DgmE/3E1VGKoAdJn3L8EX8j01/yYqpXBosdb6VrNBVBnXj+5b6BcRSMyOz18IO/jrIErLZ6AQ9sKwP48nluuJ/xVs1qu8LAIziidPg1rZKGgP5d/+6AKsas/hFBDZk+Cr+dlvH1gKGafqBzoN/ip3JaugTfNYWWrcWtBGBErkI/+in4aJSH4zf740xBc99ZDpaFb0pjIkmUKg1NSiAwdTZY+Oc23x8mVk94FI7OkOS6VweOKhlPA==; 5:89bnBTeodONDqjMB8AnjfPynuMQapSYlvjkROjOylOuDCkPZ3wq2kGqtwytF36NekTgKv7YmVdzXJSeLcIXrw5wZqYMqUIdX7SnOtofKRzgic1J8qlO39x01zF7oTGBjYbomnIa0IyU2UmHJi/XjCZNRgzIoMwFWoWCMtSAWwRg=; 24:hsvv1xoNwusldJdEnR4AqZpyhp6Ci/zqAY9MAHYfl9wbOTmmq4Yn28UVwjq8F1+GEI14ucn6eiToNL+lL6Ls1zp4PPrq7Hq2KX1VdT7loJ8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2434; 7:HGRceCALawC7Sjb+6Sz4ml7nST6B+2+90DdRWy9Ux7zVP1f4Vivh2858GT1PJtZ3jfY7vOQksKpKJXVNLmdJlt5HkEHk3TZPRW1fEX7xpL1qPRtw935RrWI6lnxwfO93ftQ65SI82naWC5B75YCQ4L4Tx7bLqKULe+4iRBjpFMBu/vLK9hb8xpq4EGmX5XMj7DK4Dw1LciU45CjCiIMfTNFgANQU+LGQZKN6Nsbi4EJXcJ1bc6G8kv8/SyayjaZZ X-MS-Office365-Filtering-Correlation-Id: b9a8f99b-22ca-4f1c-c0ff-08d59f3f2352 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2018 23:59:46.4987 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b9a8f99b-22ca-4f1c-c0ff-08d59f3f2352 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2434 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=726 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804100219 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 23:59:58 -0000 Rodney W. Grimes wrote: > I am having a compile time issue for a patched that compiled fine on my > r329294 system, but now failes to compile with what looks like a wrong > header being included. You may find it helpful to do something like: make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more The arg to -V doesn't matter btw. You could narrow that down if you know what var -I/usr/src/sys is in (probably CFLAGS but you never know) the above should help find the makefile that is introducing the bogus -I > = > = > I have wrapped the long line so I can point to a difference between > r329294 and r332262 make log of this file. > = > r329294 make output: > = > cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KE= RNEL \ > -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ > -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ > -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ > ^^^^^^^^^^^^^^^^^ this is what I = would expect From owner-freebsd-current@freebsd.org Wed Apr 11 00:29:29 2018 Return-Path: Delivered-To: freebsd-current@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 B8ED8F8300E for ; Wed, 11 Apr 2018 00:29:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 1FAD96BFF1 for ; Wed, 11 Apr 2018 00:29:27 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w3B0TP0a025468; Tue, 10 Apr 2018 17:29:25 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w3B0TPUf025467; Tue, 10 Apr 2018 17:29:25 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <3030.1523404597@kaos.jnpr.net> To: "Simon J. Gerraty" Date: Tue, 10 Apr 2018 17:29:25 -0700 (PDT) CC: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 00:29:29 -0000 > Rodney W. Grimes wrote: > > > I am having a compile time issue for a patched that compiled fine on my > > r329294 system, but now failes to compile with what looks like a wrong > > header being included. > > You may find it helpful to do something like: > > make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 > egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more > > The arg to -V doesn't matter btw. > You could narrow that down if you know what var -I/usr/src/sys is in > (probably CFLAGS but you never know) > the above should help find the makefile that is introducing the bogus -I > Thank you, that does help narrow it down: (I backed up a vew lines from the first place I saw src/.) ... Global:.PARSEFILE = bsd.kmod.mk Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Global:SYSDIR = ${:U/usr/src/sys:tA} Global:.PARSEDIR = /usr/src-topo/share/mk Global:.PARSEFILE = bsd.kmod.mk Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Result[] of :U is "/usr/src/sys" Applying[] :t to "/usr/src/sys" Result[] of :t is "/usr/src/sys" Global:.MAKE.MAKEFILES = /usr/src-topo/share/mk/sys.mk /usr/src-topo/share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/src-topo/share/mk/bsd.mkopt.m k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj.mk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.sys.mk /usr/src-topo/sha re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk ^^^^^^^^^^^^^^^^^^^^^^^^^ Thats gona bust something some day.... Global:.PARSEDIR = /usr/src/sys/conf Global:.PARSEFILE = kmod.mk Global:.INCLUDEDFROMDIR = /usr/src/sys/conf Oh my! Uggggg So something in bsd.kmod.mk is going very wrong... it looks like it starts to pull all sorts of stuff from /usr/src/sys! > > > > I have wrapped the long line so I can point to a difference between > > r329294 and r332262 make log of this file. > > > > r329294 make output: > > > > cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D_KERNEL \ > > -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ > > -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel \ > > -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common \ > > ^^^^^^^^^^^^^^^^^ this is what I would expect > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Wed Apr 11 00:38:12 2018 Return-Path: Delivered-To: freebsd-current@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 068DDF83B83 for ; Wed, 11 Apr 2018 00:38:12 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "thawte SHA256 SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4245D6EFD0 for ; Wed, 11 Apr 2018 00:38:10 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3B0YnPd025577; Tue, 10 Apr 2018 17:38:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=H5d6xPaxeLYCWDrXmXlKUT9fA8sPyb12b8J8n4/a/c0=; b=08VQW5cl+zXNz5CgcgGzVh9aYmmIFfpR5F46NOocMY9TQPvpVaBzYb8eJ3x1joLdyo1h sR8YH6CcIKJJ3jnnblQh35n+Nmj2bp75zDhKnt1CppK5Bq7XRxHq59ZM8GJ8PPbvTQMa 9G9cTCdrQQ9JjHL0pDPbFGGWjYVpwT5YN2H/7sEoJHzyTlOTsvxn4mLQWSm0D3ipWSnJ tl2Mvau+/YWp98SPKt6eL+H5eFgFsgAsIowxyBPfi+lajCW3yhiR0/mkMJGFCEqa+ty4 BWw3JiWESbiS68Wx+0w1z/gMYFLeFtb/pS/N9BieWIgAZ/OtCcLRA3KJrjHaw0OrZp/O ng== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00273201.pphosted.com with ESMTP id 2h965fr7bj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Apr 2018 17:38:09 -0700 Received: from DM5PR05CA0053.namprd05.prod.outlook.com (2603:10b6:4:39::42) by CO2PR05MB2440.namprd05.prod.outlook.com (2603:10b6:102:10::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.6; Wed, 11 Apr 2018 00:38:07 +0000 Received: from BY2NAM05FT036.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by DM5PR05CA0053.outlook.office365.com (2603:10b6:4:39::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.675.4 via Frontend Transport; Wed, 11 Apr 2018 00:38:07 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT036.mail.protection.outlook.com (10.152.100.173) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.653.8 via Frontend Transport; Wed, 11 Apr 2018 00:38:06 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 10 Apr 2018 17:37:19 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w3B0bJ1l017189; Tue, 10 Apr 2018 17:37:19 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id AA3245534B; Tue, 10 Apr 2018 17:37:16 -0700 (PDT) To: "Rodney W. Grimes" CC: , Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use In-Reply-To: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> Comments: In-reply-to: "Rodney W. Grimes" message dated "Tue, 10 Apr 2018 17:29:25 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49137.1523407036.1@kaos.jnpr.net> Date: Tue, 10 Apr 2018 17:37:16 -0700 Message-ID: <53324.1523407036@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(376002)(346002)(2980300002)(189003)(199004)(46406003)(23726003)(68736007)(6916009)(229853002)(4326008)(6266002)(97876018)(6246003)(107886003)(97756001)(7696005)(81166006)(8676002)(81156014)(50466002)(47776003)(97736004)(106466001)(316002)(54906003)(16586007)(11346002)(446003)(7126003)(2906002)(77096007)(26005)(55016002)(186003)(8936002)(5660300001)(76176011)(478600001)(336012)(486006)(126002)(53936002)(9686003)(86362001)(50226002)(305945005)(69596002)(2810700001)(105596002)(53416004)(356003)(117636001)(76506005)(476003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2440; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT036; 1:vWgZv7yN0rYWVcr3tZ3jsWebXF83573Y3OnPt7f6LUFvTiU3ifJV6KhExcFykZIEwSuhFK8iR58sOa3hQXKcuh60VcyYQIslYWrEkedvqfk2FUVbRT9em+Gtrjxep7P4 X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060); SRVR:CO2PR05MB2440; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2440; 3:ZEaQw4KYhoIkFR05C2MwrMyYzuOM4a+yZDEnd6mmmG81N9IcdeC90FlcVUWlLRsujBx3VPF9gPHRqr3ExOdskew+Z6DjFg6VxV805kchOIvMaX0g979oX9Ls3u5+2Gt/qP5cgdIYd8bGMBX4uuRUB++0yzHc5fa2FOoISsKB70JgeXxeQrP82xeUAj516FNdxd7s+T9IH5Hfrvl5s12JLbTaXF0RBkyoGlvL3EqHllW4LZxgSb8rhReg9fBy5LdqXH4Wa4sbI5rdrOnm7XBdDFdL25ukgHy2i9/HwKqPhGL8l2HuDC+dpanHSzq/MPAVOxgUGXeDoTZe57JLL9kFp/BWnqNZq4uM5Bnejo9QwbE=; 25:UPm+fmDExLaw7fiwcIAQnBPdV6KOjCD+3mRpZYz4A1UyMz6t6tbUsee5hcro78/QT8XrdGoNoDA6mMOni7BbghA3VgO8GAYStKFnFdaIE1KaPUXsx9s1yaTvrYbm2CQELM8ZxUGr4hwmgOU2LCvfbPTzA6+PfSrI75rrBUBJt54vaLmlM/lX8b50Cgj6sZqfhZyiLFJonwmaZJLYbIRloGJETohK6zkfoIi8BSsgvmQ9+A/57Lxd11aesHolkIK6YOi1C1EGo/hqiO/rr+L8L3LdG4P1TesebnAe76EShbX/5t94YGpNCgOYkOyA4SOYuh+GjJSW1HwNEuGUqSiUsA== X-MS-TrafficTypeDiagnostic: CO2PR05MB2440: X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2440; 31:kLJ99DzB3SyEmSwI0DVvO283t900bzFP2jh+lZmg4fU7FJLKipFFoWPh+dGrnzpJFp5K+A89vlmmbi8pYH7axVVtdQ/trl+/zlzg7OzJ7D/OZu+zFN33OBGmds7tVfNlwGX26giZe8aAe5opaHNgKToz3COapc4wBKZMGejK/2Z6ZzcX9BcZc1nTT1wUd3mikKKuQn54fqlHA6PWuBoo2LkeVpbg9D8riJEm9d+zAds=; 20:ekaKpYn5+cfqH6P613ZGaJTehSBuHuFs0r3XUb10fCT4LAX3ohK/67OszrSUHe/MGLyyRg/e/d9hA/ewVWxs2cpuAj5bVPtyxCLN1tQA2WGQDmws56OYTB11+z+k5UXK1jJVQeXrR0BQRaDiPttmQT2Nuyh86zwL/CLcAz6g+VENzuP4aKiUD1yLV1GTSvq7QGDbL5CeTi8KemO04tSNK/HQNUyFb3WmOL2KE9IkNrrTnyfdg2TTGALvBkN/qVlDg3174IsxpDo0AttjY3FPWNSOViExNIYD0e2Z5oSOov6x+p5WpSXkDigPvREvALiNGUz71B0rHYEb/tlRo14jB9VPXWnJZZs6EcHNwAHoI//C1sG1qr780IWx9n8W4FyO7BXJ8n6z3TL1y2kp9oEioCXtY7QevIxlREYBiwcZEEocnlkby8VAVfwNTlxa8XtUfhrIZOOcqkTc6LAI2tia1dEs7vbzYOtrlN6sa+30d7OES+4sAidEjLVzj+/wy+4/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93003095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CO2PR05MB2440; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2440; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2440; 4:F88ixnmKNACTDdB1APDxfseU4B7+/m5Tu77ZikvdRTgygywpfk2c8cvy8u+nbS9nOWOUJVCaENa5jRvE8w6w90CW6JeL0dK5AGJv2atxu79L0I9ybCqg4TXOKSlnofvw+dOHg+OUX0ADODCAbaTDE/tAlus9n+6Yc/V2OBdPJT5n6tRkJsNfvWhZ98Ummb3yD4zYPQeMqoznn1WpXCcIlvH9DgvEedk2X6bxutX2eFdi+9DBMubiTXnLdHsCytqVUSBB2nUipFKCkaynbzK24Q== X-Forefront-PRVS: 0639027A9E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR05MB2440; 23:PtPpWBL+1Wwka3pzdehQrhum+JVjrtvqnot2tL9fk?= =?us-ascii?Q?SVKxeUBzzvOA0IVd55dT3cv20sKSpm580WNzr7/Lv+BryzRhVfIaEJd1s2AR?= =?us-ascii?Q?+eT4lqTSwDI3EuB38Bvmv1zfOEvMcf8DjPqVmo6Rf+uoPZrcRjcg7KDLWoO6?= =?us-ascii?Q?2SXe/SZD3cUhG5mWkuNddsOzC6TMukFErBOwRvtAknFL5nOkhOXVm+VeRtz3?= =?us-ascii?Q?Dqw13IZGINXLE7+8qwZf6bwiOgD0CCxCfvE5MK9/dQRMMJEXrKf7VTcFesfF?= =?us-ascii?Q?SJ0ZDXAxqd5aCQnVkTY3Whu6zCU4mZHihUjAOQSxqHCXMxynwOdHWn0WKVzu?= =?us-ascii?Q?D/pqxkSkPMvmBhxEDpEqlsF/+yq9LC4PC6j91J1KUu53f9ul0DY0UVxFYF6a?= =?us-ascii?Q?S7K4XtWDMgULUGqYcNx3UfugbHAf5SNEYSpivwDb8mJowgRFImdzuflVPshR?= =?us-ascii?Q?aOdmE3K5In2HNjkCpcNtPdIAeAYwV5DiG5/QOhpy37HRF8kiTcoK3M51wLVc?= =?us-ascii?Q?2grX1+AWQSTxzbWwcnAbF+NBgxIsqWZ3DhLtl8T5CRm39oJ47+LUywAFC59d?= =?us-ascii?Q?BFiW18LnURF37d4eHGjGFSW9BS5My2Hmv7hPmKXC1w6gJlxRflsPJT+QGNGU?= =?us-ascii?Q?/k71EgLTC+B0O8qc+5jdy+5RfhbUugwpw5rcpbjuMSIHbqiMoY+V5UMtJt2x?= =?us-ascii?Q?7DtnXZDKzB81FDaUgFVlNic6vKvxxxIalPEKdINQPfCKMK+EzmDvHlJzBdOO?= =?us-ascii?Q?Sc8t9lLxglcF5XBt4PpODYTBOoM2h0JmXLf6nM3u9CAANjIlFXmq/vlV+5Tg?= =?us-ascii?Q?6C2Zi6UQTtfknUqyaOS4xL3beExDp2b+2mMys2wvydh1km863OP7pBIYiVG9?= =?us-ascii?Q?6rAZZxgZykwPJmO5ALZgp+fpzLoYiS04l3PaRQMjKwO+XTe6HHyVLz/2juZi?= =?us-ascii?Q?6u3kZtT29Ae1lFLpTD71Q9eLbLP4MdzGeqxy4s+JHS64Nlf/y6QS3xRHVeaA?= =?us-ascii?Q?6jp+FS+HxJwtimRf65DOD0yih8Usu8K1n0FfSxqLY8p/fVVpguvhM7jdbtF1?= =?us-ascii?Q?Yr5uBquBnSX07Woi3GwNghje7qwwhPMYmHkiE/WzjkaEqlLDcF47tCjU6VPw?= =?us-ascii?Q?LxN2lHWd+9eQ+5VIFRLFHylvcMezxyQ4Oait4n2SwlQhdcqqc7UMSgdLdtCQ?= =?us-ascii?Q?r/njHmaUPruPIcOfsgGvNJXLwuaZXSSgvBNVIDn/hL3oSKrMcLzwPU1/1j3H?= =?us-ascii?Q?H/tDJbyFa8QbAW1LGvAy/IYDT48DCVOs+CrZ4tFkVOs+FUxnNxqCu/LB2tCQ?= =?us-ascii?Q?fFT8IFOi80ZNoqMvRa4TTw=3D?= X-Microsoft-Antispam-Message-Info: CudFzdoS8VvdHZjC26oDqxsqCXUUtcgAnlr2Ki5Tt+NNWJPKtcUUwyvDawglrO7EJigYfAWCPgJvmUrM/0bf4+gNQ0NkTXafl7zfhcqi832p74WAyx3RkDPhRr5YT30FLKUCTCdDaODyWEa/cFHbXecO3ZJ4uVhTaIcG27lr6DwAzPlEEiSmmILlbPbJCh3z X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2440; 6:qjDV2lsTNSyUty9k9xfPRLrKAPdovSW9AetOP+hUM/lHEWyEQTnvSoeNWYfuwsoP514/WoExTL/muqLyVHMHLC+qIKCT7YAJr2osDUnxkF0gnfYdNhnvC+1hHBUkYgKRjQMFnkmUMPqQOoPFgHCL0LD9mK1k+0v7yQ/g9oz2+af/Rc/g0BIOcIJs9XXeYa1twTf4cK42KSjYbFMeMvv9cPMo1u20X3vB83+rkpmIbku57BHK+RFp+wbGc56PcTIwFK3gOvM0AYOyeAjtq7YWKFtR+QltCgGwEjhmBJMU+2tGjwfGp/lPuaLaEW1u3O4IBmjOkhayyPY9GPXZ/PvHU04IrjGi6ehdv1oGA5jT4gZSeSJU7mwDn6T7FerLvYjAVGH2A84garQeejw/X1ZNBAMnl1VRYkmlugL6XrarVH1ApMCvxrGmP32Yvqqn7GygUeFC0jTGipQB4PuZkN5YKg==; 5:H7CKrCo/AKlI4a1dLXlsteEh9bam6FtoQOY8ZXDAmSRHnrBENuSb9eOZP3O+p7i1CCBIaChNqh8iDaoKOObQVqpl9GsEjISfUibMbKl4TzqDUUkGZw1eMkMwaaXHAlVWaDlU9hl2bMptOAobRAd2pt5rNl7mQsiUUGO5daQ16Qo=; 24:v2xXp8Ix7RBIP09OrIoKe0rBLq7X59g0rjkJ/Z41c00XO+mKADvWX+lNXPW+yvVqH1Xe7dYEbYWHjXrBjLjMvV2RFjqeUR+/f9O+S8A5nmA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB2440; 7:qaGqMxnAFgUGwwsSjfvzNg5beOcqackKQdLXcGXHNX1G0IYxMV+Fwd27DTpN2bkWAV4g1a93xv6CASogUFe5wAtZzCkm0Av0PC1DuKlmae47XUw4eYXB5bQ8SAIOICDCLHOg6d42W0xxt2mhv1VnS5wlAZIgsn1ujaUJSLuX5nj733hj0FApz9YdL5BvuxrAQPSNkiNh6vT6Vk2uZw0K1261DJM3PDkW9geLy1it/vxLzx+X+ZGcab6LveyZngYv X-MS-Office365-Filtering-Correlation-Id: 0750e58c-9ba7-4fd8-da91-08d59f447e63 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2018 00:38:06.9546 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0750e58c-9ba7-4fd8-da91-08d59f447e63 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2440 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-10_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=725 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804110002 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 00:38:12 -0000 Rodney W. Grimes wrote: > Thank you, that does help narrow it down: (I backed up a vew lines > from the first place I saw src/.) > > ... > Global:.PARSEFILE = bsd.kmod.mk > Global:.PARSEDIR = /usr/src-topo/share/mk > Global:.PARSEFILE = bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Global:SYSDIR = ${:U/usr/src/sys:tA} That's from the .for loop in bsd.kmod.mk which is clearly inadequate. Since the tree for some time now, reliably sets SRCTOP that list should start with ${SRCTOP}/sys or ${SRCTOP:Uno}/sys just to be sure you ignore it if somehow unset. > So something in bsd.kmod.mk is going very wrong... it looks like it > starts to pull all sorts of stuff from /usr/src/sys! From owner-freebsd-current@freebsd.org Wed Apr 11 09:53:07 2018 Return-Path: Delivered-To: freebsd-current@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 3102AF84BEB for ; Wed, 11 Apr 2018 09:53:07 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC648C7FB for ; Wed, 11 Apr 2018 09:53:06 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id j68-v6so1713941lfg.13 for ; Wed, 11 Apr 2018 02:53:06 -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:references:mime-version :content-disposition:in-reply-to:user-agent; bh=uxLE4OSlb+W8bskjhJ0ZqJhlY9672CMJWFKck/t1V+U=; b=YqwX4rYbScYUFRoeXsihomUFinlIF9IIfbNHuWYsa9V1fDMVXANhwKahL4yC9YrLfK I5xWjQ0eFh4iZ1CClr0JKBR7eoDEK2glzkJEDM9p9AA4aYQTYiKPGCI7vhDCaAiH8oGK 0b8PjVN6mKslq7H5PWN0l+0BZKB6CrtTytdsMQVWsfPz4UoPWaZkeQQ2R/Yxzu4Zvolr u389862yuGaGr8iYlSmDm1mYMojBHj166BY25x9GHzqFkRpXYq7r6pUUb9Jq4da0Rxyk jkhaNwd+OuJIsnNeeWvSV4ptRJ/Mdqriou0iG8dmJsTyUyp/d1s2pnOWOK0ciGU0Pc/g 4o/A== 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=uxLE4OSlb+W8bskjhJ0ZqJhlY9672CMJWFKck/t1V+U=; b=FWiNLCgojwcpcj+UA8/O8FPiHCZy2ZeEWkhjcEjdKUuEX6ZDhAG28y5e+V3koz09kD 3GU+kAu3qnfj3/iPU6tgaGqEJ+UkUURHXbxtFxl4w37eK3JtrHIYc904YVruJVP9F/pX rRMjOlNCKDlMAMOfxeyGhb5j5lk7H0oSxqWosbYa9SknkgxUzzWsYTYmB34TO4KyRVlL WZ9xPdoLwCoClMKpSaHxnWme062aWQ6uZpel00zNr57ywMari+w0R0If6N3poSOjtuC6 TcQfTQbSkIdVT1ceuSZlNf/jwpy89IISfyQIO4RzI6ELKuSXnPZ+JZ/9mqs2Jm+QKsCY Ub9A== X-Gm-Message-State: ALQs6tAVYVHS3Sym4ojr3ft2AXFhoI2OrkXuC32EKK0XYfHWRWdrnZ+f NbpP+9mohnGWYJPe3739q2dpozFj X-Google-Smtp-Source: AIpwx4+3Su79kLHmVAKLVzlZIcYVHqefmhadQ0zunieJP/F8pIbU4mNuIpOZh9nRGFpyfoAyr9y8mA== X-Received: by 10.46.158.137 with SMTP id f9mr2663926ljk.113.1523440385266; Wed, 11 Apr 2018 02:53:05 -0700 (PDT) Received: from localhost ([81.19.73.155]) by smtp.gmail.com with ESMTPSA id c19-v6sm177137lfb.54.2018.04.11.02.53.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 02:53:04 -0700 (PDT) Date: Wed, 11 Apr 2018 12:53:03 +0300 From: Vladimir Zakharov To: Kristof Provost Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found Message-ID: <20180411095303.ukgx7ajxrluuocn4@vzakharov> References: <20180409085050.mjy6itqti6spzbdx@vzakharov> <20180409111011.5gqhtqtuw6xsg3wq@vzakharov> <33EDB48E-A330-4F5E-9328-AE3EE1E66B95@sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <33EDB48E-A330-4F5E-9328-AE3EE1E66B95@sigsegv.be> X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20180323 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 09:53:07 -0000 On Tue, Apr 10, 2018, Kristof Provost wrote: > On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: > > On Mon, Apr 09, 2018, Kristof Provost wrote: > > > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: > > > > > > For several days buildworld fails for me with the following > > > error. Cleaning > > > and > > > rebuilding didn't help. > > > > > > ===> tests/sys/netpfil/pf/ioctl (all) > > > --- validation --- > > > (cd /usr/src/tests/sys/netpfil/pf/ioctl && > > > DEPENDFILE=.depend.validation > > > NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile > > > _RECURSING_PROGS=t PROG=validation ) > > > Building > > > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ > > > validation.o > > > --- validation.o --- > > > In file included from > > > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: > > > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: > > > fatal > > > error: 'netpfil/pf/pf.h' file not found > > > #include > > > ^~~~~~~~~~~~~~~~~ > > It should be fully fixed as of r332358. > Thanks for the report. Works for me. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Wed Apr 11 11:40:01 2018 Return-Path: Delivered-To: freebsd-current@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 AE86DF8CCEC for ; Wed, 11 Apr 2018 11:40:01 +0000 (UTC) (envelope-from david@catwhisker.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 49A067C6CA for ; Wed, 11 Apr 2018 11:40:01 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0D83DF8CCEB; Wed, 11 Apr 2018 11:40:01 +0000 (UTC) Delivered-To: current@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 C2446F8CCEA for ; Wed, 11 Apr 2018 11:40:00 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 2AAA97C6C9 for ; Wed, 11 Apr 2018 11:39:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w3BBdwLH042740 for ; Wed, 11 Apr 2018 11:39:58 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w3BBdwVD042739 for current@freebsd.org; Wed, 11 Apr 2018 04:39:58 -0700 (PDT) (envelope-from david) Date: Wed, 11 Apr 2018 04:39:58 -0700 From: David Wolfskill To: current@freebsd.org Subject: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 Message-ID: <20180411113958.GE1134@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="afaOoWBOIwPZGAW2" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 11:40:01 -0000 --afaOoWBOIwPZGAW2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This was running: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r3323= 99M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 root@g1-215.catwhisker= =2Eorg:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 during boot, after updating from: FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 r3323= 54M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 root@g1-215.catwhisker= =2Eorg:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 (My build machine, which uses an re((4) NIC, did not encounter the issue.) It appears that r332389 is implicated. =2E.. Unread portion of the kernel message buffer: __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D3) at /usr/src/sys/kern/kern_shutdown.c:361 #2 0xffffffff80433f4c in db_fncall_generic (addr=3D,=20 rv=3D, nargs=3D, args=3D) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=3D, dummy2=3D,=20 dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff80433a99 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3D) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff80433814 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff80436a3f in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80b753e3 in kdb_trap (type=3D3, code=3D-61456, tf=3D) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff80f7eaa8 in trap (frame=3D0xfffffe00004377a0) at /usr/src/sys/amd64/amd64/trap.c:548 #9 #10 kdb_enter (why=3D0xffffffff811df9d4 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80b2feda in vpanic (fmt=3D, ap=3D0xfffffe00004= 37910) at /usr/src/sys/kern/kern_shutdown.c:826 #12 0xffffffff80b2fca0 in kassert_panic ( fmt=3D0xffffffff811dadca "mtx_lock() of spin mutex %s @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:723 #13 0xffffffff80b0ec93 in __mtx_lock_flags (c=3D0xfffff80008c85d88, opts=3D= 0,=20 file=3D0xffffffff81113c90 "/usr/src/sys/net/iflib.c", line=3D) at /usr/src/sys/kern/kern_mutex.c:246 #14 0xffffffff80c466e1 in _task_fn_admin (context=3D0xfffff80008c85c00) at /usr/src/sys/net/iflib.c:3716 #15 0xffffffff80b73849 in gtaskqueue_run_locked (queue=3D0xfffff80008489500) at /usr/src/sys/kern/subr_gtaskqueue.c:331 #16 0xffffffff80b735c8 in gtaskqueue_thread_loop (arg=3D) at /usr/src/sys/kern/subr_gtaskqueue.c:506 #17 0xffffffff80af0064 in fork_exit ( callout=3D0xffffffff80b73540 ,=20 arg=3D0xfffffe0844223008, frame=3D0xfffffe0000437ac0) at /usr/src/sys/kern/kern_fork.c:1039 #18 (kgdb)=20 If the dump would be useful, I can put it up for access. Peace, david --=20 David H. Wolfskill david@catwhisker.org Well, what did you EXPECT from Trump? He has a history of breaking promise= s. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --afaOoWBOIwPZGAW2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlrN9A1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7hdO7QgAx5oAH3AH029PI54L+Tv6GpGJtn+/ljWpjyGMDjQcd4RnjpS+/1Qr1v+E DdPWlIN7+1XntosAHXny7ucOFxQT4LB6xnBpAP7Oeqi8XxjOOABoN50h1Dxvjsy5 gz8Hb7071mvsxMD9dZNUj6halZQH8l24xct7pIL1CIzicsfUkATRUIcDj5jhQtdg DVeI3kVgT7xwzhFDeOeBCLbZhJP+8NgkfqoWtVGeWw+4dIS42Xe1yvZIgItieP2G 4U+JRW1MK2BHn2urT2Vnx4LOBu1do6RrZ/5aGfRUaU+ggMoF0QxOL9cuJMnL8OU8 C2dyIwz3fsomuGcLTu303KKsR9Q/LA== =PTC9 -----END PGP SIGNATURE----- --afaOoWBOIwPZGAW2-- From owner-freebsd-current@freebsd.org Wed Apr 11 14:49:32 2018 Return-Path: Delivered-To: freebsd-current@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 E4F42F9A7B7 for ; Wed, 11 Apr 2018 14:49:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (unknown [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 57AE7682C5 for ; Wed, 11 Apr 2018 14:49:31 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id F19701A1D6 for ; Wed, 11 Apr 2018 14:49:30 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f41.google.com with SMTP id q9-v6so3045258lfk.9 for ; Wed, 11 Apr 2018 07:49:30 -0700 (PDT) X-Gm-Message-State: ALQs6tDXOxQqSb7FfsDQ/rDDouxcfhlnHlWT1o7O32CFax3IxUXHdH4F 8EWJ4hEPD/pkHjFDRdCXv0vCCFdak+ABYSYzXtE= X-Google-Smtp-Source: AIpwx4/OULZukovoP5L/rhxvZGStkEQegD6VU960SHcRAFRbtmZAEK+DuqYx7yRogt3j0jILua9XeQSlk+VmUHnulPA= X-Received: by 2002:a19:7904:: with SMTP id u4-v6mr3251097lfc.129.1523458169176; Wed, 11 Apr 2018 07:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Wed, 11 Apr 2018 07:49:08 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Wed, 11 Apr 2018 09:49:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Testing: UEFI Changes To: Zaphod Beeblebrox Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:49:32 -0000 On Thu, Apr 5, 2018 at 7:23 PM, Zaphod Beeblebrox wrote: > As I said I would, I put the contents of /boot onto the FAT-formated EFI > partition. This is suboptimal. The default is to use "kernel.old" ... etc > ... which cannot be done on a FAT partition... at least not with our > filesystem driver ... > > ... but with all of /boot on the EFI partition, simply starting loader.efi > works. > Hi, Can you try a standard setup with the patch at [1] applied to your boot1.efi? Standard setup being /boot/loader.efi in place and boot1.efi copied over to your ESP. I *think* this might help your situation, but I've no real idea. If I know what I'm doing (which I don't), then this patch should (maybe?) force your screen down into a lower resolution prior to drawing the menu then reset it once more before it prints resolution information and executes the kernel. Maybe it'll fix it? Thanks, Kyle Evans [1] https://people.freebsd.org/~kevans/loader.diff From owner-freebsd-current@freebsd.org Wed Apr 11 15:15:06 2018 Return-Path: Delivered-To: freebsd-current@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 C8933F9C684 for ; Wed, 11 Apr 2018 15:15:06 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic316-27.consmr.mail.bf2.yahoo.com (sonic316-27.consmr.mail.bf2.yahoo.com [74.6.130.201]) (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 6C77A6FB75 for ; Wed, 11 Apr 2018 15:15:06 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523459700; bh=1Ml8spfk49jNmwVWo2uXBIaOAbZeqjcUKhC2joKPB10=; h=From:Subject:To:Date:From:Subject; b=oFtglQ4K/uOskkezZu6n51mb7K7Xt73z5srSni0kPGTKnf2NW0BHTJTN537jF5mnfe95b3zhPDMyvADtg04xan4zG1pCPSMtF7wwhkgz+/qJB7grqDUPgq9wVADQbo/mjtq8kLa4QIqTWGfPF/rzE4bzBpojFjNVRXFm7ahAPF8NfEsCOqHUQKmFQsErBaEE4KqPEXoohYGxbysmqYz1yFxSOf+DwZeF80V1jnkjZBzgoWHSHQNgF5KO822X+E6pPLI5npsI5vnApaC8pEH0i+TGsaHnlUjW1xL1w2Ok9+GKXCf/WyOlD/2Sd7coJ5MO55zt5lIjimr9u8wKMCNcVQ== X-YMail-OSG: RezEDj8VM1kfQD9UhWgUAvo4zhqjSIU8PgRo8dCQq1h3qti6PY9bDvOf.DL.IUU 4cQv6hHThYcP7HBUbPEU65gfMG6FLhbRCKBTzApD.EHqgyxGxPXI9WXAw.V5Q66xN6HKlaszDX4A Lv9sFC.kxjydt0KE9SniVlmChfdRWTtUBW5h0yj92d24cb2xIzTuU0zo.96qa22vrV9kQoRrc6oe dZuo9XbTYCzNmm7d2Hvna2OMfUnn1NYTITCMLfHFsMuCV2NSIp8r5JifTZ0uKshb68XXImkSoHmP 4Vqafuf_RODM_CMQRsajEluFCiGaoqT8TKz0znk6_yYIkKnRVeHOlvx1rn8V6E1cd8M5ni6CwFmg aPpXwW4fkDLQbs2AFiwh3DBImQcxKEJsjMIDfdCQAb_2KjtvuCy8FHzgzfG2q3lUAERuX.ITlG81 Etb6KC5wScVe9r2vAIyal.vw0oXnRa3f.HjnesurT0Ah48Zfh.RctXfhr..kGSOQbFg_8WYPYoWn 0_1uXcyYrmQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Wed, 11 Apr 2018 15:15:00 +0000 Received: from 181.52.72.201 (EHLO [192.168.0.6]) ([181.52.72.201]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fdf137c47949fb8d38da1568bad4c89d for ; Wed, 11 Apr 2018 15:14:55 +0000 (UTC) From: Pedro Giffuni Subject: CloverEFIBoot (was Re: Call for Testing: UEFI Changes) Organization: FreeBSD Project To: FreeBSD Current Message-ID: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> Date: Wed, 11 Apr 2018 10:14:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 15:15:07 -0000 Hi; FWIW, I use a very old PC of the type where the processor will not be fixed by Intel and that still needs support for the traditional BIOS. I also bought a 3TB HD (they were easier to find that 2T). If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and will happily use ZFS for everything, however I want to dual boot so after lots of testing I ended up ignoring 1 TB of HD :(. It does happen that there is a really nice boot loader that could have saved the day but it is very difficult to install standalone: https://sourceforge.net/projects/cloverefiboot Just in case someone has the time and inclination to play with it :) Pedro. From owner-freebsd-current@freebsd.org Wed Apr 11 16:04:34 2018 Return-Path: Delivered-To: freebsd-current@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 ACBA9F9FE77 for ; Wed, 11 Apr 2018 16:04:34 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52C8979234; Wed, 11 Apr 2018 16:04:34 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id p9so151634qtn.0; Wed, 11 Apr 2018 09:04:34 -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=mZ317I1z7cZdGsIzXu3pblgWA2qq+jtOxdoI+EbWPdo=; b=Rum+vCrotArBK220JU7eTQuoN4ewYm1ix0U5KWcsP6JQv5VTlwbEG7wKD09ogSm6hK 4Bn2IFYBfhc9k38mnvzNtejxmAoZImWPMCu79xdSqdSWv1m4eCYmjdu8L07ZwQcxt8S5 B7vMR1Ye0AAO7fHEP+EQlfDIdMxOcsg2GHgOE7boVrN/RRsl0GGTxUXr6u6JPR3DCtv2 L3WQf5XEN8bHHOm9/X6R4nBa3O+6BPZzdPRkI4PhYGnTZ5n8F9qrELWyCCtDIkLh7J4o hBL1Bc5aOHZzrvCBv4AV4tnXqb8fV0X9iZqiHdEqa8UAt/uKJlsByqxa0k+juDDV/6in wBFQ== 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=mZ317I1z7cZdGsIzXu3pblgWA2qq+jtOxdoI+EbWPdo=; b=SoFb5FC+1j42CeXHadKlnhFb1Vql/EIA7ndyvhZ3+04nCI3PSSC/381KvECUHIjcqu 9glDDPc4UZFktSXOuqJOxTR0REOmsIyDJg2qT15l67xkIYvkuUp4l9tGuj7uJ4fe00LX e/2N0U8b0CFrjwePccgiqD4nqOfyr36xk56y5xfR4WEVmkWtBvKPbUL8s3P3kU4tpTFq sqb6ZKkphXWMF2kj2o0zPg03lK8+zVSTgk6dmqdpoxDFlZHlc25Pszj6M5QJFMa9MBsO BmyDTd7lfQ9Ve20znPRU+6t/P+Kp4rU72L45dZA0lP0cI6/kyeNAdw/yvIqH7nndFND0 TFmg== X-Gm-Message-State: ALQs6tCJf/Fk/WDXZBKg2LiGwgxkzxWov8PktnUf866XN0AKUuiAHBb5 FqeniYvlLWydvT394i/O53plHyEvhEv+U7jLPwQ= X-Google-Smtp-Source: AIpwx4/GlYeI/jgXh4urVlST4LoJD3jUCicgfjA5Ig85rLfFlopoJPshmMogPf3JnTJtk4i81zaOi2F4LbdbICVfL1A= X-Received: by 10.200.64.70 with SMTP id j6mr8267310qtl.321.1523462673551; Wed, 11 Apr 2018 09:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.81.207 with HTTP; Wed, 11 Apr 2018 09:04:33 -0700 (PDT) In-Reply-To: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> References: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> From: Ryan Stone Date: Wed, 11 Apr 2018 12:04:33 -0400 Message-ID: Subject: Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes) To: Pedro Giffuni Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 16:04:34 -0000 On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: > Hi; > > FWIW, I use a very old PC of the type where the processor will not be fixed > by Intel and that still needs support for the traditional BIOS. I also > bought a 3TB HD (they were easier to find that 2T). > > If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and > will happily use ZFS for everything, however I want to dual boot so after > lots of testing I ended up ignoring 1 TB of HD :(. > > It does happen that there is a really nice boot loader that could have saved > the day but it is very difficult to install standalone: > > https://sourceforge.net/projects/cloverefiboot > > Just in case someone has the time and inclination to play with it :) > > Pedro. Is the issue due to using MBR partitioning? FreeBSD supports booting from a GPT partition from a traditional BIOS; you don't need EFI. Is this machine so old that its BIOS doesn't support booting from GPT? From owner-freebsd-current@freebsd.org Wed Apr 11 16:54:02 2018 Return-Path: Delivered-To: freebsd-current@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 60801FA2D3B for ; Wed, 11 Apr 2018 16:54:02 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic316-27.consmr.mail.bf2.yahoo.com (sonic316-27.consmr.mail.bf2.yahoo.com [74.6.130.201]) (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 031D484E87 for ; Wed, 11 Apr 2018 16:54:01 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523465640; bh=1ulxxGqRdK02KvCdps+lJeaknurJSFIsK5HJuSBZdV8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=PiYB9dQdNAyhG0YtgBw3V3S+Gy+p6e/RieFXSpcE59VfiC7am20A+F0wIpFv7wPM2GDDKkQAu2gcU2xu9am78LOPELjCebZK0vqAGrYJjgPzDJaFmN9DpH2u/aMvIZbYe0R91bAHAhWQtuUv2ssoTF+AXHNSr61yilHpHo8CwlqUvRVhw9KtebQgnD+uM5F6IzbR3Dg/jAPhN9CvaWYmBghxlev7DLQFC813ydc8JW/y1FF9VnjEOPc1ZieGGR4SlmYfLHP6L6WvVwsT5G+ZJwxWxFqF4jxyMz3hZPvHWpcPT4sbBsRKC7bpAlGl2Wp8fL9+xHJA6tTVVNemOw00rg== X-YMail-OSG: MfS2588VM1nRl1P5zjXHC2Cc.CLM8l3fHv7YhgvfMF6AmGD.aM6zxdhVcUOJYde EP25Vhxd37RHUHkJ8bKWvuTmHk5VkaVvT9.MncXOptiklmIEgMKz6HpRyBLlMnoXRCdwxi3WnEs7 TkeCqbQXZYZJDG8RuAk8JJOMrPtDnNNcMXsfDlqOGX.pQ4ejW.8vNu0H7ymHeddI8.Hx05dcg.Yx MaWHpiRDnj_a33XOGGcEaEubomdR2w4LeFAyZjE8odcDBDJCOej5CbWIkYBRYEqqtnoblCZkjYqS gWsrrT5w_xkBabDr5EX9OaXO7ULOppF7Zrz9XHot10NuT.Or4Kki2UcFI_LZdV487p0WkfJfNvCB JmVXAzkAFYSFs9YiHCDy4yb7ao1.nbmev.zEpGILi4sVrDtFJJJOoPLp1_G1lcvYpuOe3wSbNFD9 g_UYnafNLXH1zPbuBAt4H1Ka4HtrNR2izbhA_uNMsJ7N7wy.7y4XZiVF5yahc.SLOmbm9awyY.wI UK58Bj6FjZA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Wed, 11 Apr 2018 16:54:00 +0000 Received: from 181.52.72.201 (EHLO [192.168.0.6]) ([181.52.72.201]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 520d12560a2f42372b68f4a12e214e04; Wed, 11 Apr 2018 16:53:56 +0000 (UTC) Subject: Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes) To: Ryan Stone Cc: FreeBSD Current References: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <890e5033-0b1e-b0f5-4a86-8290b663024d@FreeBSD.org> Date: Wed, 11 Apr 2018 11:53:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 16:54:02 -0000 On 11/04/2018 11:04, Ryan Stone wrote: > On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: >> Hi; >> >> FWIW, I use a very old PC of the type where the processor will not be fixed >> by Intel and that still needs support for the traditional BIOS. I also >> bought a 3TB HD (they were easier to find that 2T). >> >> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and >> will happily use ZFS for everything, however I want to dual boot so after >> lots of testing I ended up ignoring 1 TB of HD :(. >> >> It does happen that there is a really nice boot loader that could have saved >> the day but it is very difficult to install standalone: >> >> https://sourceforge.net/projects/cloverefiboot >> >> Just in case someone has the time and inclination to play with it :) >> >> Pedro. > Is the issue due to using MBR partitioning? FreeBSD supports booting > from a GPT partition from a traditional BIOS; you don't need EFI. Is > this machine so old that its BIOS doesn't support booting from GPT? It's a Dell Optiplex 760 (refurbished). I don't remember the details but FreeBSD supports booting just fine if I dedicate all the HD to FreeBSD/GPT, but the Windows bootloader wont so I needed a bootloader with it's own EFI implementation that would. Clover comes from the Apple/Darwin world and does this but I never managed to install it in a HD; ideally you have to figure out how to install it before installing the OS so I had to install it later in a thumbdrive. FWIW, the only documentation I could find on the gory details for dual booting (with linux) is here: https://www.rodsbooks.com/gdisk/bios.html Cheers, Pedro. From owner-freebsd-current@freebsd.org Wed Apr 11 17:02:33 2018 Return-Path: Delivered-To: freebsd-current@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 D1BEFFA399D for ; Wed, 11 Apr 2018 17:02:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5516087ED5 for ; Wed, 11 Apr 2018 17:02:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1564AFA399C; Wed, 11 Apr 2018 17:02:33 +0000 (UTC) Delivered-To: current@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 00202FA399B for ; Wed, 11 Apr 2018 17:02:32 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 862C487ED2; Wed, 11 Apr 2018 17:02:32 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id t192-v6so18382460itc.1; Wed, 11 Apr 2018 10:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CKoc6FYJ9LhPAR7qoD2QFziR0ZS7RuVINBRb+4jBGlM=; b=uWiRgeN0Wzx2Ag75kwwNcsGthaQCRGcovitggzJTE91dpvKM8jDphlVKYyANtmR75w je+b8LmshAxCFPskYVP02iWUJMOfu5JYJVQd3qfzpIvMRPQJdzXjErb09rwOW2/z8DRW pPQTS3pGj2BLylvYY3E5uWMUXQFKvEOu9CR0c/xo9CrKzvQ+eLghZjKVIWAX3g9Vp7RI DXdGV7D531oRuRonJYyd3bKZq+OTmhlVz6zCZplp9t1q/zaQ+JiIslprfwFqFYpK2I00 H3yyRoKpc9D2S6XH4QnRV2YBrzyXQZ88EvmLnkjxUdz7gcppkRX9Bq7BuCxG2PWrexd9 D/lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=CKoc6FYJ9LhPAR7qoD2QFziR0ZS7RuVINBRb+4jBGlM=; b=kgakzlT76JmdR3UcYS0qizjYUxTy25o6bXB7qURfknilFCALoNvJcgihJOkcMmS7P4 q+q8HiAWqQ8ry9RQPjx3+8vX9Rcl8D5DjyqC0cNThMwB3qU9+1Nnw4QYFWezai2xQAg7 oAoUKscyah7Gdzm9rGMvmrml+ZLFYR+RLXEA9Yu5b5643/w0e1Ub8jVrqehRHGcgHfZv JpIn+Q9qPGQpYrtIB31lsmphXtyo6m17XQT8z9r16CuovWydWNozBFAyC/9w260TBeTb NyoXKK9OI1b/ixoUT8bcuNLQ6x9exnYyba2uZmSDqqntgXqylTSle0VyfsuApQ4uGKxY sm8g== X-Gm-Message-State: ALQs6tBR/eUyctzOPVUWAwBCaXvfuiJRQYDd3GCRq+MBclg59PycaYp4 8vz7XG+MrNQ7xeraX1ItvA1VCg== X-Google-Smtp-Source: AIpwx49bM/61upEkVVk0prRyfc6pmF5aOHPeLCsrLjRezj9awM1SXBjgjV2RnPnxPXtnk5nv7TATgw== X-Received: by 2002:a24:7a12:: with SMTP id a18-v6mr4800452itc.88.1523466151637; Wed, 11 Apr 2018 10:02:31 -0700 (PDT) Received: from raichu (toroon0560w-lp130-04-184-145-252-74.dsl.bell.ca. [184.145.252.74]) by smtp.gmail.com with ESMTPSA id k144-v6sm881384ita.31.2018.04.11.10.02.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 10:02:30 -0700 (PDT) Sender: Mark Johnston Date: Wed, 11 Apr 2018 13:02:28 -0400 From: Mark Johnston To: David Wolfskill , current@freebsd.org Cc: shurd@FreeBSD.org Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 Message-ID: <20180411170228.GB43015@raichu> References: <20180411113958.GE1134@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180411113958.GE1134@albert.catwhisker.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:02:34 -0000 On Wed, Apr 11, 2018 at 04:39:58AM -0700, David Wolfskill wrote: > This was running: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > during boot, after updating from: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > (My build machine, which uses an re((4) NIC, did not encounter the issue.) > > It appears that r332389 is implicated. I'm seeing this too, under bhyve with e1000 emulation. Reverting r332389 fixes the problem. From owner-freebsd-current@freebsd.org Wed Apr 11 17:21:44 2018 Return-Path: Delivered-To: freebsd-current@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 B42CEF80D37 for ; Wed, 11 Apr 2018 17:21:44 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from stargazer.midnightbsd.org (stargazer.midnightbsd.org [IPv6:2001:470:1f11:1c7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "stargazer.midnightbsd.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E5736B6BF; Wed, 11 Apr 2018 17:21:44 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from [10.88.24.193] (mobile-166-177-58-152.mycingular.net [166.177.58.152]) (authenticated bits=0) by stargazer.midnightbsd.org (8.15.2/8.15.2) with ESMTPSA id w3BGroF7030233 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Apr 2018 12:53:53 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.4 at stargazer.midnightbsd.org X-Authentication-Warning: stargazer.midnightbsd.org: Host mobile-166-177-58-152.mycingular.net [166.177.58.152] claimed to be [10.88.24.193] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes) From: Lucas Holt X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Wed, 11 Apr 2018 12:53:44 -0400 Cc: Pedro Giffuni , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> To: Ryan Stone X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:21:44 -0000 Machines don=E2=80=99t need to be old to have issues. I have a two year old a= sus am3+ board that cant boot from gpt without secure boot enabled and is ha= rd coded for Microsoft keys=20 Lucas Holt > On Apr 11, 2018, at 12:04 PM, Ryan Stone wrote: >=20 >> On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: >> Hi; >>=20 >> FWIW, I use a very old PC of the type where the processor will not be fix= ed >> by Intel and that still needs support for the traditional BIOS. I also >> bought a 3TB HD (they were easier to find that 2T). >>=20 >> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB a= nd >> will happily use ZFS for everything, however I want to dual boot so after= >> lots of testing I ended up ignoring 1 TB of HD :(. >>=20 >> It does happen that there is a really nice boot loader that could have sa= ved >> the day but it is very difficult to install standalone: >>=20 >> https://sourceforge.net/projects/cloverefiboot >>=20 >> Just in case someone has the time and inclination to play with it :) >>=20 >> Pedro. >=20 > Is the issue due to using MBR partitioning? FreeBSD supports booting > from a GPT partition from a traditional BIOS; you don't need EFI. Is > this machine so old that its BIOS doesn't support booting from GPT? > _______________________________________________ > 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-current@freebsd.org Wed Apr 11 17:22:11 2018 Return-Path: Delivered-To: freebsd-current@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 71C15F80EBD for ; Wed, 11 Apr 2018 17:22:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) 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 E73976B87E for ; Wed, 11 Apr 2018 17:22:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: by mailman.ysv.freebsd.org (Postfix) id AB665F80EBC; Wed, 11 Apr 2018 17:22:10 +0000 (UTC) Delivered-To: current@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 876F3F80EBA for ; Wed, 11 Apr 2018 17:22:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 005936B870; Wed, 11 Apr 2018 17:22:09 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback1g.mail.yandex.net (mxback1g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:162]) by forward106j.mail.yandex.net (Yandex) with ESMTP id 592A91805208; Wed, 11 Apr 2018 20:22:06 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback1g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id H0owce4wjd-M670Wi5t; Wed, 11 Apr 2018 20:22:06 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1523467326; bh=5ZxzL5LCA+IgK+DV9NFth0uYLt+dd0ji6McEu7tOxGk=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=p5JSfjM7Vv/u91s/JBb/uydpAxtyg5rBGXYGOCIsHUb3817o4WNi9hMTo2fqQNukS GX9XVobkBvAutPETlxv/8EmnWoa4rTUahCAqiy5BXc491sGKWv2/pIxLZh3uJoBHT3 5PjhyWxEgiWsRI+r1VWebPReZNgyG5tC1FSW/tMQ= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id MGtq9YZ7Eq-M5luihAp; Wed, 11 Apr 2018 20:22:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1523467325; bh=5ZxzL5LCA+IgK+DV9NFth0uYLt+dd0ji6McEu7tOxGk=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=hvgHegxxuhlMp1G9TY7b6DR6ZPSmt/4geMa5rTU7feJ4CpYY0pNxK5VrZWEetifiZ mptTolLqYaf2PRuFBqmbIytrsJIltiIJKJC5hq1kc+O/hZ4eE5SYwJ7VhWqqHKR0l+ wd3PIRcAyUexUTQVtJZUCqpTjZSLnPf83czXUqXI= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 To: Mark Johnston , David Wolfskill , current@freebsd.org Cc: shurd@FreeBSD.org References: <20180411113958.GE1134@albert.catwhisker.org> <20180411170228.GB43015@raichu> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: Date: Wed, 11 Apr 2018 20:20:02 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180411170228.GB43015@raichu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qJBLYWayJ1xJiZnsBsFiJaTnW16QVmVKM" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:22:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qJBLYWayJ1xJiZnsBsFiJaTnW16QVmVKM Content-Type: multipart/mixed; boundary="BvgccH2jYgAKmEnxjzbbXwiMEz9OqIprT"; protected-headers="v1" From: "Andrey V. Elsukov" To: Mark Johnston , David Wolfskill , current@freebsd.org Cc: shurd@FreeBSD.org Message-ID: Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 References: <20180411113958.GE1134@albert.catwhisker.org> <20180411170228.GB43015@raichu> In-Reply-To: <20180411170228.GB43015@raichu> --BvgccH2jYgAKmEnxjzbbXwiMEz9OqIprT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11.04.2018 20:02, Mark Johnston wrote: >> It appears that r332389 is implicated. >=20 > I'm seeing this too, under bhyve with e1000 emulation. Reverting r33238= 9 > fixes the problem. I have this problem too. And reverting r332389 fixes it. em0@pci0:0:25:0: class=3D0x020000 card=3D0x20088086 chip=3D0x15028086 rev= =3D0x04 hdr=3D0x00 --=20 WBR, Andrey V. Elsukov --BvgccH2jYgAKmEnxjzbbXwiMEz9OqIprT-- --qJBLYWayJ1xJiZnsBsFiJaTnW16QVmVKM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlrOQ8IACgkQAcXqBBDI oXo6jAgAk/FiW8m/I8TK/2aECsJkPOqvR+czPWgrofQwMTn6vYMkatH3i8zrGU2o I6MBpHv2k1EOtlJk3dn82s68jt4V7NoPA/BhUBNyk/0BE1PseCb5I3f2q/aP4RfP HoHdxWbvExYfYFOP0nfcv+RtB2teVN8Iusktf5m3Pkihvy50byPLptC2/V2TPDJT xRR0IBmTov+lRAZFmPJdJXSzzOGC69YZuEGB953Oq0SlGAeb9lpBm1ojLKmip2uH CQzHF9oUrx3j7xOyM3yfvp0hDG1r4yCpNppI1KQZ3kwQnQfZY3PIWmb48U6RWYqC bHPmZglqTRT2HsLoRuepCi88N+0liA== =75M1 -----END PGP SIGNATURE----- --qJBLYWayJ1xJiZnsBsFiJaTnW16QVmVKM-- From owner-freebsd-current@freebsd.org Wed Apr 11 17:24:40 2018 Return-Path: Delivered-To: freebsd-current@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 91C6AF811BF for ; Wed, 11 Apr 2018 17:24:40 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 25F0F6BC84 for ; Wed, 11 Apr 2018 17:24:40 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D0F46F811BD; Wed, 11 Apr 2018 17:24:39 +0000 (UTC) Delivered-To: current@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 AEAE9F811BB for ; Wed, 11 Apr 2018 17:24:39 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 443386BC82 for ; Wed, 11 Apr 2018 17:24:39 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id u84-v6so2464574oie.10 for ; Wed, 11 Apr 2018 10:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=c8aH9qG/Olqs9OXn15BfOMsa68TjU8TmmWv1Ootm8OQ=; b=sG2fVsc+xDwvoxCTgRRa5fYMqFdYwZjZ+gVOTTnj6bN/elyZTKvB6XI0DxdEKtHgaL /SPYgHz1zHOpKJNAqRmn5D2dMkw+Jeyn4oE1U4HpaoSMzJqUxStIUlfpQ2dElOHOHrmb YR3I37ZVUkdKO8fmQs+BmxTcuYiDNt6qk4dwwHY3obt+E/dRd1dpqgPfjpjotZ1SNxTL 7o7G16+CmgON66sCSULUn6fKdyapJ8DRkV25t7LNNEDLI1LU9wHBIx82gNY26prB2Nn/ bh31vShcx9goB0b5grD2nPaZxd92KN8lFXM6frvkoVRwk8haysj6z2oRSJrr0ffRUNXw 32ew== 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=c8aH9qG/Olqs9OXn15BfOMsa68TjU8TmmWv1Ootm8OQ=; b=g5FeDcQAMZ7LVV8EERfWG1+ZvZ3MuAJAludkHarSkvesQpKDrjSISG8EJ4I+krGOey VE8zTQQVW0pMcvArbjpGcwC1eYgWnbopV6RHqzrvMiMS9dLDH6aYztoJS9KFCXnjBk1M RjlDz/vm+KlUuw1IIb7U5Mo8nUgbaiqI33VZhQjytLJrMIWUD/mxjq+rWx77k5t4WIwT LPao0MtQXN8OEV8QdJgoD+cmcd6VZgFxcqRFvy5xfWpC7Fc0d+SPK9gwuZRjoSCakJ/z i5MC4XWiotH/RAld8Ou/eC9j9GVUVHf7nefCUIcE3KmL5mZcB0A6awLUo3c45RlsNUVp MRgQ== X-Gm-Message-State: ALQs6tD+9OksU3A48cMXGx5rKopkgPiekWXwebFNyjaNGueTeqw7VtrE k4MVtLptw9ck1z1rAwcdiTqRHB85b3qQINU88FnbOPmr X-Google-Smtp-Source: AIpwx4+1B3CCbXLTikcJMLZEy2nH/y/2ELQtqRC7dv2LVZjiHbzLhkDpftx8ilvCRdOhGSKVqAInkb/x7UaINqn6LY0= X-Received: by 2002:aca:121a:: with SMTP id 26-v6mr3763519ois.250.1523467478469; Wed, 11 Apr 2018 10:24:38 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 2002:a9d:4782:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 10:24:38 -0700 (PDT) In-Reply-To: <20180411113958.GE1134@albert.catwhisker.org> References: <20180411113958.GE1134@albert.catwhisker.org> From: "K. Macy" Date: Wed, 11 Apr 2018 10:24:38 -0700 X-Google-Sender-Auth: 0kaCMfpYv-VcyxHXXs-hhImA-e4 Message-ID: Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:24:40 -0000 Sorry about that. It looks like my review must have been missing a line. @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx) _iflib_assert(sctx); - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); - + CTX_LOCK_INIT(ctx); + STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER); if (ifp == NULL) { device_printf(dev, "can not allocate ifnet structure\n"); @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void *uniq, int cpu, char *name) } void On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill wrote: > This was running: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > during boot, after updating from: > > FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 > > (My build machine, which uses an re((4) NIC, did not encounter the issue.) > > It appears that r332389 is implicated. > > ... > Unread portion of the kernel message buffer: > > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361 > #2 0xffffffff80433f4c in db_fncall_generic (addr=, > rv=, nargs=, args=) > at /usr/src/sys/ddb/db_command.c:609 > #3 db_fncall (dummy1=, dummy2=, > dummy3=, dummy4=) > at /usr/src/sys/ddb/db_command.c:657 > #4 0xffffffff80433a99 in db_command (last_cmdp=, > cmd_table=, dopager=) > at /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff80433814 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff80436a3f in db_trap (type=, code=) > at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80b753e3 in kdb_trap (type=3, code=-61456, tf=) > at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff80f7eaa8 in trap (frame=0xfffffe00004377a0) > at /usr/src/sys/amd64/amd64/trap.c:548 > #9 > #10 kdb_enter (why=0xffffffff811df9d4 "panic", msg=) > at /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80b2feda in vpanic (fmt=, ap=0xfffffe0000437910) > at /usr/src/sys/kern/kern_shutdown.c:826 > #12 0xffffffff80b2fca0 in kassert_panic ( > fmt=0xffffffff811dadca "mtx_lock() of spin mutex %s @ %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:723 > #13 0xffffffff80b0ec93 in __mtx_lock_flags (c=0xfffff80008c85d88, opts=0, > file=0xffffffff81113c90 "/usr/src/sys/net/iflib.c", line=) > at /usr/src/sys/kern/kern_mutex.c:246 > #14 0xffffffff80c466e1 in _task_fn_admin (context=0xfffff80008c85c00) > at /usr/src/sys/net/iflib.c:3716 > #15 0xffffffff80b73849 in gtaskqueue_run_locked (queue=0xfffff80008489500) > at /usr/src/sys/kern/subr_gtaskqueue.c:331 > #16 0xffffffff80b735c8 in gtaskqueue_thread_loop (arg=) > at /usr/src/sys/kern/subr_gtaskqueue.c:506 > #17 0xffffffff80af0064 in fork_exit ( > callout=0xffffffff80b73540 , > arg=0xfffffe0844223008, frame=0xfffffe0000437ac0) > at /usr/src/sys/kern/kern_fork.c:1039 > #18 > (kgdb) > > If the dump would be useful, I can put it up for access. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Well, what did you EXPECT from Trump? He has a history of breaking promises. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Wed Apr 11 17:26:39 2018 Return-Path: Delivered-To: freebsd-current@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 27662F814D2 for ; Wed, 11 Apr 2018 17:26:39 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AF8116BE11 for ; Wed, 11 Apr 2018 17:26:38 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6654CF814CB; Wed, 11 Apr 2018 17:26:38 +0000 (UTC) Delivered-To: current@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 415F2F814CA for ; Wed, 11 Apr 2018 17:26:38 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C63276BE0E for ; Wed, 11 Apr 2018 17:26:37 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ot0-x22d.google.com with SMTP id v64-v6so2866159otb.13 for ; Wed, 11 Apr 2018 10:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=G/WkMEqPGg9hktx7A9d5QZn6HXWiQgRE0l3stFFldbw=; b=bi65dYbKFkBX6JHoA6anA+U0MrsGzzGLPojbPGKwzupwN8CGFmy4vkjW1dO+Dwq1MZ 88s0caruw5cSRRqO9o6RI1VLlM7TNJssTbQG2Jpx9PUN/uhmYhdXcm6ceBaUYzYqK2ZD de86XTxXOUIclGMCqd8FOXH4JVRoka/bPR99IqyRkMQX9OdRqymCXIjLsUllH0tfx064 piBaOK4sLuXXhXEUGhOevVI9XLgXtsHygBMxJsIhzj4PaSyI7EnQ6rtlr1kXfAx7p2Pf BNmqNw8DJ/y5A/u2ZeJuizJc9a3hbxZwVGmIJHYTaSh1RZxnU/lAkXV7A3vNI/6++1tn WYhw== 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=G/WkMEqPGg9hktx7A9d5QZn6HXWiQgRE0l3stFFldbw=; b=LjaHfRv3+DX8vnja+f2REdjZ58bV1cjFTVlm+sSDaHeCzz3SoiU+OiiDztlIhx94s2 1sEXGPylYFqNyIfPA0vIUzNddlAPWYANVFvOSXhWB91DaIwOMy1m4+2HW7eyBpuDJrbD H6Z395oujb6QJ2RfbbudUOXysW4w4GBOUnk7qukLEKTsvGZwUoO2dSKjtgn7PWl8gjIa JeWvfh0qFKKPZWHfMCMz/VLxHe1X2B6gpBXx2XI1KuNKlZiXGu/FEOUW36mJ/Bw+5V0n zZUeK7BdE/PHc7LPFkDS28dOQg/Ow2CeozYbIIBsZ9g7dYMo0lHaMTQku1yvkDC8mHsd eq5A== X-Gm-Message-State: ALQs6tBKwx69wEIeUaZQQIV/02HwnrxyAzjVdfPcw483yP9UWWrQ3/Y8 8rKJRapDtr7dRdROaBv3cWT2PMJ5jOn80x3B85pLZg== X-Google-Smtp-Source: AIpwx49Sx+K0hA9yHmgctPUJLnitrU6xdRJOQKc4D/lr/n+nFSw3C+ydNdtzB3E+mxoGWATADzgj5Ki/uCKRpPlgz9M= X-Received: by 2002:a9d:4082:: with SMTP id n2-v6mr3558151ote.150.1523467597098; Wed, 11 Apr 2018 10:26:37 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 2002:a9d:4782:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 10:26:36 -0700 (PDT) In-Reply-To: References: <20180411113958.GE1134@albert.catwhisker.org> From: "K. Macy" Date: Wed, 11 Apr 2018 10:26:36 -0700 X-Google-Sender-Auth: 48rUM21RmFpuc2GQbAkDCRkXI4Y Message-ID: Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:26:39 -0000 Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line. -M On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wrote: > Sorry about that. It looks like my review must have been missing a line. > > @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx) > > _iflib_assert(sctx); > > - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); > - > + CTX_LOCK_INIT(ctx); > + STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); > ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER); > if (ifp == NULL) { > device_printf(dev, "can not allocate ifnet structure\n"); > @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void > *uniq, int cpu, char *name) > } > > void > > On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill wrote: >> This was running: >> >> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 >> >> during boot, after updating from: >> >> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 >> >> (My build machine, which uses an re((4) NIC, did not encounter the issue.) >> >> It appears that r332389 is implicated. >> >> ... >> Unread portion of the kernel message buffer: >> >> __curthread () at ./machine/pcpu.h:230 >> 230 __asm("movq %%gs:%1,%0" : "=r" (td) >> (kgdb) #0 __curthread () at ./machine/pcpu.h:230 >> #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361 >> #2 0xffffffff80433f4c in db_fncall_generic (addr=, >> rv=, nargs=, args=) >> at /usr/src/sys/ddb/db_command.c:609 >> #3 db_fncall (dummy1=, dummy2=, >> dummy3=, dummy4=) >> at /usr/src/sys/ddb/db_command.c:657 >> #4 0xffffffff80433a99 in db_command (last_cmdp=, >> cmd_table=, dopager=) >> at /usr/src/sys/ddb/db_command.c:481 >> #5 0xffffffff80433814 in db_command_loop () >> at /usr/src/sys/ddb/db_command.c:534 >> #6 0xffffffff80436a3f in db_trap (type=, code=) >> at /usr/src/sys/ddb/db_main.c:250 >> #7 0xffffffff80b753e3 in kdb_trap (type=3, code=-61456, tf=) >> at /usr/src/sys/kern/subr_kdb.c:697 >> #8 0xffffffff80f7eaa8 in trap (frame=0xfffffe00004377a0) >> at /usr/src/sys/amd64/amd64/trap.c:548 >> #9 >> #10 kdb_enter (why=0xffffffff811df9d4 "panic", msg=) >> at /usr/src/sys/kern/subr_kdb.c:479 >> #11 0xffffffff80b2feda in vpanic (fmt=, ap=0xfffffe0000437910) >> at /usr/src/sys/kern/kern_shutdown.c:826 >> #12 0xffffffff80b2fca0 in kassert_panic ( >> fmt=0xffffffff811dadca "mtx_lock() of spin mutex %s @ %s:%d") >> at /usr/src/sys/kern/kern_shutdown.c:723 >> #13 0xffffffff80b0ec93 in __mtx_lock_flags (c=0xfffff80008c85d88, opts=0, >> file=0xffffffff81113c90 "/usr/src/sys/net/iflib.c", line=) >> at /usr/src/sys/kern/kern_mutex.c:246 >> #14 0xffffffff80c466e1 in _task_fn_admin (context=0xfffff80008c85c00) >> at /usr/src/sys/net/iflib.c:3716 >> #15 0xffffffff80b73849 in gtaskqueue_run_locked (queue=0xfffff80008489500) >> at /usr/src/sys/kern/subr_gtaskqueue.c:331 >> #16 0xffffffff80b735c8 in gtaskqueue_thread_loop (arg=) >> at /usr/src/sys/kern/subr_gtaskqueue.c:506 >> #17 0xffffffff80af0064 in fork_exit ( >> callout=0xffffffff80b73540 , >> arg=0xfffffe0844223008, frame=0xfffffe0000437ac0) >> at /usr/src/sys/kern/kern_fork.c:1039 >> #18 >> (kgdb) >> >> If the dump would be useful, I can put it up for access. >> >> Peace, >> david >> -- >> David H. Wolfskill david@catwhisker.org >> Well, what did you EXPECT from Trump? He has a history of breaking promises. >> >> See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Wed Apr 11 17:32:45 2018 Return-Path: Delivered-To: freebsd-current@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 B2587F81F54 for ; Wed, 11 Apr 2018 17:32:45 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3212A6CE03 for ; Wed, 11 Apr 2018 17:32:45 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E71DBF81F53; Wed, 11 Apr 2018 17:32:44 +0000 (UTC) Delivered-To: current@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 C023FF81F52 for ; Wed, 11 Apr 2018 17:32:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E15E6CDF5 for ; Wed, 11 Apr 2018 17:32:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by mail-ot0-x232.google.com with SMTP id m22-v6so2894566otf.8 for ; Wed, 11 Apr 2018 10:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=AYxvebcih2VGiaEHnKkf09W8/PJmtclXx6xfZyXEIXI=; b=ZEVfM0p5O+ERuuI4X2pOeQPQ+mgXzJ0js/Kr+OrDdBDZUhqd3cd5u3+BE1OEBnOFgz gRPGIk6hKxjsDqcncTHhPHX0tgrXMpUXY1M8pdiDUtGegiCtAp4VtFgRkqThnZmPMj+0 GSjBnB902UxU9wsAJNfCHJf28LvRZSg2uLFsaK3RtYJqeffduHA5wOYbuYUlzbFCF0A0 PBAi3m/Czm7iNEFklU1x6HZQhvwnL2czwihJMnVgJu0MNx4c6BvMJdAnGbjh/z/LvvqQ PUUSankFO5fW2kVlvQ9XY8hQ8oQNKvBp3bFtWmrJmkhIJOMMqejI0BI6+10FU7zQn1Ea OE+A== 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=AYxvebcih2VGiaEHnKkf09W8/PJmtclXx6xfZyXEIXI=; b=nhPHX4+C7rtnzDW/pUJf0oIQNCx7K1tYjDVPBZXk4RSSbd3x/cgEJ+u6vpvnVQzzrV p0f4j6TXPzF+JpWHKVZr+iYZXr9+FqyFIVks5eBbCi9HoRkjB0g9rwR7FMZOqtcbTEkm dJxqxxw9OShI5RnH9SLvUqP+4qwjD6swmaSJpxw60AW4rpibbftqar8TfkYWM/HlUHUl j/WVDx4H7dCAahU/sz1wOSCE9b42OcqIk2fvPyZGZEaKfnl+ezqpG154ij4WVHjLBEHK oHQTM4NTDdt8KpQPWx4Sf6YzaBlSPHIeDIlqyuhubSmek8qhYCfLbdVhNH12Hoy+vM4k /TrA== X-Gm-Message-State: ALQs6tDKzl5NvCUe5v0TAPt47NAviGRV/QABRWunDRJYsU4ikhhTUNG2 e5cVUExTCQZKNdIQ13GB5/2srhGcHbaFvGNNdWE= X-Google-Smtp-Source: AIpwx48GKLhAJAZQqeBGZ9UFD6KtgAxUPr9Ji4ppFCdD4mGZBBlIe4zX/FWKoEqIHDE6sT8b6NLoCHxcCBtDt5ntGo0= X-Received: by 2002:a9d:4a77:: with SMTP id d52-v6mr2887532otj.136.1523467963559; Wed, 11 Apr 2018 10:32:43 -0700 (PDT) MIME-Version: 1.0 Sender: kmacybsd@gmail.com Received: by 2002:a9d:4782:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 10:32:42 -0700 (PDT) In-Reply-To: References: <20180411113958.GE1134@albert.catwhisker.org> From: "K. Macy" Date: Wed, 11 Apr 2018 10:32:42 -0700 X-Google-Sender-Auth: Gg8BKreWXm6W4oAUNUEDs_VN3lQ Message-ID: Subject: Re: panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/net/iflib.c:3716 To: David Wolfskill , current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 17:32:45 -0000 Chalk another review fail up to shuffling patches between git and phab. Sorry for the inconvenience. -M On Wed, Apr 11, 2018 at 10:26 AM, K. Macy wrote: > Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line. > -M > > On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wrote: >> Sorry about that. It looks like my review must have been missing a line. >> >> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx) >> >> _iflib_assert(sctx); >> >> - CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); >> - >> + CTX_LOCK_INIT(ctx); >> + STATE_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev)); >> ifp = ctx->ifc_ifp = if_gethandle(IFT_ETHER); >> if (ifp == NULL) { >> device_printf(dev, "can not allocate ifnet structure\n"); >> @@ -5430,8 +5435,8 @@ iflib_io_tqg_attach(struct grouptask *gt, void >> *uniq, int cpu, char *name) >> } >> >> void >> >> On Wed, Apr 11, 2018 at 4:39 AM, David Wolfskill wrote: >>> This was running: >>> >>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #156 r332399M/332400:1200061: Wed Apr 11 04:17:45 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 >>> >>> during boot, after updating from: >>> >>> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #155 r332354M/332357:1200061: Tue Apr 10 04:00:41 PDT 2018 root@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 >>> >>> (My build machine, which uses an re((4) NIC, did not encounter the issue.) >>> >>> It appears that r332389 is implicated. >>> >>> ... >>> Unread portion of the kernel message buffer: >>> >>> __curthread () at ./machine/pcpu.h:230 >>> 230 __asm("movq %%gs:%1,%0" : "=r" (td) >>> (kgdb) #0 __curthread () at ./machine/pcpu.h:230 >>> #1 doadump (textdump=3) at /usr/src/sys/kern/kern_shutdown.c:361 >>> #2 0xffffffff80433f4c in db_fncall_generic (addr=, >>> rv=, nargs=, args=) >>> at /usr/src/sys/ddb/db_command.c:609 >>> #3 db_fncall (dummy1=, dummy2=, >>> dummy3=, dummy4=) >>> at /usr/src/sys/ddb/db_command.c:657 >>> #4 0xffffffff80433a99 in db_command (last_cmdp=, >>> cmd_table=, dopager=) >>> at /usr/src/sys/ddb/db_command.c:481 >>> #5 0xffffffff80433814 in db_command_loop () >>> at /usr/src/sys/ddb/db_command.c:534 >>> #6 0xffffffff80436a3f in db_trap (type=, code=) >>> at /usr/src/sys/ddb/db_main.c:250 >>> #7 0xffffffff80b753e3 in kdb_trap (type=3, code=-61456, tf=) >>> at /usr/src/sys/kern/subr_kdb.c:697 >>> #8 0xffffffff80f7eaa8 in trap (frame=0xfffffe00004377a0) >>> at /usr/src/sys/amd64/amd64/trap.c:548 >>> #9 >>> #10 kdb_enter (why=0xffffffff811df9d4 "panic", msg=) >>> at /usr/src/sys/kern/subr_kdb.c:479 >>> #11 0xffffffff80b2feda in vpanic (fmt=, ap=0xfffffe0000437910) >>> at /usr/src/sys/kern/kern_shutdown.c:826 >>> #12 0xffffffff80b2fca0 in kassert_panic ( >>> fmt=0xffffffff811dadca "mtx_lock() of spin mutex %s @ %s:%d") >>> at /usr/src/sys/kern/kern_shutdown.c:723 >>> #13 0xffffffff80b0ec93 in __mtx_lock_flags (c=0xfffff80008c85d88, opts=0, >>> file=0xffffffff81113c90 "/usr/src/sys/net/iflib.c", line=) >>> at /usr/src/sys/kern/kern_mutex.c:246 >>> #14 0xffffffff80c466e1 in _task_fn_admin (context=0xfffff80008c85c00) >>> at /usr/src/sys/net/iflib.c:3716 >>> #15 0xffffffff80b73849 in gtaskqueue_run_locked (queue=0xfffff80008489500) >>> at /usr/src/sys/kern/subr_gtaskqueue.c:331 >>> #16 0xffffffff80b735c8 in gtaskqueue_thread_loop (arg=) >>> at /usr/src/sys/kern/subr_gtaskqueue.c:506 >>> #17 0xffffffff80af0064 in fork_exit ( >>> callout=0xffffffff80b73540 , >>> arg=0xfffffe0844223008, frame=0xfffffe0000437ac0) >>> at /usr/src/sys/kern/kern_fork.c:1039 >>> #18 >>> (kgdb) >>> >>> If the dump would be useful, I can put it up for access. >>> >>> Peace, >>> david >>> -- >>> David H. Wolfskill david@catwhisker.org >>> Well, what did you EXPECT from Trump? He has a history of breaking promises. >>> >>> See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Wed Apr 11 18:27:59 2018 Return-Path: Delivered-To: freebsd-current@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 BC048F86197 for ; Wed, 11 Apr 2018 18:27:59 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from sonic301-18.consmr.mail.bf2.yahoo.com (sonic301-18.consmr.mail.bf2.yahoo.com [74.6.129.57]) (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 5EF5B7A4B1 for ; Wed, 11 Apr 2018 18:27:58 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1523471278; bh=iRC9dKlhfrXhBnDXvzYMCPxLuOL2QvAxCzSiYInSEno=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=VHfbL29ZA1m9kxqU2DKF3lungpYZyAtECpoqGNGuBTMTYEjw1Y8EV60OmQ5v9M+Rrex3dbsn/9SBb39ZS+xmiCfd15dTn8hPXXv2r/Iusgu/A6vcCrqA7nuqIJRaMzqxsATNK1Wh+KtjC980nXNsHvH4MVFY2c1rxQNLooGFVSPRnLjQWyjglToecKGevrR1Ho6vR+XVyvzKxH+mGdU6ni6nOzuSSdU0vF1ug9Tv0pi0nkZAHBjIfoSwcsfmfixSp1z7PYCU/qbgXGjJcd2HM+fz3WDCKOtNclnkeV8GvlXRPYgjpCEn0vies5vSW8V6cXKiy8UOf95n82BOh+w79A== X-YMail-OSG: VYZt.DMVM1n8Bclgjt_g.3eUIJ5kSADBe_mU6iKzxW7P4RvU9LulCmMSnO20vqe fm1fxYg3xPZ5KsIT.RGrogTYFh5b45_79cLStHYf159Xwn09rkkGBFg2__P_sdlujyDnIySqwSIr LKG2xsF0CnuOzlB54dxnKkeXRDHkfPguUEasJqgYJWEHCl17IzlVMIY.mozuOIlSm1lVDg5DjrOQ wlhT4N.67qNpwQHAA5RecuTUFe_bspQRwSrxwm1NnFXHsBOZQ3ekgaitoJF50XEt2ctqibIjnsb1 c32dgdgfEkgieyZ8KMtu0_gEAyJCQ2T2yb1mi8kKq6HOeWuvegHh.5xMrvUR3auX8CVQDsrc1Kac HEBvhGmN3p4Kw2NcjjgpwV0PX0nNtusn1Dl8qm4p8tYI6A8ha64JIr.UGgAj9IVprk_suFV73pfg J0YA29Ui2_aBlBIBzkJbUvUFp9UKSFs9eZL9YRpg_oqVE2rUrk5NBW0.Ic1x5D0jMSbIGOK_JUHD SfrNHy0bi9g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Wed, 11 Apr 2018 18:27:58 +0000 Received: from 181.52.72.201 (EHLO [192.168.0.6]) ([181.52.72.201]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6d07f456b6d0203c75f304b27aa30d9a; Wed, 11 Apr 2018 18:17:49 +0000 (UTC) Subject: Re: CloverEFIBoot (was Re: Call for Testing: UEFI Changes) To: Lucas Holt , Ryan Stone Cc: FreeBSD Current References: <4730997e-bd13-b87f-276f-875a06a26383@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Project Message-ID: <43f04b08-aecd-37d8-8135-e449d7726fb7@FreeBSD.org> Date: Wed, 11 Apr 2018 13:17:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 18:28:00 -0000 On 11/04/2018 11:53, Lucas Holt wrote: > Machines don’t need to be old to have issues. I have a two year old asus am3+ board that cant boot from gpt without secure boot enabled and is hard coded for Microsoft keys > > Lucas Holt Interesting. Not sure Clover would help there though, secure boot is a  different issue: https://wiki.freebsd.org/SecureBoot Cheers, Pedro. >> On Apr 11, 2018, at 12:04 PM, Ryan Stone wrote: >> >>> On Wed, Apr 11, 2018 at 11:14 AM, Pedro Giffuni wrote: >>> Hi; >>> >>> FWIW, I use a very old PC of the type where the processor will not be fixed >>> by Intel and that still needs support for the traditional BIOS. I also >>> bought a 3TB HD (they were easier to find that 2T). >>> >>> If I leave the disk dedicated to FreeBSD it recognizes the complete 3TB and >>> will happily use ZFS for everything, however I want to dual boot so after >>> lots of testing I ended up ignoring 1 TB of HD :(. >>> >>> It does happen that there is a really nice boot loader that could have saved >>> the day but it is very difficult to install standalone: >>> >>> https://sourceforge.net/projects/cloverefiboot >>> >>> Just in case someone has the time and inclination to play with it :) >>> >>> Pedro. >> Is the issue due to using MBR partitioning? FreeBSD supports booting >> from a GPT partition from a traditional BIOS; you don't need EFI. Is >> this machine so old that its BIOS doesn't support booting from GPT? >> _______________________________________________ >> 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-current@freebsd.org Wed Apr 11 19:03:18 2018 Return-Path: Delivered-To: freebsd-current@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 78917F88A04 for ; Wed, 11 Apr 2018 19:03:18 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yb0-x244.google.com (mail-yb0-x244.google.com [IPv6:2607:f8b0:4002:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13E2D8207B for ; Wed, 11 Apr 2018 19:03:18 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yb0-x244.google.com with SMTP id e5-v6so991196ybq.13 for ; Wed, 11 Apr 2018 12:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L31UgdJ4ZyrDouXDfVchAopxj4sqlRD7qC8WjsfjxTk=; b=CkVcbOfbXtnzsC+U1LZQtm4bf2U26CpJaW6Dr1J/Rp8ZpUkhAJG852GanPhEFDPXmt ZpMRylvD6OCk1Rzpw2QduE5MfVEySEMrtdfdq1Vz5oDYL096877k91KCWXMcpEjoglAe v50nI8FKq1FkAJmk2axLHBlKQ47pXtpurG6lyP+08KOkBPKwizCLAgf82JArZLUAXY/4 LZVNMwvUh8gRhUjvuRwZ6hbDFokFZvUZiVvP3E98hzQ4Wt87jX67xY1kkrztfPrVudEw o2u8rPQTqvmtCrS/Xk+l6+zdsj0Bh80ThDKHAzeam1orMhWrMoxMTdcjkCJ5eZYfkGQ5 95dg== 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=L31UgdJ4ZyrDouXDfVchAopxj4sqlRD7qC8WjsfjxTk=; b=aBNRpilOShztW/DJPCuhIX/DbN3tyiXvuVZYJ46r/hA9ylz6AaQzzJpFujgg5fYVPL Dvq9nVgXXahReJo6UoGVkAeN+BSnI4vYXuf3GIOXGPwdgzFYIyuk0i4eqEmI3TsZP8Qi GioSyHWU7CmBKFCtu1egTLBsNkZy1qT8AJ3MuXrTF+qEe2wbk61r33mUo8YlTDcdeaum 2kVc+ufdH/U0vHob7wGBJLezM2EoQRrmVyj1SDm9lnY9wJwTApBHzOVtMdgCP+GkNpeR A9f5qKi3+Yploxd2KY1D4H/8JtqdcEOn732ZtIalYT79pIYptfuzku4oGG/UcpOlzcVj NEDw== X-Gm-Message-State: ALQs6tAfo0eJoRfbQutZasP7gnamDXXyEMTO3F2g6LT67o+eFOFM3PHZ XSrr2+Jk3vvEeAtgDs8QMagMo1i5/PFmb+jtmt4K4Q== X-Google-Smtp-Source: AIpwx49imRgpVzX1QSjSq49DXvTNspcMEvxjMIwAHHHxIi3DKOLSd+EP3leIAwlwMshYGlwOIY04KKP2Cvrs0MT/1wQ= X-Received: by 2002:a25:dc53:: with SMTP id y80-v6mr2831310ybe.331.1523473397437; Wed, 11 Apr 2018 12:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:ae64:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 12:03:16 -0700 (PDT) In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Oliver Pinter Date: Wed, 11 Apr 2018 21:03:16 +0200 Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Warner Losh , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:03:18 -0000 Hi! Is there any update regarding the rebase or the inclusion to base system? On 3/28/18, Eric McCorkle wrote: > I'll do another rebase from head just to be sure > > On March 28, 2018 3:23:23 PM EDT, Warner Losh wrote: >>It's on my list for nexr, finally. I have an alternate patch for >>loader.efi >>from ESP, but i don't think it will affect the GELI stuff. I have some >>time >>slotted for integration issues though. >> >>I am quite mindful of the freeze dates.... I have some uefi boot >>loader >>protocol changes that I need to get in. >> >>Warner >> >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrote: >> >>> Awesome, thanks for the update and the work that you have done! >>> >>> Now we just need some more reviewers eyes on the code :) >>> >>> Br, >>> >>> Tommi >>> >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle >>wrote: >>> >>>> FYI, I just IFC'ed everything, and the current patches are still >>fine. >>>> >>>> Also, the full GELI + standalone loader has been deployed on one of >>my >>>> laptops for some time now. >>>> >>>> On 02/21/2018 18:15, Eric McCorkle wrote: >>>> > The GELI work could be merged at this point, though it won't be >>usable >>>> > without an additional patch to enable loader-only operation. The >>>> > patches are currently up for review: >>>> > >>>> > This is the order in which they'd need to be merged: >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12732 >>>> > >>>> > This one changes the efipart device. Toomas Soome identified some >>>> > problems, which I have addressed. He has not re-reviewed it, >>however. >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12692 >>>> > >>>> > This adds some crypto code needed for GELI. It simply adds new >>code, >>>> > and doesn't conflict with anything. >>>> > >>>> > >>>> > https://reviews.freebsd.org/D12698 >>>> > >>>> > This adds the EFI KMS interface code, and has the EFI loader pass >>keys >>>> > into the keybuf interface. >>>> > >>>> > >>>> > I can't post the main GELI driver until those get merged, as it >>depends >>>> > on them. It can be found on the geli branch on my github freebsd >>>> > repository, however. >>>> > >>>> > >>>> > Additionally, you need this patch, which allows loader.efi to >>function >>>> > when installed directly to the ESP: >>>> > >>>> > https://reviews.freebsd.org/D13497 >>>> > >>>> > On 02/20/2018 22:56, Tommi Pernila wrote: >>>> >> Hi Eric, >>>> >> >>>> >> could you provide a brief update how the work is going? >>>> >> >>>> >> >>>> >> Br, >>>> >> >>>> >> Tommi >>>> >> >>>> >> >>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >>> >> > wrote: >>>> >> >>>> >> Right, so basically, the remaining GELI patches are against >>>> loader, and >>>> >> most of them can go in independently of the work on removing >>boot1. >>>> >> There's a unanimous consensus on getting rid of boot1 which >>>> includes its >>>> >> original author, so that's going to happen. >>>> >> >>>> >> >>>> >> For GELI, we have the following (not necessarily in order): >>>> >> >>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel >>keybuf >>>> >> interactions >>>> >> b) Modifications to the efipart driver >>>> >> c) boot crypto >>>> >> d) GELI partition types (not strictly necessary) >>>> >> >>>> >> Then there's the GELI driver itself. (a) and (c) are good to >>>> land, (b) >>>> >> needs some more work after Toomas Soome pointed out a >>legitimate >>>> >> problem, and (d) actually needs a good bit more code (but >>again, >>>> it's >>>> >> more cosmetic). Additionally, the GELI driver will need >>further >>>> mods to >>>> >> efipart to be written (nothing too big). But we could go >>ahead >>>> with (a) >>>> >> and (c), as they've already been proven to work. >>>> >> >>>> >> I'd wanted to have this stuff shaped up sooner, but I'm >>>> preoccupied with >>>> >> the 7th RISC-V workshop at the end of the month. >>>> >> >>>> >> Once this stuff is all in, loader should handle any GELI >>volumes it >>>> >> finds, and it should Just Work once boot1 is gone. >>>> >> >>>> >> >>>> > _______________________________________________ >>>> > 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" >>>> > >>>> >>> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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-current@freebsd.org Wed Apr 11 19:06:43 2018 Return-Path: Delivered-To: freebsd-current@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 54C2DF88E71 for ; Wed, 11 Apr 2018 19:06:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAF2482F5D for ; Wed, 11 Apr 2018 19:06:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id 142-v6so4158138itl.5 for ; Wed, 11 Apr 2018 12:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/SLwPxDPQXnWwMdqa1iXpwb24LSZlOWkVFYlPsBI7BQ=; b=0BFzAfBEUxlbOS/gMpEocMtm9dAGsjn665xGU58ZGgxOiA4D7J3QHniebWNSpgKfta Wn+vopiEqO27xmj9mhlwVwXYJEQqTRg9+v7AACrTTr98O+GZCriUrv2sRFeWo3Odxeot 4kRLCm46k3jfFTkOgQ13f7xuG2XFWG4jTJBl69s6T1Vm+DTLikPPZzhhHS354dLJqDlC peV6kOqH21pcM2ptr3N6QtKQQI76Kx7thEZKTje9Dq5AjxqEZB4W30L+12e2dsQk0Pn/ SQRoq4XlFXeNwjeMMJbrou6K6JHnOOUXPwBsF0DW4u57troShSEoaznsBZFQgiKZswFW 4DQg== 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:cc; bh=/SLwPxDPQXnWwMdqa1iXpwb24LSZlOWkVFYlPsBI7BQ=; b=NKtfAkgNnaeG8iJYYufu2AfkQF0sGPXjnPf93pyEMP651S4qHUV+6VIN36340i/CBr 1sVs+oXeSumsL7JVomfaIzlfvgGckdCrwqw+06kfJemSClduUfV8ye0uQD8IWDtWv4Ek lm7TDBXDu/bNxHaI/qZF5/rSVYsGgeW4YAcjiI+TbhuPNu4ZZfjZnayLfCRjh0qwc9d5 nUX4S/sojim/yqX61HCjsFkPHQj1lkFyUT7Ut3BwNADn8Thi33bsUMMwmySCgeO4rxxz 7SDa+Vp+xe+JIL+ylWYwMlQ0To/g766vgPdZWEfcQAbXrVZdb+fok+unTFmFwDsU6B6S 5Vow== X-Gm-Message-State: ALQs6tDfLP4dJAxlIQfSmShA9/w5FpmnrsIWMEjxdMGrZA1yGPYwRSGP /u94W0uSFcvmGEvRDGBrLNWQwAU/2DzdJmcZXb/axg== X-Google-Smtp-Source: AIpwx49OXu9RC1F4yOGGvLfUJOcrLZ+POPz/qfHFMEWJz4CYwePI4ebG8Eu9iQLLEiyZX6kim7K/yynHeHn0YO5z/Dg= X-Received: by 2002:a24:4286:: with SMTP id i128-v6mr5377435itb.73.1523473601963; Wed, 11 Apr 2018 12:06:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.166.4 with HTTP; Wed, 11 Apr 2018 12:06:41 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Warner Losh Date: Wed, 11 Apr 2018 13:06:41 -0600 X-Google-Sender-Auth: VB0KO18zIsw3HX1GaiNVNPWy98U Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Oliver Pinter Cc: Eric McCorkle , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 19:06:43 -0000 Still reviewing the code. I'm worried it's too i386 specific and it conflicts with some work I'm doing. I'll have a list of actionable critiques this week. Warner On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter < oliver.pinter@hardenedbsd.org> wrote: > Hi! > > Is there any update regarding the rebase or the inclusion to base system? > On 3/28/18, Eric McCorkle wrote: > > I'll do another rebase from head just to be sure > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh wrote: > >>It's on my list for nexr, finally. I have an alternate patch for > >>loader.efi > >>from ESP, but i don't think it will affect the GELI stuff. I have some > >>time > >>slotted for integration issues though. > >> > >>I am quite mindful of the freeze dates.... I have some uefi boot > >>loader > >>protocol changes that I need to get in. > >> > >>Warner > >> > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrote: > >> > >>> Awesome, thanks for the update and the work that you have done! > >>> > >>> Now we just need some more reviewers eyes on the code :) > >>> > >>> Br, > >>> > >>> Tommi > >>> > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle > >>wrote: > >>> > >>>> FYI, I just IFC'ed everything, and the current patches are still > >>fine. > >>>> > >>>> Also, the full GELI + standalone loader has been deployed on one of > >>my > >>>> laptops for some time now. > >>>> > >>>> On 02/21/2018 18:15, Eric McCorkle wrote: > >>>> > The GELI work could be merged at this point, though it won't be > >>usable > >>>> > without an additional patch to enable loader-only operation. The > >>>> > patches are currently up for review: > >>>> > > >>>> > This is the order in which they'd need to be merged: > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12732 > >>>> > > >>>> > This one changes the efipart device. Toomas Soome identified some > >>>> > problems, which I have addressed. He has not re-reviewed it, > >>however. > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12692 > >>>> > > >>>> > This adds some crypto code needed for GELI. It simply adds new > >>code, > >>>> > and doesn't conflict with anything. > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12698 > >>>> > > >>>> > This adds the EFI KMS interface code, and has the EFI loader pass > >>keys > >>>> > into the keybuf interface. > >>>> > > >>>> > > >>>> > I can't post the main GELI driver until those get merged, as it > >>depends > >>>> > on them. It can be found on the geli branch on my github freebsd > >>>> > repository, however. > >>>> > > >>>> > > >>>> > Additionally, you need this patch, which allows loader.efi to > >>function > >>>> > when installed directly to the ESP: > >>>> > > >>>> > https://reviews.freebsd.org/D13497 > >>>> > > >>>> > On 02/20/2018 22:56, Tommi Pernila wrote: > >>>> >> Hi Eric, > >>>> >> > >>>> >> could you provide a brief update how the work is going? > >>>> >> > >>>> >> > >>>> >> Br, > >>>> >> > >>>> >> Tommi > >>>> >> > >>>> >> > >>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >>>> >> > wrote: > >>>> >> > >>>> >> Right, so basically, the remaining GELI patches are against > >>>> loader, and > >>>> >> most of them can go in independently of the work on removing > >>boot1. > >>>> >> There's a unanimous consensus on getting rid of boot1 which > >>>> includes its > >>>> >> original author, so that's going to happen. > >>>> >> > >>>> >> > >>>> >> For GELI, we have the following (not necessarily in order): > >>>> >> > >>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel > >>keybuf > >>>> >> interactions > >>>> >> b) Modifications to the efipart driver > >>>> >> c) boot crypto > >>>> >> d) GELI partition types (not strictly necessary) > >>>> >> > >>>> >> Then there's the GELI driver itself. (a) and (c) are good to > >>>> land, (b) > >>>> >> needs some more work after Toomas Soome pointed out a > >>legitimate > >>>> >> problem, and (d) actually needs a good bit more code (but > >>again, > >>>> it's > >>>> >> more cosmetic). Additionally, the GELI driver will need > >>further > >>>> mods to > >>>> >> efipart to be written (nothing too big). But we could go > >>ahead > >>>> with (a) > >>>> >> and (c), as they've already been proven to work. > >>>> >> > >>>> >> I'd wanted to have this stuff shaped up sooner, but I'm > >>>> preoccupied with > >>>> >> the 7th RISC-V workshop at the end of the month. > >>>> >> > >>>> >> Once this stuff is all in, loader should handle any GELI > >>volumes it > >>>> >> finds, and it should Just Work once boot1 is gone. > >>>> >> > >>>> >> > >>>> > _______________________________________________ > >>>> > 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" > >>>> > > >>>> > >>> > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > > 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-current@freebsd.org Thu Apr 12 00:02:19 2018 Return-Path: Delivered-To: freebsd-current@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 E4479F9CA5A for ; Thu, 12 Apr 2018 00:02:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 62C2786ABD; Thu, 12 Apr 2018 00:02:18 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 63F899747; Thu, 12 Apr 2018 00:02:12 +0000 (UTC) Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Warner Losh , Oliver Pinter Cc: Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEWQXo2BYJKwYBBAHaRw8BAQdAYZJt/w5CCUvp4v5Mssy0JwiO21sDxKfa27YLD5uQVc60 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEE6eoVp0R+Jx2/f0Df5CP6Oqs6upgFAlkF6gcC GQEACgkQ5CP6Oqs6upiK5gEA2rdFpRnPct2O6IWIIkiiDSxVcQumGJNLpl5+wvjcOgsA/iHL kDE4v0RLg6w8b8KWzSJVFtim9Zoff66iUzkEVNQNtChFcmljIE1jQ29ya2xlIDxlcmljX21j Y29ya2xlQGtleWJhc2UuaW8+iJYEExYIAD4WIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWQXq AQIbAwUJAeEzgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDkI/o6qzq6mC1TAP49VcmC wwa0/X/jU8EeLCjFQL+3U1UvKKRaN7tvt8U76QD+IzjI3LoSWzc3F/Zqu+8NE/LSbzTbFezC f0VUJiuEhgu0K0VyaWMgTWNDb3JrbGUgPGVyaWNtY2NvcmtsZUBwcm90b25tYWlsLmNvbT6I lgQTFggAPhYhBOnqFadEficdv39A3+Qj+jqrOrqYBQJZLrJoAhsDBQkB4TOABQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEOQj+jqrOrqYAGsBANlpTq+GF+7N9o5iVkDwuuO7ZBFZlxsO CdA/dIhh3oBCAQC2ipgR/mE6eab1akzRa5PsEAHA/z3bDxLYtCZzCBXdBrg4BFkF6NgSCisG AQQBl1UBBQEBB0BXtYyAeWPqTL7aosi48FCkwH7+w17y3wMv2kCTLStqPgMBCAeIfgQYFggA JhYhBOnqFadEficdv39A3+Qj+jqrOrqYBQJZBejYAhsMBQkB4TOAAAoJEOQj+jqrOrqY2H8A /1tdtmFg6evmfC6Hf4+kTd76Dj+Kb7DfDyGrcYDy8cmuAQCGwHh+Za5U1zptnKCSgvKcjBgS EuvfTgXZTaIXaZOnBA== Message-ID: Date: Wed, 11 Apr 2018 20:02:08 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j6rsGUR5EYtrs6ssNwWRg2jQQpYzSHXaK" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 00:02:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j6rsGUR5EYtrs6ssNwWRg2jQQpYzSHXaK Content-Type: multipart/mixed; boundary="ztiM6EPjGKnm5abadnKD9yHa5yHRwthwq"; protected-headers="v1" From: Eric McCorkle To: Warner Losh , Oliver Pinter Cc: Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> In-Reply-To: --ztiM6EPjGKnm5abadnKD9yHa5yHRwthwq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I think the thing to do at this point is to wait for the current work on loader.efi to land, then adapt my patches to apply against that work. On 04/11/2018 15:06, Warner Losh wrote: > Still reviewing the code. I'm worried it's too i386 specific and it > conflicts with some work I'm doing. I'll have a list of actionable > critiques this week. >=20 > Warner >=20 > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > > wrote: >=20 > Hi! >=20 > Is there any update regarding the rebase or the inclusion to base > system? > On 3/28/18, Eric McCorkle > wrote: > > I'll do another rebase from head just to be sure > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh > wrote: > >>It's on my list for nexr, finally. I have an alternate patch for > >>loader.efi > >>from ESP, but i don't think it will affect the GELI stuff. I have= some > >>time > >>slotted for integration issues though. > >> > >>I am quite mindful of the freeze dates.... I=C2=A0 have some uefi= boot > >>loader > >>protocol changes that I need to get in. > >> > >>Warner > >> > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" > wrote: > >> > >>> Awesome, thanks for the update and the work that you have done!= > >>> > >>> Now we just need some more reviewers eyes on the code :) > >>> > >>> Br, > >>> > >>> Tommi > >>> > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle > > >>wrote: > >>> > >>>> FYI, I just IFC'ed everything, and the current patches are sti= ll > >>fine. > >>>> > >>>> Also, the full GELI + standalone loader has been deployed on o= ne of > >>my > >>>> laptops for some time now. > >>>> > >>>> On 02/21/2018 18:15, Eric McCorkle wrote: > >>>> > The GELI work could be merged at this point, though it won't= be > >>usable > >>>> > without an additional patch to enable loader-only operation.= =C2=A0 The > >>>> > patches are currently up for review: > >>>> > > >>>> > This is the order in which they'd need to be merged: > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12732 > > >>>> > > >>>> > This one changes the efipart device.=C2=A0 Toomas Soome iden= tified > some > >>>> > problems, which I have addressed.=C2=A0 He has not re-review= ed it, > >>however. > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12692 > > >>>> > > >>>> > This adds some crypto code needed for GELI.=C2=A0 It simply = adds new > >>code, > >>>> > and doesn't conflict with anything. > >>>> > > >>>> > > >>>> > https://reviews.freebsd.org/D12698 > > >>>> > > >>>> > This adds the EFI KMS interface code, and has the EFI loader= pass > >>keys > >>>> > into the keybuf interface. > >>>> > > >>>> > > >>>> > I can't post the main GELI driver until those get merged, as= it > >>depends > >>>> > on them.=C2=A0 It can be found on the geli branch on my gith= ub freebsd > >>>> > repository, however. > >>>> > > >>>> > > >>>> > Additionally, you need this patch, which allows loader.efi t= o > >>function > >>>> > when installed directly to the ESP: > >>>> > > >>>> > https://reviews.freebsd.org/D13497 > > >>>> > > >>>> > On 02/20/2018 22:56, Tommi Pernila wrote: > >>>> >> Hi Eric, > >>>> >> > >>>> >> could you provide a brief update how the work is going? > >>>> >> > >>>> >> > >>>> >> Br, > >>>> >> > >>>> >> Tommi > >>>> >> > >>>> >> > >>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" > >>>> >> >= > > wrote: > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0Right, so basically, the remaining GELI = patches are against > >>>> loader, and > >>>> >>=C2=A0 =C2=A0 =C2=A0most of them can go in independently of = the work on removing > >>boot1. > >>>> >>=C2=A0 =C2=A0 =C2=A0There's a unanimous consensus on getting= rid of boot1 which > >>>> includes its > >>>> >>=C2=A0 =C2=A0 =C2=A0original author, so that's going to happ= en. > >>>> >> > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0For GELI, we have the following (not nec= essarily in order): > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0a) Adding the KMS interfaces, pseudo-dev= ice, and kernel > >>keybuf > >>>> >>=C2=A0 =C2=A0 =C2=A0interactions > >>>> >>=C2=A0 =C2=A0 =C2=A0b) Modifications to the efipart driver > >>>> >>=C2=A0 =C2=A0 =C2=A0c) boot crypto > >>>> >>=C2=A0 =C2=A0 =C2=A0d) GELI partition types (not strictly ne= cessary) > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0Then there's the GELI driver itself.=C2=A0= (a) and (c) are > good to > >>>> land, (b) > >>>> >>=C2=A0 =C2=A0 =C2=A0needs some more work after Toomas Soome = pointed out a > >>legitimate > >>>> >>=C2=A0 =C2=A0 =C2=A0problem, and (d) actually needs a good b= it more code (but > >>again, > >>>> it's > >>>> >>=C2=A0 =C2=A0 =C2=A0more cosmetic).=C2=A0 Additionally, the = GELI driver will need > >>further > >>>> mods to > >>>> >>=C2=A0 =C2=A0 =C2=A0efipart to be written (nothing too big).= =C2=A0 But we could go > >>ahead > >>>> with (a) > >>>> >>=C2=A0 =C2=A0 =C2=A0and (c), as they've already been proven = to work. > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0I'd wanted to have this stuff shaped up = sooner, but I'm > >>>> preoccupied with > >>>> >>=C2=A0 =C2=A0 =C2=A0the 7th RISC-V workshop at the end of th= e month. > >>>> >> > >>>> >>=C2=A0 =C2=A0 =C2=A0Once this stuff is all in, loader should= handle any GELI > >>volumes it > >>>> >>=C2=A0 =C2=A0 =C2=A0finds, and it should Just Work once boot= 1 is gone. > >>>> >> > >>>> >> > >>>> > _______________________________________________ > >>>> > freebsd-current@freebsd.org > mailing list > >>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >>>> > To unsubscribe, send any mail to "freebsd-current-unsubscrib= e@ > >>>> freebsd.org " > >>>> > > >>>> > >>> > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevi= ty. > > _______________________________________________ > > 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 > " > > >=20 >=20 --ztiM6EPjGKnm5abadnKD9yHa5yHRwthwq-- --j6rsGUR5EYtrs6ssNwWRg2jQQpYzSHXaK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWs6iAwAKCRDkI/o6qzq6 mFpoAP98KbfVs4FCPI9ncl7DXRMHofYE4kIyLPPeediPPdKpdwD+K6jx2AfyhLlI hGNrVvoSXC3U2YsTk5E41g5cnP4T/Ac= =STKF -----END PGP SIGNATURE----- --j6rsGUR5EYtrs6ssNwWRg2jQQpYzSHXaK-- From owner-freebsd-current@freebsd.org Thu Apr 12 00:31:19 2018 Return-Path: Delivered-To: freebsd-current@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 EE5F3F9E9EB for ; Thu, 12 Apr 2018 00:31:18 +0000 (UTC) (envelope-from wlosh@bsdimp.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 G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 750F96C3DD for ; Thu, 12 Apr 2018 00:31:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id e79so4398964ioi.7 for ; Wed, 11 Apr 2018 17:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ONsVBvGNwox634wDoGa5e3zogNcZ6nG1LYNMetO3rB8=; b=yF/QV7M9q5k2IjxpRCASlCEPCSAS7zej/FYIMDZ+JE/33DpJRhstfCSxEBiOXMM1RX iTKUAfiFZwzv3VxfHKrQjbuZx9Kaioa2RO5V+7a0PwBh79LSNigbDfbnPlz5R5nW4uul wDXFVZW2Vi8Qhro7MqlzgToxTHyTPDJbqyCa5RTDewCNtJ8TCHCKYlYOXulNNxoex2bc ajz23CkhAuZ+TIQ1S90B6IvxJ3VGI20Vqg6GhlbBxx8Djj7vTd2OyKelfVUkVB1vcRnG FbX4552IgX+CCvLU4g9SIaPLAjEQEY3LwyYT289wWgGnh7+hAxzqoTg7giqC3LVN0NNq fRCg== 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:cc; bh=ONsVBvGNwox634wDoGa5e3zogNcZ6nG1LYNMetO3rB8=; b=KHcBoTg61kKAgfaqQ6Rbeet4j52zoeUPgq2NjFJhGtRqlT7aGu6v+Goi6IicHryKSw Gjpt87vpO3h6dZ42W5yYXkDPcJtUNZkSXABKf8Cyhu1PgG5xYy2GT8NW3a4QOCrxzVSm tNSg/eiufhHgHhRJe1+xcqgJLingsqHDZO8gaKnxwB7B/Wt2dtlWHLlqgYiNfhoLdzaG nDRo5fOzxj8HaY2VobBveWhKTd4O0kaRoK4e6osKXk0CU70AqAUukWbBJ42HFPH6TnEp Wv66pziyxjDUkTEVPEfgbE7pObJH1kxUNVn+3L1tJQaqj6z5JIAfnjDLwDJcBD0s7voR Vp1w== X-Gm-Message-State: ALQs6tDouX0jKUu4tLKm8hc+lBRrZq2rNKT89a37txQsMYVXnUUZvYvf D7ZcDO2y5UKVtSIX9F0jrQIZMjWtDKOrfyvi4KYiIQ== X-Google-Smtp-Source: AIpwx48RW1ZQ9P5eTFCTEVkYoCZYBYeJeBa/au4oN50+OPxhS3lrWo2+oTiyp3omA8yto/Qq479qOCIJ/z1LFzRDyfk= X-Received: by 10.107.18.162 with SMTP id 34mr6818887ios.168.1523493077503; Wed, 11 Apr 2018 17:31:17 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.166.4 with HTTP; Wed, 11 Apr 2018 17:31:16 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Warner Losh Date: Wed, 11 Apr 2018 18:31:16 -0600 X-Google-Sender-Auth: zwtyYnVzpcWDAzdIqZWVRxY93Ck Message-ID: Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Eric McCorkle Cc: Oliver Pinter , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 00:31:19 -0000 OK. I've pushed in the main part of it. The additional work I have shouldn't affect any of this stuff. I was going to look at what part(s) of your open reviewed needed to be redone tomorrow and send you feedback, but if you wanted to get a start before then, I'm happy to answer questions. All the rest of my work is going to be selecting the root partition when we're told to us a specific partition, so will be very constrained. Warner On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle wrote: > I think the thing to do at this point is to wait for the current work on > loader.efi to land, then adapt my patches to apply against that work. > > On 04/11/2018 15:06, Warner Losh wrote: > > Still reviewing the code. I'm worried it's too i386 specific and it > > conflicts with some work I'm doing. I'll have a list of actionable > > critiques this week. > > > > Warner > > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > > > > wrote: > > > > Hi! > > > > Is there any update regarding the rebase or the inclusion to base > > system? > > On 3/28/18, Eric McCorkle > > wrote: > > > I'll do another rebase from head just to be sure > > > > > > On March 28, 2018 3:23:23 PM EDT, Warner Losh > > wrote: > > >>It's on my list for nexr, finally. I have an alternate patch for > > >>loader.efi > > >>from ESP, but i don't think it will affect the GELI stuff. I have > some > > >>time > > >>slotted for integration issues though. > > >> > > >>I am quite mindful of the freeze dates.... I have some uefi boot > > >>loader > > >>protocol changes that I need to get in. > > >> > > >>Warner > > >> > > >>On Feb 21, 2018 11:18 PM, "Tommi Pernila" > > wrote: > > >> > > >>> Awesome, thanks for the update and the work that you have done! > > >>> > > >>> Now we just need some more reviewers eyes on the code :) > > >>> > > >>> Br, > > >>> > > >>> Tommi > > >>> > > >>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle > > > > >>wrote: > > >>> > > >>>> FYI, I just IFC'ed everything, and the current patches are still > > >>fine. > > >>>> > > >>>> Also, the full GELI + standalone loader has been deployed on > one of > > >>my > > >>>> laptops for some time now. > > >>>> > > >>>> On 02/21/2018 18:15, Eric McCorkle wrote: > > >>>> > The GELI work could be merged at this point, though it won't > be > > >>usable > > >>>> > without an additional patch to enable loader-only operation. > The > > >>>> > patches are currently up for review: > > >>>> > > > >>>> > This is the order in which they'd need to be merged: > > >>>> > > > >>>> > > > >>>> > https://reviews.freebsd.org/D12732 > > > > >>>> > > > >>>> > This one changes the efipart device. Toomas Soome identified > > some > > >>>> > problems, which I have addressed. He has not re-reviewed it, > > >>however. > > >>>> > > > >>>> > > > >>>> > https://reviews.freebsd.org/D12692 > > > > >>>> > > > >>>> > This adds some crypto code needed for GELI. It simply adds > new > > >>code, > > >>>> > and doesn't conflict with anything. > > >>>> > > > >>>> > > > >>>> > https://reviews.freebsd.org/D12698 > > > > >>>> > > > >>>> > This adds the EFI KMS interface code, and has the EFI loader > pass > > >>keys > > >>>> > into the keybuf interface. > > >>>> > > > >>>> > > > >>>> > I can't post the main GELI driver until those get merged, as > it > > >>depends > > >>>> > on them. It can be found on the geli branch on my github > freebsd > > >>>> > repository, however. > > >>>> > > > >>>> > > > >>>> > Additionally, you need this patch, which allows loader.efi to > > >>function > > >>>> > when installed directly to the ESP: > > >>>> > > > >>>> > https://reviews.freebsd.org/D13497 > > > > >>>> > > > >>>> > On 02/20/2018 22:56, Tommi Pernila wrote: > > >>>> >> Hi Eric, > > >>>> >> > > >>>> >> could you provide a brief update how the work is going? > > >>>> >> > > >>>> >> > > >>>> >> Br, > > >>>> >> > > >>>> >> Tommi > > >>>> >> > > >>>> >> > > >>>> >> On Nov 16, 2017 04:29, "Eric McCorkle" > > > >>>> >> >> > > wrote: > > >>>> >> > > >>>> >> Right, so basically, the remaining GELI patches are > against > > >>>> loader, and > > >>>> >> most of them can go in independently of the work on > removing > > >>boot1. > > >>>> >> There's a unanimous consensus on getting rid of boot1 > which > > >>>> includes its > > >>>> >> original author, so that's going to happen. > > >>>> >> > > >>>> >> > > >>>> >> For GELI, we have the following (not necessarily in > order): > > >>>> >> > > >>>> >> a) Adding the KMS interfaces, pseudo-device, and kernel > > >>keybuf > > >>>> >> interactions > > >>>> >> b) Modifications to the efipart driver > > >>>> >> c) boot crypto > > >>>> >> d) GELI partition types (not strictly necessary) > > >>>> >> > > >>>> >> Then there's the GELI driver itself. (a) and (c) are > > good to > > >>>> land, (b) > > >>>> >> needs some more work after Toomas Soome pointed out a > > >>legitimate > > >>>> >> problem, and (d) actually needs a good bit more code (but > > >>again, > > >>>> it's > > >>>> >> more cosmetic). Additionally, the GELI driver will need > > >>further > > >>>> mods to > > >>>> >> efipart to be written (nothing too big). But we could go > > >>ahead > > >>>> with (a) > > >>>> >> and (c), as they've already been proven to work. > > >>>> >> > > >>>> >> I'd wanted to have this stuff shaped up sooner, but I'm > > >>>> preoccupied with > > >>>> >> the 7th RISC-V workshop at the end of the month. > > >>>> >> > > >>>> >> Once this stuff is all in, loader should handle any GELI > > >>volumes it > > >>>> >> finds, and it should Just Work once boot1 is gone. > > >>>> >> > > >>>> >> > > >>>> > _______________________________________________ > > >>>> > 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 " > > >>>> > > > >>>> > > >>> > > > > > > -- > > > Sent from my Android device with K-9 Mail. Please excuse my > brevity. > > > _______________________________________________ > > > 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-current@freebsd.org Thu Apr 12 00:33:20 2018 Return-Path: Delivered-To: freebsd-current@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 2341DF9ECB6 for ; Thu, 12 Apr 2018 00:33:20 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4236D797; Thu, 12 Apr 2018 00:33:19 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 291F09774; Thu, 12 Apr 2018 00:33:19 +0000 (UTC) Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Warner Losh Cc: Oliver Pinter , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEWQXo2BYJKwYBBAHaRw8BAQdAYZJt/w5CCUvp4v5Mssy0JwiO21sDxKfa27YLD5uQVc60 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiZBBMWCABBAhsDBQkB4TOA BQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEE6eoVp0R+Jx2/f0Df5CP6Oqs6upgFAlkF6gcC GQEACgkQ5CP6Oqs6upiK5gEA2rdFpRnPct2O6IWIIkiiDSxVcQumGJNLpl5+wvjcOgsA/iHL kDE4v0RLg6w8b8KWzSJVFtim9Zoff66iUzkEVNQNtChFcmljIE1jQ29ya2xlIDxlcmljX21j Y29ya2xlQGtleWJhc2UuaW8+iJYEExYIAD4WIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWQXq AQIbAwUJAeEzgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDkI/o6qzq6mC1TAP49VcmC wwa0/X/jU8EeLCjFQL+3U1UvKKRaN7tvt8U76QD+IzjI3LoSWzc3F/Zqu+8NE/LSbzTbFezC f0VUJiuEhgu0K0VyaWMgTWNDb3JrbGUgPGVyaWNtY2NvcmtsZUBwcm90b25tYWlsLmNvbT6I lgQTFggAPhYhBOnqFadEficdv39A3+Qj+jqrOrqYBQJZLrJoAhsDBQkB4TOABQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEOQj+jqrOrqYAGsBANlpTq+GF+7N9o5iVkDwuuO7ZBFZlxsO CdA/dIhh3oBCAQC2ipgR/mE6eab1akzRa5PsEAHA/z3bDxLYtCZzCBXdBrg4BFkF6NgSCisG AQQBl1UBBQEBB0BXtYyAeWPqTL7aosi48FCkwH7+w17y3wMv2kCTLStqPgMBCAeIfgQYFggA JhYhBOnqFadEficdv39A3+Qj+jqrOrqYBQJZBejYAhsMBQkB4TOAAAoJEOQj+jqrOrqY2H8A /1tdtmFg6evmfC6Hf4+kTd76Dj+Kb7DfDyGrcYDy8cmuAQCGwHh+Za5U1zptnKCSgvKcjBgS EuvfTgXZTaIXaZOnBA== Message-ID: <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> Date: Wed, 11 Apr 2018 20:33:14 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NWudzlHR0FtwPcMk3NqvOKi5FpG39QoiP" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 00:33:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NWudzlHR0FtwPcMk3NqvOKi5FpG39QoiP Content-Type: multipart/mixed; boundary="lr8kB5RO0udJItiOegEozSjEkCObf6cXi"; protected-headers="v1" From: Eric McCorkle To: Warner Losh Cc: Oliver Pinter , Tommi Pernila , "[ScaleEngine] Allan Jude" , freebsd-current , Warner Losh Message-ID: <5ba11024-e99b-86e1-48b7-125fb80b4001@metricspace.net> Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> In-Reply-To: --lr8kB5RO0udJItiOegEozSjEkCObf6cXi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I'm in the middle of moving to a new apartment right now. It's going to be a bit before I can get to this. On 04/11/2018 20:31, Warner Losh wrote: > OK. I've pushed in the main part of it. The additional work I have > shouldn't affect any of this stuff.=C2=A0 I was going to look at what p= art(s) > of your open reviewed needed to be redone tomorrow and send you > feedback, but if you wanted to get a start before then, I'm happy to > answer questions. All the rest of my work is going to be selecting the > root partition when we're told to us a specific partition, so will be > very constrained. >=20 > Warner >=20 > On Wed, Apr 11, 2018 at 6:02 PM, Eric McCorkle > wrote: >=20 > I think the thing to do at this point is to wait for the current wo= rk on > loader.efi to land, then adapt my patches to apply against that wor= k. >=20 > On 04/11/2018 15:06, Warner Losh wrote: > > Still reviewing the code. I'm worried it's too i386 specific and = it > > conflicts with some work I'm doing. I'll have a list of actionabl= e > > critiques this week. > > > > Warner > > > > On Wed, Apr 11, 2018 at 1:03 PM, Oliver Pinter > > > >> > > wrote: > > > >=C2=A0 =C2=A0 =C2=A0Hi! > > > >=C2=A0 =C2=A0 =C2=A0Is there any update regarding the rebase or th= e inclusion to base > >=C2=A0 =C2=A0 =C2=A0system? > >=C2=A0 =C2=A0 =C2=A0On 3/28/18, Eric McCorkle > >=C2=A0 =C2=A0 =C2=A0>> wrote: > >=C2=A0 =C2=A0 =C2=A0> I'll do another rebase from head just to be = sure > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> On March 28, 2018 3:23:23 PM EDT, Warner Los= h > >=C2=A0 =C2=A0 =C2=A0= >> wrote: > >=C2=A0 =C2=A0 =C2=A0>>It's on my list for nexr, finally. I have an= alternate patch for > >=C2=A0 =C2=A0 =C2=A0>>loader.efi > >=C2=A0 =C2=A0 =C2=A0>>from ESP, but i don't think it will affect t= he GELI stuff. I have some > >=C2=A0 =C2=A0 =C2=A0>>time > >=C2=A0 =C2=A0 =C2=A0>>slotted for integration issues though. > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>>I am quite mindful of the freeze dates.... I= =C2=A0 have some uefi boot > >=C2=A0 =C2=A0 =C2=A0>>loader > >=C2=A0 =C2=A0 =C2=A0>>protocol changes that I need to get in. > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>>Warner > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>>On Feb 21, 2018 11:18 PM, "Tommi Pernila" > >=C2=A0 =C2=A0 =C2=A0>> wrote: > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>>> Awesome, thanks for the update and the wor= k that you have done! > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0>>> Now we just need some more reviewers eyes = on the code :) > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0>>> Br, > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0>>> Tommi > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0>>> On Thu, 22 Feb 2018 at 2.03, Eric McCorkle= > >=C2=A0 =C2=A0 =C2=A0>> > >=C2=A0 =C2=A0 =C2=A0>>wrote: > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0>>>> FYI, I just IFC'ed everything, and the cu= rrent patches > are still > >=C2=A0 =C2=A0 =C2=A0>>fine. > >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0>>>> Also, the full GELI + standalone loader h= as been deployed > on one of > >=C2=A0 =C2=A0 =C2=A0>>my > >=C2=A0 =C2=A0 =C2=A0>>>> laptops for some time now. > >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0>>>> On 02/21/2018 18:15, Eric McCorkle wrote:= > >=C2=A0 =C2=A0 =C2=A0>>>> > The GELI work could be merged at this p= oint, though it > won't be > >=C2=A0 =C2=A0 =C2=A0>>usable > >=C2=A0 =C2=A0 =C2=A0>>>> > without an additional patch to enable l= oader-only > operation.=C2=A0 The > >=C2=A0 =C2=A0 =C2=A0>>>> > patches are currently up for review: > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > This is the order in which they'd need = to be merged: > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > https://reviews.freebsd.org/D12732 > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > This one changes the efipart device.=C2= =A0 Toomas Soome > identified > >=C2=A0 =C2=A0 =C2=A0some > >=C2=A0 =C2=A0 =C2=A0>>>> > problems, which I have addressed.=C2=A0= He has not > re-reviewed it, > >=C2=A0 =C2=A0 =C2=A0>>however. > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > https://reviews.freebsd.org/D12692 > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > This adds some crypto code needed for G= ELI.=C2=A0 It simply > adds new > >=C2=A0 =C2=A0 =C2=A0>>code, > >=C2=A0 =C2=A0 =C2=A0>>>> > and doesn't conflict with anything. > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > https://reviews.freebsd.org/D12698 > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > This adds the EFI KMS interface code, a= nd has the EFI > loader pass > >=C2=A0 =C2=A0 =C2=A0>>keys > >=C2=A0 =C2=A0 =C2=A0>>>> > into the keybuf interface. > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > I can't post the main GELI driver until= those get > merged, as it > >=C2=A0 =C2=A0 =C2=A0>>depends > >=C2=A0 =C2=A0 =C2=A0>>>> > on them.=C2=A0 It can be found on the g= eli branch on my > github freebsd > >=C2=A0 =C2=A0 =C2=A0>>>> > repository, however. > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > Additionally, you need this patch, whic= h allows > loader.efi to > >=C2=A0 =C2=A0 =C2=A0>>function > >=C2=A0 =C2=A0 =C2=A0>>>> > when installed directly to the ESP: > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > https://reviews.freebsd.org/D13497 > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > On 02/20/2018 22:56, Tommi Pernila wrot= e: > >=C2=A0 =C2=A0 =C2=A0>>>> >> Hi Eric, > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> could you provide a brief update how t= he work is going? > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> Br, > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> Tommi > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> On Nov 16, 2017 04:29, "Eric McCorkle"= > > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0>>>> >> >>> > >=C2=A0 =C2=A0 =C2=A0wrote: > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0Right, so basically= , the remaining GELI patches > are against > >=C2=A0 =C2=A0 =C2=A0>>>> loader, and > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0most of them can go= in independently of the work > on removing > >=C2=A0 =C2=A0 =C2=A0>>boot1. > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0There's a unanimous= consensus on getting rid of > boot1 which > >=C2=A0 =C2=A0 =C2=A0>>>> includes its > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0original author, so= that's going to happen. > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0For GELI, we have t= he following (not necessarily > in order): > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0a) Adding the KMS i= nterfaces, pseudo-device, and > kernel > >=C2=A0 =C2=A0 =C2=A0>>keybuf > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0interactions > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0b) Modifications to= the efipart driver > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0c) boot crypto > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0d) GELI partition t= ypes (not strictly necessary) > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0Then there's the GE= LI driver itself.=C2=A0 (a) and (c) are > >=C2=A0 =C2=A0 =C2=A0good to > >=C2=A0 =C2=A0 =C2=A0>>>> land, (b) > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0needs some more wor= k after Toomas Soome pointed out a > >=C2=A0 =C2=A0 =C2=A0>>legitimate > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0problem, and (d) ac= tually needs a good bit more > code (but > >=C2=A0 =C2=A0 =C2=A0>>again, > >=C2=A0 =C2=A0 =C2=A0>>>> it's > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0more cosmetic).=C2=A0= Additionally, the GELI driver > will need > >=C2=A0 =C2=A0 =C2=A0>>further > >=C2=A0 =C2=A0 =C2=A0>>>> mods to > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0efipart to be writt= en (nothing too big).=C2=A0 But we > could go > >=C2=A0 =C2=A0 =C2=A0>>ahead > >=C2=A0 =C2=A0 =C2=A0>>>> with (a) > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0and (c), as they've= already been proven to work. > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0I'd wanted to have = this stuff shaped up sooner, > but I'm > >=C2=A0 =C2=A0 =C2=A0>>>> preoccupied with > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0the 7th RISC-V work= shop at the end of the month. > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0Once this stuff is = all in, loader should handle > any GELI > >=C2=A0 =C2=A0 =C2=A0>>volumes it > >=C2=A0 =C2=A0 =C2=A0>>>> >>=C2=A0 =C2=A0 =C2=A0finds, and it shoul= d Just Work once boot1 is gone. > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> >> > >=C2=A0 =C2=A0 =C2=A0>>>> > _______________________________________= ________ > >=C2=A0 =C2=A0 =C2=A0>>>> > freebsd-current@freebsd.org > > >=C2=A0 =C2=A0 =C2=A0 > mailing list > >=C2=A0 =C2=A0 =C2=A0>>>> > https://lists.freebsd.org/mailman/listi= nfo/freebsd-current > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0>>>> > To unsubscribe, send any mail to "freeb= sd-current-unsubscribe@ > >=C2=A0 =C2=A0 =C2=A0>>>> freebsd.org " > >=C2=A0 =C2=A0 =C2=A0>>>> > > >=C2=A0 =C2=A0 =C2=A0>>>> > >=C2=A0 =C2=A0 =C2=A0>>> > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> -- > >=C2=A0 =C2=A0 =C2=A0> Sent from my Android device with K-9 Mail. P= lease excuse my brevity. > >=C2=A0 =C2=A0 =C2=A0> ____________________________________________= ___ > >=C2=A0 =C2=A0 =C2=A0> freebsd-current@freebsd.org > > > > >=C2=A0 =C2=A0 =C2=A0mailing list > >=C2=A0 =C2=A0 =C2=A0> https://lists.freebsd.org/mailman/listinfo/f= reebsd-current > > >=C2=A0 =C2=A0 =C2=A0 > > >=C2=A0 =C2=A0 =C2=A0> To unsubscribe, send any mail to > >=C2=A0 =C2=A0 =C2=A0"freebsd-current-unsubscribe@freebsd.org > > >=C2=A0 =C2=A0 =C2=A0 >" > >=C2=A0 =C2=A0 =C2=A0> > > > > >=20 >=20 --lr8kB5RO0udJItiOegEozSjEkCObf6cXi-- --NWudzlHR0FtwPcMk3NqvOKi5FpG39QoiP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTp6hWnRH4nHb9/QN/kI/o6qzq6mAUCWs6pSgAKCRDkI/o6qzq6 mMN8AQDOsBdY5bwjSG2EbESTxAbZkK64DhrLcX+JHMhX7HTGIQD/YPQOiflSkFzd SbkGcDKKl+zaKvUUGtL7yBHYEUxYOgw= =pUWJ -----END PGP SIGNATURE----- --NWudzlHR0FtwPcMk3NqvOKi5FpG39QoiP-- From owner-freebsd-current@freebsd.org Thu Apr 12 20:11:52 2018 Return-Path: Delivered-To: freebsd-current@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 ACD5FF8CE94 for ; Thu, 12 Apr 2018 20:11:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53035858FE; Thu, 12 Apr 2018 20:11:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 04D485832; Thu, 12 Apr 2018 20:11:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 01226BAB; Thu, 12 Apr 2018 20:11:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id h6F4JoVzTtBB; Thu, 12 Apr 2018 20:11:48 +0000 (UTC) Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 1A824BA6 To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> Date: Thu, 12 Apr 2018 13:11:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YRObYu5yywffVd7jj8ArloTsFLF5dYhhO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 20:11:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YRObYu5yywffVd7jj8ArloTsFLF5dYhhO Content-Type: multipart/mixed; boundary="ydutFZf1TmORBrV6Js8x68RbBmJQBegYC"; protected-headers="v1" From: Bryan Drewery To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org Message-ID: <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> --ydutFZf1TmORBrV6Js8x68RbBmJQBegYC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: >> Rodney W. Grimes wrote: >> >>> I am having a compile time issue for a patched that compiled fine on = my >>> r329294 system, but now failes to compile with what looks like a wron= g >>> header being included. >> >> You may find it helpful to do something like: >> >> make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 >> egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more >> >> The arg to -V doesn't matter btw. >> You could narrow that down if you know what var -I/usr/src/sys is in >> (probably CFLAGS but you never know) >> the above should help find the makefile that is introducing the bogus = -I >> >=20 > Thank you, that does help narrow it down: (I backed up a vew lines > from the first place I saw src/.) >=20 > ... > Global:.PARSEFILE =3D bsd.kmod.mk > Global:.PARSEDIR =3D /usr/src-topo/share/mk > Global:.PARSEFILE =3D bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Global:SYSDIR =3D ${:U/usr/src/sys:tA} > Global:.PARSEDIR =3D /usr/src-topo/share/mk > Global:.PARSEFILE =3D bsd.kmod.mk > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Result[] of :U is "/usr/src/sys" > Applying[] :t to "/usr/src/sys" > Result[] of :t is "/usr/src/sys" > Global:.MAKE.MAKEFILES =3D /usr/src-topo/share/mk/sys.mk /usr/src-topo/= share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/src-= topo/share/mk/bsd.mkopt.m > k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.obj= =2Emk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local= =2Esys.mk /usr/src-topo/sha > re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo/s= hare/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk > = ^^^^^^^^^^^^^^^^^^^^^^^^^ > Thats gona bust something some day.... >=20 > Global:.PARSEDIR =3D /usr/src/sys/conf > Global:.PARSEFILE =3D kmod.mk > Global:.INCLUDEDFROMDIR =3D /usr/src/sys/conf > Oh my! Uggggg >=20 >=20 > So something in bsd.kmod.mk is going very wrong... it looks like it > starts to pull all sorts of stuff from /usr/src/sys! >=20 >>> >>> I have wrapped the long line so I can point to a difference between >>> r329294 and r332262 make log of this file. >>> >>> r329294 make output: >>> >>> cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -D= _KERNEL \ >>> -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ >>> -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel = \ >>> -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-common= \ >>> ^^^^^^^^^^^^^^^^^ this is what= I would expect >> >> >=20 Is this buildkernel or a direct module directory build? Does reverting r331683 and r331682 help? Perhaps I missed ensuring SYSDIR is exported properly. --=20 Regards, Bryan Drewery --ydutFZf1TmORBrV6Js8x68RbBmJQBegYC-- --YRObYu5yywffVd7jj8ArloTsFLF5dYhhO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaz72CAAoJEDXXcbtuRpfPqngIAMyPWuGDpt0bNrYu4oe8i+dg FHzod2mmtp/wDm6OTHnitXvEhk2j1Qv2gx7nTc0EZzuV7LfGi0sgJ3H7bsncKH/b DOOVPrClxr/6aCG7EDGE+IK3OjpHW9OXkmp1kmsk58WIbJHr2JCqCwh5qhulxwFK 5EaeqLmrzBDyvuubfxPqhRWjdd7fjdKD1y0wG13mUHkDHgCZXhAtmjpl/5DfOrqF W3dJCX1ChjFVVIzkokng0mxKEHEadyEHcvS54ytbquoRBdfW54W1zRhFrKB2GPPq mznrApCiH1DyQLGSEYZwInynI0VxVS3mdiByguwBoi01ehb+0CgrJBA5mNszQ1A= =f4Hx -----END PGP SIGNATURE----- --YRObYu5yywffVd7jj8ArloTsFLF5dYhhO-- From owner-freebsd-current@freebsd.org Thu Apr 12 20:21:04 2018 Return-Path: Delivered-To: freebsd-current@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 084D8F8D867 for ; Thu, 12 Apr 2018 20:21:04 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A74D468460; Thu, 12 Apr 2018 20:21:03 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 77F1190D2; Thu, 12 Apr 2018 20:21:03 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id B15D8BC8; Thu, 12 Apr 2018 20:21:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id U4LzCeAj-bF1; Thu, 12 Apr 2018 20:20:59 +0000 (UTC) Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 549F1BC2 From: Bryan Drewery To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Thu, 12 Apr 2018 13:20:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XxBlTLh3stS8BjBElR12c6ZP4IqUnHMZO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 20:21:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XxBlTLh3stS8BjBElR12c6ZP4IqUnHMZO Content-Type: multipart/mixed; boundary="YNQBuZV71dq80Ixaug9FaSC6dzajC0Lk9"; protected-headers="v1" From: Bryan Drewery To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> In-Reply-To: <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> --YNQBuZV71dq80Ixaug9FaSC6dzajC0Lk9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/12/2018 1:11 PM, Bryan Drewery wrote: > On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: >>> Rodney W. Grimes wrote: >>> >>>> I am having a compile time issue for a patched that compiled fine on= my >>>> r329294 system, but now failes to compile with what looks like a wro= ng >>>> header being included. >>> >>> You may find it helpful to do something like: >>> >>> make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 >>> egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more >>> >>> The arg to -V doesn't matter btw. >>> You could narrow that down if you know what var -I/usr/src/sys is in >>> (probably CFLAGS but you never know) >>> the above should help find the makefile that is introducing the bogus= -I >>> >> >> Thank you, that does help narrow it down: (I backed up a vew lines >> from the first place I saw src/.) >> >> ... >> Global:.PARSEFILE =3D bsd.kmod.mk >> Global:.PARSEDIR =3D /usr/src-topo/share/mk >> Global:.PARSEFILE =3D bsd.kmod.mk >> Result[] of :U is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Global:SYSDIR =3D ${:U/usr/src/sys:tA} >> Global:.PARSEDIR =3D /usr/src-topo/share/mk >> Global:.PARSEFILE =3D bsd.kmod.mk >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Result[] of :U is "/usr/src/sys" >> Applying[] :t to "/usr/src/sys" >> Result[] of :t is "/usr/src/sys" >> Global:.MAKE.MAKEFILES =3D /usr/src-topo/share/mk/sys.mk /usr/src-topo= /share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/src= -topo/share/mk/bsd.mkopt.m >> k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.ob= j.mk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local.= sys.mk /usr/src-topo/sha >> re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo/= share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk >> = ^^^^^^^^^^^^^^^^^^^^^^^^^ >> Thats gona bust something some day.... >> >> Global:.PARSEDIR =3D /usr/src/sys/conf >> Global:.PARSEFILE =3D kmod.mk >> Global:.INCLUDEDFROMDIR =3D /usr/src/sys/conf >> Oh my! Uggggg >> >> >> So something in bsd.kmod.mk is going very wrong... it looks like it >> starts to pull all sorts of stuff from /usr/src/sys! >> >>>> >>>> I have wrapped the long line so I can point to a difference between >>>> r329294 and r332262 make log of this file. >>>> >>>> r329294 make output: >>>> >>>> cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror -= D_KERNEL \ >>>> -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ >>>> -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/intel= \ >>>> -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-commo= n \ >>>> ^^^^^^^^^^^^^^^^^ this is wha= t I would expect >>> >>> >> >=20 > Is this buildkernel or a direct module directory build? >=20 > Does reverting r331683 and r331682 help? Perhaps I missed ensuring > SYSDIR is exported properly. >=20 Ok I see the problem with a direct module build. I am fixing it. Sorry about that. --=20 Regards, Bryan Drewery --YNQBuZV71dq80Ixaug9FaSC6dzajC0Lk9-- --XxBlTLh3stS8BjBElR12c6ZP4IqUnHMZO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaz7+qAAoJEDXXcbtuRpfPM9AH/1wgCr9aEkaoSxnhBmDJLGgX PRf8loKvCe8LYTwSvCiH2+c4U7HW8laJ73P6pnt7Yr9wZaUvCUw+3VCV3bVraVDH XMs0zg/8HiELIW1mFAhdtzoiUNiGn4EkNPotcClrmdWOfAqLgbZYIoo2s9V226zz cR5s8+gzxjyE2SJkF7lhoo1mqyuRaGBFWSJAAI8Fnyzve4v7IOLqBPO06HVv7iH1 K+NHGi6aSLzA/rvfv/3mex+siE+hXqUFsXGSaqKrvLvWt0GbGN8YY0ll4D+COeXR 9ZD1lRiqnWhH5rlMBBQNu6Hjy4jwrfhxjs8Ubok5GOLasDZQy7G+V5w2orKzvsg= =cKZp -----END PGP SIGNATURE----- --XxBlTLh3stS8BjBElR12c6ZP4IqUnHMZO-- From owner-freebsd-current@freebsd.org Thu Apr 12 20:28:24 2018 Return-Path: Delivered-To: freebsd-current@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 B48C6F8E375 for ; Thu, 12 Apr 2018 20:28:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A5F96A69E; Thu, 12 Apr 2018 20:28:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 0D0CFBC5A; Thu, 12 Apr 2018 20:28:24 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 3F198BFF; Thu, 12 Apr 2018 20:28:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id p8ts_YpRFkm4; Thu, 12 Apr 2018 20:28:20 +0000 (UTC) Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com B70A4BFA From: Bryan Drewery To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Thu, 12 Apr 2018 13:28:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6WCvRrcXi3sTZG30t6JNBw96gELIZIgRi" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 20:28:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6WCvRrcXi3sTZG30t6JNBw96gELIZIgRi Content-Type: multipart/mixed; boundary="5ftsNCKK7euUYYCGLAbqTQWsCvx4B4NKf"; protected-headers="v1" From: Bryan Drewery To: "Rodney W. Grimes" , "Simon J. Gerraty" Cc: freebsd-current@freebsd.org Message-ID: Subject: Re: Module compiles looking in /usr/src when alternate src tree is in use References: <201804110029.w3B0TPUf025467@pdx.rh.CN85.dnsmgr.net> <115747a8-a7f9-9112-d7b0-c4fc24742708@FreeBSD.org> In-Reply-To: --5ftsNCKK7euUYYCGLAbqTQWsCvx4B4NKf Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/12/2018 1:20 PM, Bryan Drewery wrote: > On 4/12/2018 1:11 PM, Bryan Drewery wrote: >> On 4/10/2018 5:29 PM, Rodney W. Grimes wrote: >>>> Rodney W. Grimes wrote: >>>> >>>>> I am having a compile time issue for a patched that compiled fine o= n my >>>>> r329294 system, but now failes to compile with what looks like a wr= ong >>>>> header being included. >>>> >>>> You may find it helpful to do something like: >>>> >>>> make -dv -C sys/modules/vmm -V CFLAGS > /tmp/dvo 2>&1 >>>> egrep ':.PARSE|/usr/src/sys' /tmp/dvo | grep -B1 usr/src | more >>>> >>>> The arg to -V doesn't matter btw. >>>> You could narrow that down if you know what var -I/usr/src/sys is in= >>>> (probably CFLAGS but you never know) >>>> the above should help find the makefile that is introducing the bogu= s -I >>>> >>> >>> Thank you, that does help narrow it down: (I backed up a vew lines >>> from the first place I saw src/.) >>> >>> ... >>> Global:.PARSEFILE =3D bsd.kmod.mk >>> Global:.PARSEDIR =3D /usr/src-topo/share/mk >>> Global:.PARSEFILE =3D bsd.kmod.mk >>> Result[] of :U is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Global:SYSDIR =3D ${:U/usr/src/sys:tA} >>> Global:.PARSEDIR =3D /usr/src-topo/share/mk >>> Global:.PARSEFILE =3D bsd.kmod.mk >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Result[] of :U is "/usr/src/sys" >>> Applying[] :t to "/usr/src/sys" >>> Result[] of :t is "/usr/src/sys" >>> Global:.MAKE.MAKEFILES =3D /usr/src-topo/share/mk/sys.mk /usr/src-top= o/share/mk/local.sys.env.mk /usr/src-topo/share/mk/src.sys.env.mk /usr/sr= c-topo/share/mk/bsd.mkopt.m >>> k /usr/src-topo/share/mk/src.sys.obj.mk /usr/src-topo/share/mk/auto.o= bj.mk /usr/src-topo/share/mk/bsd.suffixes.mk /usr/src-topo/share/mk/local= =2Esys.mk /usr/src-topo/sha >>> re/mk/src.sys.mk /usr/src-topo/sys/modules/vmm/Makefile /usr/src-topo= /share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk >>> = ^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Thats gona bust something some day.... >>> >>> Global:.PARSEDIR =3D /usr/src/sys/conf >>> Global:.PARSEFILE =3D kmod.mk >>> Global:.INCLUDEDFROMDIR =3D /usr/src/sys/conf >>> Oh my! Uggggg >>> >>> >>> So something in bsd.kmod.mk is going very wrong... it looks like it >>> starts to pull all sorts of stuff from /usr/src/sys! >>> >>>>> >>>>> I have wrapped the long line so I can point to a difference between= >>>>> r329294 and r332262 make log of this file. >>>>> >>>>> r329294 make output: >>>>> >>>>> cc -O2 -pipe -DVMM_KEEP_STATS -DSMP -fno-strict-aliasing -Werror = -D_KERNEL \ >>>>> -DKLD_MODULE -nostdinc -I/usr/src-topo/sys/amd64/vmm \ >>>>> -I/usr/src-topo/sys/amd64/vmm/io -I/usr/src-topo/sys/amd64/vmm/inte= l \ >>>>> -I/usr/src-topo/sys/amd64/vmm/amd -I. -I/usr/src-topo/sys -fno-comm= on \ >>>>> ^^^^^^^^^^^^^^^^^ this is wh= at I would expect >>>> >>>> >>> >> >> Is this buildkernel or a direct module directory build? >> >> Does reverting r331683 and r331682 help? Perhaps I missed ensuring >> SYSDIR is exported properly. >> >=20 > Ok I see the problem with a direct module build. I am fixing it. Sorry > about that. >=20 Fixed in r332453. --=20 Regards, Bryan Drewery --5ftsNCKK7euUYYCGLAbqTQWsCvx4B4NKf-- --6WCvRrcXi3sTZG30t6JNBw96gELIZIgRi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaz8FiAAoJEDXXcbtuRpfP5TQH/3z2rm9L0xgmlNGDWIKo7eBt kfXUDIuTV5Gj8bPr8byJUU67xysSfMO8II6p2nc7/eG3lT18d2N8brPR06cdwwtL 6TV7NVWacEs29A1aFd0jvAkPVWCgrUSJRhiMAj80SueBfJ2smYxhc4Lbr5PG0AJs U+LMgDZT9LB/jfkMNf5x3sTnLd5o2Yi0ltm4hq24GpCwtgPrUpmmTwohd4mZwYm5 HVZuHw/O5ut3/XgIDf6IvaGGDfr4EbD2tr53z+60RMar915I2CS0Wj8gfG0XRmQR rwq0TAW29/WOQYoQXPriX143BSUzWt6Udjw1qfwrp+cHScqrjitvUEqZ1j6oY78= =9bfx -----END PGP SIGNATURE----- --6WCvRrcXi3sTZG30t6JNBw96gELIZIgRi--