From owner-freebsd-current@freebsd.org Sun Aug 19 00:50:57 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 8EC91107B0DE for ; Sun, 19 Aug 2018 00:50:57 +0000 (UTC) (envelope-from 0ffb41o@gmail.com) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1209D7F591 for ; Sun, 19 Aug 2018 00:50:57 +0000 (UTC) (envelope-from 0ffb41o@gmail.com) Received: by mail-pl0-x229.google.com with SMTP id u11-v6so5375530plq.5 for ; Sat, 18 Aug 2018 17:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=j3/HvFPiu9UDAVyg80TMzD6NMg3bkuVfcDxHu7ywOJg=; b=Zmcpr0cKI+cCuH8ta+W0bO/8sTLD2OmVRwUm9TQyjE9Z9FKU1qaftN494JOFyUQZYA ZyMlzkLZATrxa9ZxZmHYbkFdpAQEFljRrZ+HGo61R8SkY568ye4mRgiWquDkhvu4A5jR eFGiH6W+JC73RC3z2dDlDTvAHhJjB7jEmptxWOKtmg6p5FsrY3zuJ1W+Yv4kPMA6r4bn 2MSQYPqESTJ1u3Yd9AoB9+2su53A4m+TFdVqkX9/g3zIFGlotIH8cPfQY/2OEhFiCB0c mnumxS0E1xn9s8OafndEOr1m8OCRSUQ2vUOYqwGzx6MHVvhUXz9qam8A7JndrR/sZsrg C9Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=j3/HvFPiu9UDAVyg80TMzD6NMg3bkuVfcDxHu7ywOJg=; b=lIJUnDCE0GGqoOo3nUXsNDCeBPSEHZYl4SQJQByH7/3pEmgD6APIjUWMcvpWLNv5pm aqkgPLGnPAMrBahsNaGm/Ckm08P1mHYJ6qqF6hqbiK6FFKP41pJW/MwTQY7t9z0g9Imo nscO6FyzmL4eueWsFQrDmL7k6NPPtKEqy+2B/EYbCB6R/0SQfgm1yEDa19hdn1GUE286 cn+Y74z/5jdfDrU/nJSFylxRb0DfaYwOjUJGxwBba8KGOAQElrt5z817MOZ1/LsCw+nB 7BDj0bAvaHrtUmgAFT6O+IxAqkslElWVm7ic+alsk61Ylk7zq1oBOsEhXOi3DOFpbSDx Jb3Q== X-Gm-Message-State: AOUpUlEdhZRWHr6YcOrwsmnwLzu7xMaaqssADQTfFGgC7E9iEqk1GCip V0bc7gr1wuAZm7E9i+v4C9Bzw58CaNbc3LsZz4bpWNY= X-Google-Smtp-Source: AA+uWPx3OgExcUhf5WEPE2g0b7AP32CgyUKXsbaM4h76rFIrzJowN1Z2RP9Fvmn/zvHwWDX3RRlHwiybaFzJvhiGEoY= X-Received: by 2002:a17:902:758a:: with SMTP id j10-v6mr39345402pll.281.1534639856181; Sat, 18 Aug 2018 17:50:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:7108:0:0:0:0 with HTTP; Sat, 18 Aug 2018 17:50:35 -0700 (PDT) Reply-To: mike@app.leby.org From: Mike Appleby <0ffb41o@gmail.com> Date: Sat, 18 Aug 2018 19:50:35 -0500 Message-ID: Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: Dhananjay Balan Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 00:50:57 -0000 On Sat, Aug 18, 2018 at 5:34 PM, Dhananjay Balan wrote: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? > I've never actually tried it myself, but the following section of the handbook outlines one possibility for doing this via NFS: https://www.freebsd.org/doc/handbook/small-lan.html From owner-freebsd-current@freebsd.org Sun Aug 19 00:55: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 EE784107B3E2 for ; Sun, 19 Aug 2018 00:55:44 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 247AC7F96D for ; Sun, 19 Aug 2018 00:55:43 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from unknown (HELO leader.local) ([118.211.125.71]) by ipmail06.adl6.internode.on.net with ESMTP; 19 Aug 2018 10:25:35 +0930 Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: Dhananjay Balan , freebsd-current@freebsd.org References: <20180818223420.rjisst4vuxzxbcrl@kazhap> From: Shane Ambler Message-ID: <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> Date: Sun, 19 Aug 2018 10:25:33 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180818223420.rjisst4vuxzxbcrl@kazhap> Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 00:55:45 -0000 On 19/8/18 8:04 am, Dhananjay Balan wrote: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? You can use freebsd-update by setting up your own update server https://www.freebsd.org/doc/en/articles/freebsd-update-server This can then be paired with poudriere for pkgs - see handbook 4.6 Also be careful setting the CPUTYPE, it has to be the lowest denominator so that no cpu features are used on a machine without them. This is more important with poudriere as many ports will configure to the current cpu features, I think base always targets the lowest cpu specs. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Sun Aug 19 06:12: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 815C71084819 for ; Sun, 19 Aug 2018 06:12:29 +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 289A989CD5; Sun, 19 Aug 2018 06:12:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [51.52.172.98]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0A3CB10A87D; Sun, 19 Aug 2018 02:12:26 -0400 (EDT) Subject: Re: kernel build failure To: Matthew Macy , Rick Macklem References: <201808131628.w7DGSvOm037857@pdx.rh.CN85.dnsmgr.net> Cc: freebsd-rwg@pdx.rh.cn85.dnsmgr.net, =?UTF-8?Q?Trond_Endrest=c3=b8l?= , Michael Butler , freebsd-current From: John Baldwin Message-ID: <5560c48c-097e-c6a7-4f51-1bd9b2b854bf@FreeBSD.org> Date: Sun, 19 Aug 2018 07:12:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sun, 19 Aug 2018 02:12:27 -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.27 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, 19 Aug 2018 06:12:29 -0000 On 8/14/18 1:35 AM, Matthew Macy wrote: > On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem wrote: > >> Rodney W. Grimes wrote: >>>> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote: >>>> >>>>> Sorry guys, last time I touched ZFS I tried to push to make it an >> option to >>>>> statically link and was actually told that it wasn't something anyone >> else >>>>> wanted. The issue comes from ZFS not being in NOTES and thus not in >> LINT. >>>> >>>> If consensus is that "options ZFS" is no longer valid, then maybe >>>> UPDATING should reflect the fact. >>>> >>>> I can live with loading zfs.ko and opensolaris.ko at boot time, but I >>>> think this is a step backwards. >>> >>> Please no, I can think of no sound reason that you should be >>> forced to use modules. >> I thought that ZFS was required to be a module because of the licensing >> terms (they didn't want any CDDL code in the core kernel)? >> > > It can't be in _GENERIC_ for that reason. There's no reason it can't be in > LINT or end users can't configure a CDDL tainted kernel. It should definitely be in sys/conf/NOTES. That may have just been oversight of whoever finally fixed 'options ZFS' to work. -- John Baldwin From owner-freebsd-current@freebsd.org Sun Aug 19 08:01: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 328B31086439 for ; Sun, 19 Aug 2018 08:01:54 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A095B8C3C3 for ; Sun, 19 Aug 2018 08:01:53 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [IPv6:2001:8b0:151:1:d99c:72b6:4b2e:7a67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id D177E9542 for ; Sun, 19 Aug 2018 08:01:30 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/D177E9542; dkim=none; dkim-atps=neutral Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: freebsd-current@freebsd.org References: <20180818223420.rjisst4vuxzxbcrl@kazhap> <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> From: Matthew Seaman Openpgp: preference=signencrypt Autocrypt: addr=matthew@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFJIL80BEADi7/VbnnErDU6pjEhI/SzEZ/HbDRkJ5g7HroAtqIRm6nj8ZwOAgZ/2ZnWn 5F+fXTuLsG0FLNtkd17FoVcuCi5e/GPliXI5cmamV7E1Yz4T8UsJ7RQolimyxVexccKd16Tc AA7B9bFlJSKkBUSD0buj7VjT07xWhRzu6Vgi5r0UjLALYJz977uZA0F1aOGOXREDEAOhdcNc kSNjynqAwDA6dCT1Elpi4key1fYjv4jyDF+GU/YXul2Y/rguA8FCkHd9vyym5eAsLQ5mG00V V9fkEHIpH5KorNVnl/ufHXnkZqmHAZVpFDcrshb7aZ/pL45PXyWgLj+e6etelgj3a2bZi0JF cVdXCnBZVP2oIyYblM11ugTbfCwodORU8a5KfPeztMdAtDr4e+32NTrPdPi5rLT+GUsYz+PL 3A3m3u8bdsFp40DlIrBtSByVjqERxcfhphrEB4J8BXHUG7OAtXkZMlW/PGKDwXJq0O6Z5Tcg YHAoEiSWbXiexHgXNJyP+sqnIlhLWhSJGeJ+C83wqI6oYlZUCW00NkPxcIHnQPV/z+5wQVci TMyaWC2YCIHz4Ljs+TnwWMz0E8PNFDfHVbQ0W4PRGV7gRAqxfL+yKufauIEGbEq8rNDbSwL3 bcUCxR4ZDlaUEUwT4J8naf7rjdgiEYHs2Ig3jeK1+ER4FPG1sQARAQABzTBNYXR0aGV3IFNl YW1hbiA8bS5zZWFtYW5AaW5mcmFjYW5pbm9waGlsZS5jby51az7CwZcEEwEKAEECGwMFCwkI BwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQRyz6whebywJLW1RZADb2ye5/OevwUCWttU4QUJ DFmAlAAKCRADb2ye5/Oevwb5EACipbOazgwl5IbqkQI4gELpCh5dqDASS9DQqAD35n/cI91P 0lrYcdyCQbOXadQi5bswnP4AcJqX83mITXbcApDdxVxHujw7VODI069eV3/I9Qz72mHYYAAj w0CHNx4bKED2YCSVS6+jV5hq2sywNEUxL+4I218Oc+IsLts62m4tQ8UxX9fQ2H1kQOvdrYpj x7je5qJX/yujLc+9WWZ8ZBSdP/HVJUEdRgQotwAlgfMp3mRQEE73MAJisG/olj/dSxd+oHIP NbJt1yxMqhZekuEGqZpm3tWvqYgpGcEXdhphJSxeK6oLpTLghuAb7/WdOBrpfL7c2OQYBgOw DK+7Io9NBt/d/rCxL39jmUONW8ohrhnNQ2SALnyYTvZgruxA4tXxOOyM9up0/8mB5E8YC9ML 5YuxRPNTXYeWCexa0zktnkCgT7PhS33evf5gsA0B9Snv7TFCFN9adPAdHlsppZIWfTHDG8e2 Jik8PmvsUG34XNif5k6Ui3++2ZA8ZoKvOyLeomuno1hN8yk1APw8SbX1SPNz9UVbl8W/YgGj 3GhYOuQt4HcMiLyTby6R4lC4nsBaHS1MX+57f6Zxzf2wNjSKxiJK9qS7azbu/GxpafNhbz1Z +iUDIaJkRWA1Gs8C7SMcfVsI5zDtvqHGYtTCgooVMYJ6vRyB68M4bljUYMxRTs7BTQRSUUK4 ARAA1FhWoOejtwmsnGshoIbda2FmM+z/f97OzpagLhACHfP5Es/I18wG/0G+rdNuO2tjA9IM Z44GUMtjokDrDk63N9S+rVKy1QEy+UN6CiIfYTpTTAPnEY7IGN1JjGksPhn7aeuBCQwUMAV1 k+wklBCcOD6s8DD4kx0ZJqkH83XzWoBSVamdHvnM56C8yPVr5HHMC1tZInAWBMrF+cjl1EPf z3CqkVnG8Sxc5ydeibMS9Q3lHLeVkVlMRAmNqzNLfgJDUWtzac7JIjFEsxYYhpiaPcsstUUu Ha4zIRJ/yHDNbDttWRf1lrlFZLpeuap4BZ2hQw0UOZVNwGoFoS4ZqaZiv8mm0lX6s9/AdQD6 AVrpXWKa7JU2wDiay9sRbYh+5vVWGz9mhncK/Vfwtu5IjVp5v5WMz/WfnUxZMcNlfgTo4i1s www+qRBO2A4Yj8qKKWnTsl7aCX92itTiPgwbt6YgQPwgww72r67jPt5o8VMXDqPMPKzGicw1 AyxtMjsoSlnn91FuZctwil3vPpvzGXtBmrzQSbdDmy0KT5p5/W9pD/8UtLLLM6PLs5X0jIho vQHnQKEUO7xV3yNDAW9DPICeh7f/o9W+QJfQAXngNz0brvmgScAUXRaeAFeQbAmtEG92qlSV D7gb7WOemllgfbEn0Nanrv5aEcZCWx4WjybMLHEAEQEAAcLBZQQYAQoADwUCUlFCuAIbDAUJ Adf5AAAKCRADb2ye5/Oev8CLD/40aQCRpHTfydtq6sEVHFdpQCgGIE/47r46kr2x15C2wYPY m9JJ1lHvjpKt6N2gGfmiMfq8+PX1ppWp+qkZP4KF2PSxJJ6sjPNMne9+UhPEX5Xn3Z1vjRXJ t7BV0vhsB7WrI8jI9arpYkwVOkQyyjFxWeL0jvfGYYABttvlG/hjxuwI01vipuTfr89zjRYc C5hY1sg2bOn/tIe/V15Sj13Uo/JuFn7Aim91iEYrp5668qbWbLM/8hNqtECH6qLEhtoeoLlL bq6D3HIi00bYvcbBpig/azUasHio3gf4GNklQ5bVvWgIwV0Ue4TjXMCokpaLCq+CNaIqEO9v qJcEa4t0d7oXFHj6U9l6iSVPYRgXsCj/pBgYFPrdV6V8WNGHqa+yQBBtV9bSPNKF8xAjHQ5B KGardo1fBsF7P1CVE3SSr5IzZwk5DIeyCWGJjB8NGGaPWNPIvNyC9v5N9KpFe7WAOyAdEjR7 81ly0veYnFEFcVAmvW3FgzlEXQXw4M4FuniETd3idSJZpRBmq2jvxyfF3b69AdiLddcOAffR jGOBTezLtqxJstJhj7/s4yCuwQhUTpJzwoNBbPLqxmQ/THmdwx6VYAPIqOHBkSQj14nGyX5R vkfvZFq9OBKiVBSQi94jaaWZswqMfGeqZIOuZit+Q2TFTyS8b0R0dDaUUw32DMLBZQQYAQoA DwIbDAUCVCEGdQUJA7D3PQAKCRADb2ye5/Oev1gnD/4wJs6iWJrm2p7/7A0vt+ldL7j/ZaLw dl6XGiTvDY13qISfRwsl6yhsKgwqeAM5zOm1E6gzIdf7VwWx2/4KnQJ83nfBmU8KReUX3udT bVIk8Jo3sMYvPsWtNjRIHCLcXn54/Ajljp1cXihzQ0oXpFxn9sbZll4iE6TcKbPuBBFEsrbI xbjdtG7PNzjnhKkkwrORp2JsScWMcpvqq0/AvPeMKMbQ8SAkOZH20aWdw4wDbcm1bTrxSGYf bFsDmMXxueySeIWbDCwimeMFdWSItsCvHTKX8BIwDM6NP2sQY9Qya3p48HCmFGDpmHdZoU4f xp9+lZFvbNlG+gtY1up3HNYZ9pIbOOdKDjkKtymYX+F2gNflgD/Jp/Fa2EXDzk/iQ73gdT66 2TP9C0WOkFiM17bv5HmmFMGxG0Ap6Ntt8dcqZb2/XoBjR88ssrgDaSbFtpDkUIMy6OarXCii ioMF+bgpPDIffOFPRSFsB+jmMcGu2r3q5I6C3fpTgHh9towgJLhw0pfl08Vr+q3oODcOcXwk NbTrBtM3T5SrLv/lQqWtZmCppWDuRuFt02/jbMaVmWCnpQJN89Z+44H+Fu2ZL+sZSDhsBE0w O7iGAfgP1yIIiK/zunx6IMuNMf5v1y6StOHO/PqJ4+q8IWKBLzjWzEnpNiT5CA/Hdk7v+Va1 Ypd9XsLBfAQYAQoAJgIbDBYhBHLPrCF5vLAktbVFkANvbJ7n856/BQJa21VJBQkMUG4RAAoJ EANvbJ7n856/mAcP/0ybQAvXfxWEEBykIP0DhJHAC/EMeBwNkiAp4Sqr+uIz3GCFGKHDjvEG sofiFQ2ujBpG7FncHlBbnsTLFvte3ahE30I1AKcd9k1MBeOFoCBHwES1ts0XUXF37E+ANrEC QrzSayZx95csIiYvlfOPEOLAt7EiURKXCXdO6HNo8UimcmGdQwT3ytTMosHAbdrhQk13chTI WptmmCwz9iWLxT9PLY01ACCoXuAdGz07ZXQn+bB+avMa6Wh5yh39J+6jJiuzbRlv/Uelogq7 ojbC5zveX5rNbcyinwOEFyGAhFpfF7ESsKedR2Q40LvysT7I5ugS+Hk4Z2nvbd2bOSdC4j8a BWzfqVu2p37d2AnnswfPoLrOyNUZ+ciTEcmEUVR7WWUwQ0H6A6h4C2NeBmLRRjk9CEfzrgM2 DNQqDL1RMYKlVosQ8BeUR9ThztUwDakxnK0ZtZb2rAliKYaaEFbZDePz1xmvjYc7EZq/3OTl GMUDa6BPHHbCvJjiAUc/Q9iaRe3dp69V/rwOM5NiS+tWgp3OtgX0mDWVoQnDjyWVIRU/QagJ HsNJJCc0N48BxgIX3H6M0x6BbA9PKgFtDlK4hLR/hDl5fnWG45TVIxT4ybuPXGW7af9U6bGD gXTBNUCzNUz2p2F2u7W/iK0WTfjovYvVVcptegyu6ttZN49KkQtL Message-ID: <2098a6d6-733f-14c4-b4c9-8bc6b3d2fddc@FreeBSD.org> Date: Sun, 19 Aug 2018 09:01:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="v5ejC2iybrtUIr7wQjKsoiEDNpVI6lXAw" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 08:01:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v5ejC2iybrtUIr7wQjKsoiEDNpVI6lXAw Content-Type: multipart/mixed; boundary="ZVBMfnkjOdQc4AmXFGlp5tjpYtuP7NkKg"; protected-headers="v1" From: Matthew Seaman To: freebsd-current@freebsd.org Message-ID: <2098a6d6-733f-14c4-b4c9-8bc6b3d2fddc@FreeBSD.org> Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. References: <20180818223420.rjisst4vuxzxbcrl@kazhap> <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> In-Reply-To: <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> --ZVBMfnkjOdQc4AmXFGlp5tjpYtuP7NkKg Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 19/08/2018 01:55, Shane Ambler wrote: >> I run 12-CURRENT on few machines, some more powerful that other (all >> of them x86_64, march varies).=20 > You can use freebsd-update by setting up your own update server > https://www.freebsd.org/doc/en/articles/freebsd-update-server freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP specified. Cheers, Matthew --ZVBMfnkjOdQc4AmXFGlp5tjpYtuP7NkKg-- --v5ejC2iybrtUIr7wQjKsoiEDNpVI6lXAw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAlt5I9pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDE5 RjE1NEVDQkYxMTJFNTA1NDRFM0YzMDAwNTEzRjEwRTBBOUU0RTcACgkQAFE/EOCp 5OcvsA/+OSFnrMEtFww2TP0R6gS4KyPi9hgV6wsJqwBJDjK9XosErIpZRwGinkjc Q/L72/5lZbVYLTIjvaIglucdXdqCRWi3K3Oekl5avi17q3F/DFaklhkIVq5ufLED mdiwRcwfJA2MAEKu1myHSTI3aTGl/ostwNVg5Rly+4I4zAa61+vPs3TA6C8EJpzw f1/1C1nYzTu52q1XFQqsPVqahCL/lADgN9bXmyKDeSZSCsI35cOxmomOL2PRBkXo Z38sJeH+0iY+nnDJ1PMptow28sOKQp1nwNSkKbBMNlpPr8mIEOO9Oe8/h5gdCENu 4f81MVrtZUpyuMlxNmwOdNNtneneXLR0NzrDsK5dDm+irfpBJUmS3pyIYLwMDYmw wbPx/SSRVLOCFABZKKXejf8H5/qkcUhLRDXriMvB/vhFPHt29UJEeA086H2lQe8Z L74tuzOwniiNezRJfIbxVoMNvziWZIygCuFqfrG2JCg7G44qQXvDBOXj8zFFrd5D E2gL3YCqtVZIyhUyZFLdUPIdNVNhBFTrZc0b+ssyPFw439TS0+JNVJelSjPHDbpG MgaauC7iE9yAQygGD1NXXd5VUl89+nXvO4vGPVJNNoPYvHRRjkZKkWWFnU1NjMxz kJ/F0EgyiN8lZAIWN8fD0pCAiwwzmHl1MXtHVTPA4CyP133mWiA= =Nfni -----END PGP SIGNATURE----- --v5ejC2iybrtUIr7wQjKsoiEDNpVI6lXAw-- From owner-freebsd-current@freebsd.org Sun Aug 19 09:43:23 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 058161088159 for ; Sun, 19 Aug 2018 09:43:23 +0000 (UTC) (envelope-from SRS0=u+Y1=LC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97F038F0B8 for ; Sun, 19 Aug 2018 09:43:22 +0000 (UTC) (envelope-from SRS0=u+Y1=LC=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B619B2845A; Sun, 19 Aug 2018 11:43:20 +0200 (CEST) Received: from illbsd.quip.test (ip-86-49-16-209.net.upcbroadband.cz [86.49.16.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 0302C28454; Sun, 19 Aug 2018 11:43:11 +0200 (CEST) Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: Dhananjay Balan , freebsd-current@freebsd.org References: <20180818223420.rjisst4vuxzxbcrl@kazhap> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Sun, 19 Aug 2018 11:43:11 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180818223420.rjisst4vuxzxbcrl@kazhap> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 09:43:23 -0000 Dhananjay Balan wrote on 2018/08/19 00:34: > Hi, > > I run 12-CURRENT on few machines, some more powerful that other (all > of them x86_64, march varies). > > Is there is a way to avoid building CURRENT on all machines? Rather > than building everywhere, can I just build it on the big server that I > have and copy and update my laptop? Yes and we are using it (for STABLE, but it works for all versions). You can build it on you build server and export it with NFS. https://www.freebsd.org/cgi/man.cgi?query=development&sektion=7 Miroslav Lachman From owner-freebsd-current@freebsd.org Sun Aug 19 10:27:49 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 3E8581089150 for ; Sun, 19 Aug 2018 10:27:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADD2070602 for ; Sun, 19 Aug 2018 10:27:48 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.221.188]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MfjJY-1fWNlK2M4K-00NBbO; Sun, 19 Aug 2018 12:27:34 +0200 Date: Sun, 19 Aug 2018 12:27:00 +0200 From: "O. Hartmann" To: Dhananjay Balan Cc: freebsd-current@freebsd.org Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. Message-ID: <20180819122727.4d22f99d@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180818223420.rjisst4vuxzxbcrl@kazhap> References: <20180818223420.rjisst4vuxzxbcrl@kazhap> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:toDOdV/Imj3PTjrJzw+jW1GfgKQNnEBc591LB5UnpTh4Da8Jqu4 DQRBPWcK+mOJoIzuFp6Gmtggp7CwfQqBYdwLnqxmkhXTXJSzd+/LKCh1eHqGS5rqq6KZEpU EtXJ/ulG8/8xCPNDAoA8wzl9gEHn7NNfCCmVnK91RIForxk4FB9pzeFsLsgWIj5K9YYypU6 Yer1OpnF8slsGvB4KzBrA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ALLHJX6zV1g=:3pLhUzKqD+eY6f+MDiWAVx RiJ97YXh74iBiSDRZgNykfK6JSEMca4RK3a6ox8l7/31RieY5roVwnim7UwdW/qtWxEOgdscC wJUezzRBjIvYfv0lhQjtjTZgXgMuJBzbGu5Dv16D1Ewg2PevFWY0vQC1RzIAMUmabcFvD+LGe oedup6oyRwrCHQ49HhfyK0m2CYqJhkdgf2ZJSBIbF/yyANBplvqTd9z05TuaXDYIlt326teka 19vqxe3BEQwGWnrhBGbgusvTUXLpgNnm1M2SXdxDGxlvoAVhVBgft6CxX6nS8ccqWlnzaSdvR Vh73IPKNkqpdV4qt+jG66i72/btjAtMAXkajHaXPw7N0Doi0fjY3R0cpGOA8vrrcCALEAsyOP vUlZSiqQBzlCJJgt49dL61M64wMCxNKPIIjK/EtT9MUhsFBLIIm/1Io/NmaaM0lacGMvkMh0H QYWsH5Uh4654lqDSM8C5XbY+j1smLUeFMUpTdH4kp934G6m7Sa6in6zqoLH5V31bsiGMM+PjB 6Om2Q3J45oMK+d35BH7fr+Bm7jaCBBayDZ2gpXRGQPNnsNV9cKTortdG6XluGFaFJupvPAaYa kySE3LgqkmV55JmTS/B3UVoNgpdxTeQsv4RfMMbioQ1brfTpOseePkrJ9ZjMnx8JDiYcPm5tX ofcnMTR8SHJPaL/z4iEEDmWKsfPCmPXhPTKeIjoSw1r0NxtuwGTTNbbIztosiJXteWctXPjz8 Xz3LLlXs+Heu7vsAWrQrJi8yqoiLuZo02ULyZ3N/Gfu89wBQiGOT8go3y+UC/fr/UclIP8M9v 792uKzB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 10:27:49 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIFN1 biwgMTkgQXVnIDIwMTggMDA6MzQ6MjAgKzAyMDANCkRoYW5hbmpheSBCYWxhbiA8bWFpbEBkYmFs YW4uaW4+IHNjaHJpZWI6DQoNCj4gSGksDQo+IA0KPiBJIHJ1biAxMi1DVVJSRU5UIG9uIGZldyBt YWNoaW5lcywgc29tZSBtb3JlIHBvd2VyZnVsIHRoYXQgb3RoZXIgKGFsbA0KPiBvZiB0aGVtIHg4 Nl82NCwgbWFyY2ggdmFyaWVzKS4gDQo+IA0KPiBJcyB0aGVyZSBpcyBhIHdheSB0byBhdm9pZCBi dWlsZGluZyBDVVJSRU5UIG9uIGFsbCBtYWNoaW5lcz8gUmF0aGVyDQo+IHRoYW4gYnVpbGRpbmcg ZXZlcnl3aGVyZSwgY2FuIEkganVzdCBidWlsZCBpdCBvbiB0aGUgYmlnIHNlcnZlciB0aGF0IEkN Cj4gaGF2ZSBhbmQgY29weSBhbmQgdXBkYXRlIG15IGxhcHRvcD8NCj4gDQo+IC0NCj4gRGhhbmFu amF5IEJhbGFuDQpbLi4uXQ0KDQpZZXMsIHlvdSBjYW4uDQpXZSBkbyB0aGlzIHZpYSBhIGN1c3Rv bSBidWlsZCBhbmQgY3JlYXRpbmcgcGFja2FnZXMgYXMgdGhpcyBpcyBpbnRyb2R1Y2VkIGF0DQoN Cmh0dHBzOi8vd2lraS5mcmVlYnNkLm9yZy9Qa2dCYXNlDQoNCkJ1dCBiZXdhcmUhIEFzIG1hbnkg b3RoZXJzIGhhdmUgYWxyZWFkeSBzdGF0ZWQsIHRha2UgY2FyZSBhYm91dCB0byB1c2UgdGhlIGxl YXN0IGNvbW1vbg0KZGVub21pbmF0b3Igb2YgYWNoaXRlY3R1cmFsIHNwZWNpZmljYXRpb25zIGFt b25nc3QgeW91ciBwb29scyEgVGhpcyBtZWFucyB0byBub3QgdXNlIGFueQ0Ka2luZCBvZiBvcHRp bWl6YXRpb25zIGZvciBhIHNwZWNpZmljIENQVSB0eXBlIGZvciBwa2ctYmFzZSBkaXN0cmlidXRl ZCBidWlsZHMhDQoNCkJlY2F1c2Ugd2UgYnVpbGQgdGhlIGxvY2FsIE9TIGZvciBmYXN0L3NlcnZl ciBtYWNoaW5lcyBhbHdheXMoISkgd2l0aCBvcHRpbWlzYXRpb25zLCB0aGUNCnBrZy1iYXNlIGJ1 aWxkcyBhcmUgZG9uZSBpbiBhIHNlcGFyYXRlIHdheSAtIHdoaWNoIGlzIHZlcnkgZWFzeSBpZiB5 b3UndmUgb25jZSB1bmRlcnN0b29kDQp0aGUgcmVhbGx5IG5lYXQgYW5kIGdyZWF0IGJ1aWxkIGZy YW1ld29yayBvZiBGcmVlQlNEJ3MhDQoNCkluc3RlYWQgb2YgYnVpbGRpbmcgdGhlIHRyYWRpdGlv bmFsIChwcm9iYWJseSBvcHRpbWlzZWQpIHN5c3RlbSBmcm9tIC91c3Ivc3JjDQphbmQgL3Vzci9v YmosIG5vdyB5b3UndmUgdG8gY29uc2lkZXIgYSBzZXBhcmF0ZSBwYXRoIGxpa2UgL3Bvb2wvc291 cmNlcy9DVVJSRU5UL3NyYyAob3VyDQp3YXksIHNpbmNlIHdlIGFsc28gdHJ5IHRvIGJ1aWxkIHBh Y2thZ2VzIGFuZCBvYmplY3QgdHJlZXMgZm9yIDExLlgpLCB0aGVuIHNldHVwIGEgc21hbGwNCmJ1 aWxkIHNjcmlwdCB0aGF0IGVzc2VudGlhbGx5IHNldHMgDQogDQpNQUtFT0JKRElSUFJFRklYDQpL RVJOQ09ORkRJUg0KS0VSTkNPTkYNCg0KYW5kIGVzcGVjaWFsbHkNCg0KX19NQUtFX0NPTkYNClNS Q0NPTkYNClNSQ19FTlZfQ09ORg0KDQppZiB5b3UgdXNlIHVzdWFsbHkgb3B0aW1pc2F0aW9ucyBm b3IgdGhlIG5hdGl2ZSB0YXJnZXQgYnVpbGQgb24gdGhlIGJ1aWxkaW5nIGhvc3QgYW5kDQptb3Jl IGdlbmVyaWMgYmluYXJpZXMgZm9yIHRoZSBJbnRlbCB4ODYgY3JhcCBmb3IgcmVkaXN0cmlidXRp b24uDQoNCkRvaW5nIHNvLCB3ZSBhbHNvIHBlcmZvcm0gYnVpbGRzIGZvciBzb21lIEFSTTY0IGJh c2VkIGV4cGVyaW1lbnRhbCBib3hlcy4NCg0KVGhlIG5leHQgc3RlcCBpcyB0aGVuIHVwIHRvIHlv dSBob3cgdG8gZGlzdHJpYnV0ZS4gV2UgY29weSBhbGwgdGhlIHBrZyBzdHVmZiBjb21pbmcgb3V0 DQpvZiB0aGUgYnVpbGQgY3ljbGUgdG8gYSBmb2xkZXIgd2hpY2ggaXMgYWNjZXNzaWJsZSBieSBw a2cgdmlhIEhUVFAoUykgLSBzbyB3d3cvYXBhY2hlMjQNCmlzIG91ciBwbGF0Zm9ybSB0byByZWRp c3RyaWJ1dGUgdGhlIGJpbmFyaWVzIG92ZXIgdGhlIG5ldHdvcmsgYW5kIGV2ZW4gdG8gcmVtb3Rl IHNpdGVzDQooYmV3YXJlIG9mIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMhKS4gWW91IGFsc28g Y2FuIGRpc3RyaWJ1dGUgdGhlIG9iai1mb2xkZXIgKC91c3Ivb2JqLA0Kb3IsIGlmIHVzaW5nIGFu b3RoZXIgYXBwcm9hY2gsIGxpa2UgL3Bvb2wvc291cmNlcy9DVVJSRU5UL29iaikgdmlhIE5GUy4N Cg0KT25jZSB5b3UndmUgdW5kZXJzdG9vZCB0aGUgKGVhc3kgdG8gbGVhcm4pIGNvbmNlcHQgb2Yg YnVpbGRpbmcgdGhlIHNvdXJjZSB0cmVlLCBjcmVhdGluZw0KdGhlIHBhY2thZ2VzIGZvciBwa2ct YmFzZSBhbmQgaGF2aW5nIGRlYWx0IHdpdGggdGhlIG1vcmUgbGFib3IgZm9yIHRoZSBzZXR0aW5n IG9mIGENCmRpc3RyaWJ1dGlvbiBzZXJ2ZXIsIHlvdSBjYW4gdXNlIHRoZSBtb3N0IHBvdGVudCBz ZXJ2ZXIvYm94IG9uIHlvdSBuZXR3b3JrIGZvciBidWlsZGluZw0KZGVkaWNhdGVkIGRpc3RyaWJ1 dGlvbnMNCg0KRXZlbiBhICJSZWxlYXNlIiBidWlsZCBpcyBwb3NzaWJsZSBhcyBsb25nIGFzIHRo ZXJlIGFyZSBub3QgcGl0ZmFsbHMgbGlrZSB0aGV5IG9jY3VyZWQNCmR1cmluZyB0aGUgdHJhbnNp dGlvbiBmcm9tIDExLlggdG8gbW9yZSAxMi1DVVJSRU5UIHNwY2lmaWMgZGV2ZWxvcG1lbnQgKGku ZS4gTElOVCkuDQoNCklmIHlvdSB1c2UgcGtnLWJhc2UgYXMgbWVudGlvbmVkIGFib3ZlLCBiZSBh d2FyZSB0byBzZXR1cCBhIHByb3BlciBwa2cuY29uZiBmaWxlIGFzDQppbnRyb2R1Y2VkIG9uIHRo ZSBXaWtpIGFuZCBwbGVhc2UgYmUgYWxzbyBhd2FyZSBvZiB0aGUgZmFjdCwgdGhhdCB0aGVyZSBp cyBhdCB0aGUgbW9tZW50DQpubyBzaGFycCBzZXBhcmF0aW9uIGJldHdlZW4gcGtnLWJhc2UgYW5k IG9yaWRuYXJ5IHBrZyBmb3IgcGFja2FnZXMgLSBzbyB0YWtlIHRoZQ0Kd2FyaW5pZyBzZXJpb3Vz LCB0aGF0IHBrZyBkZWxldGUgLWEgd2lsbCBub3Qgb25seSBraWxsIGFsbCBwYWNrYWdlcywgaXQg YWxzbyB3aWxsIGtpbGwNCmFsbCBwYWNrYWdlcyBpbnN0YWxsZWQgZm9yIHRoZSBiYXNlIHN5c3Rl bSENCg0KT25jZSBpbnN0YWxsZWQgeW91J2xsIHNlZSBob3cgZmFzdCBjb21wYXJlZCB0byBzb3Vy Y2UgYnVpbGQgdGhlIHBrZy1iYXNlIGluc3RhbGxhdGlvbg0KaXMgKGFsdGhvdWdoIEkgc3RpbGwg cHJlZmVyIHNvdXJjZSBidWlsZCwgb3B0aW1pc2VkIGJ1aWxkcyAuLi4pLg0KDQpBbmQgYnkgdGhl IHdheTogZGVwZW5kaW5nIG9uIHRoZSBzb3BoaXN0aWNhdGlvbiBvZiB5b3VyIGJ1aWxkIHNjcmlw dCBmb3IgZGVkaWNhdGVkDQp0cmVlIGJ1aWxkcyBhcyBtZW50aW9uZWQsIHZpYSBtYW5pcHVsYXRp b25zIG9mIF9fTUFLRV9DT05GLCBTUkNDT05GIHlvdSdyZSBhYmxlIHRvIGFsc28NCmJ1aWxkIG9w dGltaXNlZCBiaW5hcnkgdHJlZXMgZm9yIGRpZmZlcmVudCBDUFUgdHlwZXMsIGJ1dCB5b3UgaGF2 ZSB0byBkZWFsIHlvdXJzZWxmDQp3aXRoIHRoZSBmYWN0IHRoYXQgeW91J3ZlIHRvIHB1dCB0aGUg YmluYXJpZXMgaW50byBhIHByb3BlciBwbGFjZSBhbmQgdGhlbiBkZWxlZ2F0ZSB0aGUNClVSSSBp biBwa2cuY29uZiB0byB0aGUgY29ycmVjdCBicmFuY2ggb2YgeW91ciB0cmVlLiBUaGUgQUJJIGVu dmlyb25tZW50YWwgdmFyaWFibGUNCmRvZXNuJ3QgdGFrZSBjYXJlIG9mIHRoZSAic2V0IiB5b3Ug bWF5IGhhdmUgdXNlZCB0byBvcHRpbWlzZS4gQnV0IHRoaXMgaXMgc29tZXRoaW5nDQp5b3UncmUg YWJsZSB0byBkZWFsIHdpdGggZWFzaWx5IHlvdXJzZWxmIGFmdGVyIGhhdmluZyBzZXR1cCB5b3Vy IGJhc2ljIGJ1aWxkDQplbnZpcm9ubWVudC4NCg0KUmVnYXJkcywNCg0Kb2ggICANCg0KLSAtLSAN Ck8uIEhhcnRtYW5uDQoNCkljaCB3aWRlcnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDDnGJlcm1p dHRsdW5nIG1laW5lciBEYXRlbiBmw7xyDQpXZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGllIE1hcmt0 LSBvZGVyIE1laW51bmdzZm9yc2NodW5nICjCpyAyOCBBYnMuIDQgQkRTRykuDQotLS0tLUJFR0lO IFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppTFVFQVJNS0FCMFdJUVFaVlpNekF0d0MyVC84NlRyUzUy OGZ5RmhZbEFVQ1czbEdEd0FLQ1JEUzUyOGZ5RmhZDQpsTUJlQWY0blZJRkVBZ2VnYlp5S0RadlRR UUQvOVE4bU4rSVk4YUo3Rnp6YTIzS2dXUXNNM1pQNTlPcmgwbWkyDQpQQTk0eXduNWhPamZUZ3pk WWNwMWxxM01DRTg0QWdDQkdBV0FNVGFnODdydTg5SkhtNzVOTHNnRHZFalBwWWdHDQo5aFcxVnJk b2o5RWVpUjJIVHYybmNUYy9Ba0ZQTmhkeWhlK0VKcVVnMDFydEFkOXNkbWRNDQo9L3J6Tw0KLS0t LS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@freebsd.org Sun Aug 19 14:39:37 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 BAA73106A8E1 for ; Sun, 19 Aug 2018 14:39:36 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B1537969F for ; Sun, 19 Aug 2018 14:39:36 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id j81-v6so17284640ite.0 for ; Sun, 19 Aug 2018 07:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7V6p4MCd9t7Y1d54rQdFGuusOUfwNyk/psx0VumfXYA=; b=hkDm86YCferFLRHJccO18afDYJffe9AMEvawnktVSQ4/+pgboK/n9G3XIjv+q93+8Q bNm8JGEivX8nICdJLLldz5P9kVDy+kNmxSi44xDBlSLzjccLXfm60k+DHQ24cMEDCui5 xI/4Dlq7MpnQbFFMyFceDNnfMpbOykJcL38Gi92a/WFblvW9K5yKl3in2XG5JqsrwyWa 6wTxu+42RjwhySGe/LyNVHSWwIXGqEQmNOFlGyVxkNz8ozQi5YVPjUEW5eBG31DwtWIK 72icYZsvYraRi8tOJK5xUXSqfEYGTiZb5GTHbvCd9wCuMr19eh9sldFITRZdFrzlkGpx RrwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7V6p4MCd9t7Y1d54rQdFGuusOUfwNyk/psx0VumfXYA=; b=ACx0vRgIT0CXLBtjGNmEMDl+3szserWkK2rnftxD8RV8iMq+apy1CEA6QGyERHbCOF NumRk/mp2RffhZ2ZwNRJx3l/zLB0NhOiCT9OIoHdzYj5Bry6DSlEbNi1erI/9DqNQBtM N8GjDXRjjqwdKD3q+kThl3sS+ACBTJyZD7zbhkGPRLYiqsLH5PC1je7nVpRxfDW9ktfI rR00bSoVX9rRkniw+xVXiLcNNvseFgwP/ownaT9cPcHllv2h1FNgiAg6l88+DhDB/6Dh LEydcHynQHYJKMPiMJCyQv1ln1wQGCYz+iZYZ0mymsfvubjCUn/fC+h/Vj/Rh/hT4HDL msNg== X-Gm-Message-State: AOUpUlESAvEd52snwPN/Bl1A5onjHakBQTbFOriyUdZ2bELNx9wdHmVF eBmjrl5gcRrH3lc8pO6z/63zPpTGrcGunsHpH2cw1h3U X-Google-Smtp-Source: AA+uWPwxg6NmB1buhgjeG8qHiLJKhjpWPzbpMTiB5QsbQT4f+IPI+XdHJFKkT+ltkSHkEDvb8EkxbbvtSycU8PcmxkU= X-Received: by 2002:a24:7f94:: with SMTP id r142-v6mr32046203itc.137.1534689575737; Sun, 19 Aug 2018 07:39:35 -0700 (PDT) MIME-Version: 1.0 References: <20180818223420.rjisst4vuxzxbcrl@kazhap> <20180819122727.4d22f99d@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180819122727.4d22f99d@thor.intern.walstatt.dynvpn.de> From: blubee blubeeme Date: Sun, 19 Aug 2018 22:39:24 +0800 Message-ID: Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: "O. Hartmann" Cc: mail@dbalan.in, FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 14:39:37 -0000 On Sun, Aug 19, 2018 at 6:30 PM O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Sun, 19 Aug 2018 00:34:20 +0200 > Dhananjay Balan schrieb: > > > Hi, > > > > I run 12-CURRENT on few machines, some more powerful that other (all > > of them x86_64, march varies). > > > > Is there is a way to avoid building CURRENT on all machines? Rather > > than building everywhere, can I just build it on the big server that I > > have and copy and update my laptop? > > > > - > > Dhananjay Balan > [...] > > Yes, you can. > We do this via a custom build and creating packages as this is introduced > at > > https://wiki.freebsd.org/PkgBase > > But beware! As many others have already stated, take care about to use th= e > least common > denominator of achitectural specifications amongst your pools! This means > to not use any > kind of optimizations for a specific CPU type for pkg-base distributed > builds! > > Because we build the local OS for fast/server machines always(!) with > optimisations, the > pkg-base builds are done in a separate way - which is very easy if you've > once understood > the really neat and great build framework of FreeBSD's! > > Instead of building the traditional (probably optimised) system from > /usr/src > and /usr/obj, now you've to consider a separate path like > /pool/sources/CURRENT/src (our > way, since we also try to build packages and object trees for 11.X), then > setup a small > build script that essentially sets > > MAKEOBJDIRPREFIX > KERNCONFDIR > KERNCONF > > and especially > > __MAKE_CONF > SRCCONF > SRC_ENV_CONF > > if you use usually optimisations for the native target build on the > building host and > more generic binaries for the Intel x86 crap for redistribution. > > Doing so, we also perform builds for some ARM64 based experimental boxes. > > The next step is then up to you how to distribute. We copy all the pkg > stuff coming out > of the build cycle to a folder which is accessible by pkg via HTTP(S) - s= o > www/apache24 > is our platform to redistribute the binaries over the network and even to > remote sites > (beware of the security implications!). You also can distribute the > obj-folder (/usr/obj, > or, if using another approach, like /pool/sources/CURRENT/obj) via NFS. > > Once you've understood the (easy to learn) concept of building the source > tree, creating > the packages for pkg-base and having dealt with the more labor for the > setting of a > distribution server, you can use the most potent server/box on you networ= k > for building > dedicated distributions > > Even a "Release" build is possible as long as there are not pitfalls like > they occured > during the transition from 11.X to more 12-CURRENT spcific development > (i.e. LINT). > > If you use pkg-base as mentioned above, be aware to setup a proper > pkg.conf file as > introduced on the Wiki and please be also aware of the fact, that there i= s > at the moment > no sharp separation between pkg-base and oridnary pkg for packages - so > take the > warinig serious, that pkg delete -a will not only kill all packages, it > also will kill > all packages installed for the base system! > > Once installed you'll see how fast compared to source build the pkg-base > installation > is (although I still prefer source build, optimised builds ...). > > And by the way: depending on the sophistication of your build script for > dedicated > tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you'r= e > able to also > build optimised binary trees for different CPU types, but you have to dea= l > yourself > with the fact that you've to put the binaries into a proper place and the= n > delegate the > URI in pkg.conf to the correct branch of your tree. The ABI environmental > variable > doesn't take care of the "set" you may have used to optimise. But this is > something > you're able to deal with easily yourself after having setup your basic > build > environment. > > Regards, > > oh > > - -- > O. Hartmann > > Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr > Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab= s. 4 BDSG). > -----BEGIN PGP SIGNATURE----- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY > lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2 > PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG > 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM > =3D/rzO > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I would say setup a poudriere build bot on your most powerful machine to build and test all the applications and tools that your weaker machines need, then setup a custom pkg repo so once poudriere builds all the ports and create packages from them. Then you use the custom pkg url to update your other machines. Quick primer on poudriere: https://www.freebsd.org/doc/handbook/ports-poudriere.html Digital Ocean did a write up on exactly what you're requesting here: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-poudriere-= build-system-to-create-packages-for-your-freebsd-servers Best, Owen From owner-freebsd-current@freebsd.org Sun Aug 19 15:00:03 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 043C5106B987 for ; Sun, 19 Aug 2018 15:00:03 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 6DA977A681 for ; Sun, 19 Aug 2018 15:00:02 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 36663 invoked by uid 89); 19 Aug 2018 14:59:53 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 19 Aug 2018 14:59:53 -0000 Date: Sun, 19 Aug 2018 16:59:51 +0200 From: Michael Gmelin To: John Baldwin Cc: Michael Gmelin , Konstantin Belousov , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180819165951.274d61b0@bsd64.grem.de> In-Reply-To: <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> References: <20180603215020.452a81d8@bsd64.grem.de> <20180603205340.GS3789@kib.kiev.ua> <20180604004632.56ca6afa@bsd64.grem.de> <20180604110654.GA2450@kib.kiev.ua> <20180604231756.2ed2adb9@bsd64.grem.de> <20180605131135.GH2450@kib.kiev.ua> <20180606010625.62632920@bsd64.grem.de> <20180815005106.69402d23@bsd64.grem.de> <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:00:03 -0000 On Fri, 17 Aug 2018 10:02:08 +0100 John Baldwin wrote: > On 8/17/18 9:54 AM, Michael Gmelin wrote: > >=20 > > =20 > >> On 17. Aug 2018, at 08:17, John Baldwin wrote: > >> =20 > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > >>> > >>> =20 > >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov > >>>> > wrote:=20 > >>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: > >>>>> > >>>>> =20 > >>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov > >>>>>>> > wrote: > >>>>>>> > >>>>>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > >>>>>>> wrote: Reviving this old thread, since I just updated to > >>>>>>> r337818 and a similar problem is happening again. Since the > >>>>>>> fix in r334799 (review https://reviews.freebsd.org/D15675) > >>>>>>> (mp_)machdep.c have been touched, so maybe this is related > >>>>>>> (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D33479= 9). > >>>>>>> > >>>>>>> Please see the screenshot of the panic below: > >>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > >>>>>>> > >>>>>>> This is me not digging any deeper, hoping that this is > >>>>>>> something obvious. Please let me know if you need more > >>>>>>> input. =20 > >>>>>> > >>>>>> I do not see how recent mp_machdep.c changes could affect this. > >>>>>> Can you try newest kernel but old loader ? =20 > >>>>> > >>>>> I will try (but that will take a while). Oh, also, it still > >>>>> boots in save mode/with smp disabled. =20 > >>>> > >>>> Right, this is because the access to that address through DMAP > >>>> is only needed when configuring AP startup resources. > >>>> > >>>> Also, I think it is safe to suggest that the bisect is needed. =20 > >>> > >>> Using an older loader didn=E2=80=99t help, but I identified the probl= em: > >>> > >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D334952 > >>> > >>> modified the code you introduced in > >>> > >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D334799 > >>> > >>> By correcting units to pages it also broke booting the Chromebook > >>> as a side effect - so the previous fix just worked due to a bug > >>> it seems. > >>> > >>> Is there an easy way to output the content of physmap at that > >>> point (debug.late_console=3D0 doesn=E2=80=99t work) - like an existing > >>> buffer I could use, or would this be more elaborate (I did > >>> something complicated last time but didn=E2=80=99t save it, so any si= mple > >>> solution would be preferred). =20 > >> > >> How about reverting the commit for now so you get a working console > >> and print out the physmap array values along with Maxmem later in > >> the boot (or just use kgdb to examine them once the system is > >> running)?=20 > >=20 > > This is before the system has a working console (part of calling > > getmem...), disabling late console makes it hang, physmap changes > > afterwards, so running kgdb later doesn=E2=80=99t help. Last time I kep= t a > > copy of physmap and logged it later to know the original content. I > > can do that again, I just thought maybe there is a simple mechanism > > I=E2=80=99m not aware of that would save me some time. =20 >=20 > I thought we only modified phys_avail[], but saving a copy of > physmap[] and dumping it from kgdb is probably the simplest thing to > do. >=20 Okay, so I had some time to investigate a bit more: Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), physmap looks like this: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x30000 0x30 2 0x40000 0x40 3 0x9e400 0x9e 4 0x100000 0x100 5 0xf00000 0xf00 6 0x1000000 0x1000 7 0x7bf7a000 0x7bf7a 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 Maxmem: 0x100600000 0x100600 Without using atop (the "buggy" version that actually boots without crashing), the loop in mp_bootaddress looks like this: i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem 8 0x100000000 0x100600000 0x100600 0x100600=20 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600=20 4 0x100000 0xf00000 0xf00 0x100600=20 2 0x40000 0x9e400 0x9e 0x100600=20 And physmap looks like this afterwards: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x30000 0x30 2 0x43000 0x43 <-- here 3 0x9e400 0x9e 4 0x100000 0x100 5 0xf00000 0xf00 6 0x1000000 0x1000 7 0x7bf7a000 0x7bf7a 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 mptramp_pagetables is 0x40000 So a three page gap was made at 0x40000 (atop(idx 2) is now 0x43 instead of 0x40) In the current version (using atop), the loop in mp_bootaddress looks like this: i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem 8 0x100000000 0x100600000 0x100600 0x100600=20 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600=20 And physmap looks like this afterwards: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x30000 0x30 2 0x40000 0x40 3 0x9e400 0x9e 4 0x100000 0x100 5 0xf00000 0xf00 6 0x1003000 0x1003 <-- here 7 0x7bf7a000 0x7bf7a 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 mptramp_pagetables: 0x1000000 So a three page gap was made at 0x1000000 (atop(idx 6) is now 0x1003 instead of 0x1000) When changing the code to require a page below 0x1000: if (physmap[i] >=3D GiB(4) || physmap[i + 1] - round_page(physmap[i]) < PAGE_SIZE * 3 || atop(physmap[i + 1]) > Maxmem || atop(physmap[i + 1]) > 0x1000) // <--- this continue; The system boots just fine. It uses page 0x100 for the bootstrap code in this case: i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem 8 0x100000000 0x100600000 0x100600 0x100600=20 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600=20 4 0x100000 0xf00000 0xf00 0x100600=20 Physmap looks like this: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x30000 0x30 2 0x40000 0x40 3 0x9e400 0x9e 4 0x103000 0x103 <-- here 5 0xf00000 0xf00 6 0x1000000 0x1000 7 0x7bf7a000 0x7bf7a 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 mptramp_pagetables: 0x100000 So for some reason it's crashing when using pages 0x1000 - 0x1003 for the bootstrap code, while it boots okay when using 0x40 - 0x43 and 0x100 - 0x103. Any ideas? Best, Michael p.s. This is what biosmem looks like Type '?' for a list of command, 'help' for more detailed help. OK biosmem bios_basemem: 0x9e400 bios_extmem: 0x3ff00000 memtop: 0x3c000000 high_heap_base: 0x3c000000 high_heap_size: 0x4000000 bios_quirks: 0x01 BQ_DISTRUST_820_EXTMEM b_bios_probed: 0x0a B_BASEMEM_12 B_EXTMEM_E801 --=20 Michael Gmelin From owner-freebsd-current@freebsd.org Sun Aug 19 15:22: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 45020106C63C for ; Sun, 19 Aug 2018 15:22:55 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E60CB7B546 for ; Sun, 19 Aug 2018 15:22:54 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from ler-imac.local (unknown [IPv6:2600:1700:210:b18f:1840:43d6:4770:35e0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ler/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9CEA419D34 for ; Sun, 19 Aug 2018 15:22:54 +0000 (UTC) (envelope-from ler@FreeBSD.org) Date: Sun, 19 Aug 2018 10:22:53 -0500 From: Larry Rosenman To: freebsd-current@FreeBSD.org Subject: LUA loader: bhyve now doesn't? Message-ID: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> Mail-Followup-To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rjw3wpe5afkm7xi7" Content-Disposition: inline User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:22:55 -0000 --rjw3wpe5afkm7xi7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With today's change to LUA as the loader, I seem to have an issue with bhyhve: Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) Startup error in /boot/lua/loader.lua: LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. /boot/kernel/kernel text=3D0x1063d88 data=3D0x12e930+0x283970 syms=3D[0x8+0= x14cf28+0x8+0x163e57] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... These VM's have been running for MONTHS. Ideas? --=20 Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --rjw3wpe5afkm7xi7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHBBAABCgCrFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5i00tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQEZyZWVCU0Qub3JnXxSAAAAAAC4AKGlz c3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRTM4 MjQ5REU3NjE1QjNCQzk4MzA1NzM2OTdDOTlCMUFCNDhBNzdEAAoJEGl8mbGrSKd9 8iYH/2p80lNNlq7bchXJqpBQoSQNkmFI26tu5DU8l9PUbOAjD0aRtVAJWKEy7gUX iqOmw39Ydk/VWQziPmQh5ECNQ2pvLvvPohABKLUEFXgyZBanDVPPVEE4GRPoe5Zd zJ/u9KNHLX1vTGNXZTJdAKrRcZxiR6l4KLKai7XTe6pvBuxv0oc698z+pvPkszDk ZSP86CAqq9PbwV2XICcTXVMzwvDtoYO6ZSt0tJS/LDtedE0iLK9DOo+HDk7PMU0K FBQt2I5E3oJplRDMai/ir/u1AUESj69ZyJmM5UDOclMxOYfRY0KunINqHJ4AXz/x k4xO90KO8dP+jkfTbEFnywtIw0M= =2e07 -----END PGP SIGNATURE----- --rjw3wpe5afkm7xi7-- From owner-freebsd-current@freebsd.org Sun Aug 19 15: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 43A1B106CBC9 for ; Sun, 19 Aug 2018 15:33:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D41CD7BB7B for ; Sun, 19 Aug 2018 15:33:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id h20-v6so17476948itf.2 for ; Sun, 19 Aug 2018 08:33:19 -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; bh=l1r57CijZ5JjmuB5kHXLGGZ6bkpnGSZOAQX0o/bxUvY=; b=YNzEdkcVm5VwxQcuLXSA+Mr2yJIg1eE117jCO0MzXdDsQcqjnxcaCtxBThm1quMi9j WIhi9X/mDZgbA4TeGB5Jsa0ZMZiY4ZlkBLrZaKTdVKVEvsWq9jVMx41FWJpMMp+G5ih0 kJzyw0iyC1gReDlncCrdy0j6xEG3ojQeICFbwD+XXEeyhIrlFInp/qt+lU37o3E97xYI t/Za5cQl1B6q9XLCbx60or7DOBgTXZfcaJdjOhPkD5bIfidzkt9OmOWEvSPheCrj7KPM 2rbg/NK0fn4w9rqr1vcyRwwWNycGxNjyrqXzfrtBhemr2Qj9ev4rwL1f23HAmpxUKVnR mLpA== 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=l1r57CijZ5JjmuB5kHXLGGZ6bkpnGSZOAQX0o/bxUvY=; b=b8fQ+qoewz1QIDpWeVfmFhBOTpwOsVUH6tKwamCzJgAU8R/JWjGJPY7L4etlPvwZZB 0R6IMWa4ZZb9PZwtT/rFxeEoCt7CMM7dhOmhmB3OYvUDiJjvDP6w94FWQp48C8FCHy+e fNXYKfsRKUGKQI1lx0eDZX2dbRx4vj3siSLw82EruP7JKOxTLXbXLL3uQzlnDbWHq2Tt azMdMNzKayVow6cmRv+8Pzou+DbKDSUPEooaJ1v+M/kBSxfm50Ye8l5Us1qMREZJH4fM TK/AfUq/yf4rqNqcu6ipY+oiNGAoS7uJXwxEh55tNZEQWr+KHAYK0oyyxBNCnRbRFG/w nsvg== X-Gm-Message-State: AOUpUlG9jCOgec3DbglFpIajyS/vsecpBj9ovhw54WEf38FcgYzmPyDf GvFoWmcVZNaRbxnhsJuMh4Jc3PQm/MHJoRrHruyMnUz8r1g= X-Google-Smtp-Source: AA+uWPyq39KLiYPMZE9l5zTwV7hR9E/Mp4BKkZOfae4AVqGPBPae1sK4u+JDr8B2fjAbLvzXvmQEMh6gN0IbnU9Yeio= X-Received: by 2002:a02:4306:: with SMTP id s6-v6mr5001697jab.140.1534692798835; Sun, 19 Aug 2018 08:33:18 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 08:33:18 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> From: Warner Losh Date: Sun, 19 Aug 2018 09:33:18 -0600 X-Google-Sender-Auth: F0yYlew6PSkgJbFzXn-1M-jQfxs Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:33:20 -0000 On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > With today's change to LUA as the loader, I seem to have an issue with > bhyhve: > > Consoles: userboot > > FreeBSD/amd64 User boot, Revision 1.1 > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > Startup error in /boot/lua/loader.lua: > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > syms=[0x8+0x14cf28+0x8+0x163e57] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > > These VM's have been running for MONTHS. > > Ideas? > There's no boot/lua/loader.lua. You can either fix that, or you can recompile with LOADER_DEFAULT_INTERP=4th for the moment. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 15:35:28 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 8FE9A106CD3C for ; Sun, 19 Aug 2018 15:35:28 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46AD67BDC7; Sun, 19 Aug 2018 15:35:28 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from ler-imac.local (unknown [IPv6:2600:1700:210:b18f:1840:43d6:4770:35e0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ler/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E78F019E31; Sun, 19 Aug 2018 15:35:27 +0000 (UTC) (envelope-from ler@FreeBSD.org) Date: Sun, 19 Aug 2018 10:35:27 -0500 From: Larry Rosenman To: Warner Losh Cc: FreeBSD Current Subject: Re: LUA loader: bhyve now doesn't? Message-ID: <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> Mail-Followup-To: Warner Losh , FreeBSD Current References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="giovbf7paetsiwye" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:35:28 -0000 --giovbf7paetsiwye Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: >=20 > > With today's change to LUA as the loader, I seem to have an issue with > > bhyhve: > > > > Consoles: userboot > > > > FreeBSD/amd64 User boot, Revision 1.1 > > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > > Startup error in /boot/lua/loader.lua: > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > /boot/kernel/kernel text=3D0x1063d88 data=3D0x12e930+0x283970 > > syms=3D[0x8+0x14cf28+0x8+0x163e57] > > Hit [Enter] to boot immediately, or any other key for command prompt. > > Booting [/boot/kernel/kernel]... > > > > These VM's have been running for MONTHS. > > > > Ideas? > > >=20 > There's no boot/lua/loader.lua. >=20 > You can either fix that, or you can recompile with > LOADER_DEFAULT_INTERP=3D4th for the moment. actually on the host there is: borg.lerctr.org /home/ler $ ls -l /boot/lua/ total 131 -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua borg.lerctr.org /home/ler $ This is when booting the vm, and it's not on the vm's disk. So the bhyveload behavior *CHANGED*. POLA? >=20 > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --giovbf7paetsiwye Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHBBAABCgCrFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5jj4tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQEZyZWVCU0Qub3JnXxSAAAAAAC4AKGlz c3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRTM4 MjQ5REU3NjE1QjNCQzk4MzA1NzM2OTdDOTlCMUFCNDhBNzdEAAoJEGl8mbGrSKd9 h2oIAK96dSXmTYSvpNpYLlrfVfKZw/2VpLq/wO7oZfJ27SxR0tV2kR8DGDbrBMd9 ILO/2SPN5wFTORQrT8KbLlHgMpdZZ70BBLa92Hb3P2HZ3mWIeInhWkNiW2Ap/EYO ghuBifU3mkoC+GueE8vkRm7ZxAgYuhZDCz4+8Ndw4tsThTE8D5YiWdfpXav5VRdp bJ2KAjsrLzKQ7zjWEB6ZtIvbc5XAzbxCjZBxgyWUQvNWzDbpTcxas3Vq7DCZ22i9 HsRoNVkiEAq9zAxBKM0D1m+OuRAVvdUGN4XUZxl781yO4Ej2XEP5/KCpGvrp+TSr fILpVVA0ra6zP2xT9RzD2N8dWq0= =80KS -----END PGP SIGNATURE----- --giovbf7paetsiwye-- From owner-freebsd-current@freebsd.org Sun Aug 19 15:42: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 AEB15106D206 for ; Sun, 19 Aug 2018 15:42:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 438777C2A9 for ; Sun, 19 Aug 2018 15:42:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x241.google.com with SMTP id l7-v6so10640183iok.6 for ; Sun, 19 Aug 2018 08:42:06 -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; bh=nZoHXt5L3yX/B/3Lzm9NXnRqBzYYOwVDoY4YWK4zeAw=; b=0qg6pDDNGzCkEt9wysZoRMMEj/Le6jA7TRfhkz+CstwAysLbupyBTDhRoaPEPwWPQn 1avAatvNglvx64/A0i75Oy/JjK1M71IGAZtK0drM2Qkf7qhglF4S8B4RvsKUDChLFZD6 ApV6+/19Q9D9WlolPlCYyLj2zEtE2m52Y+ON8HY4v4qat2lJXIRqcNRiovy4xOKk1K1O kcaRxZc/pItaABRXvCFvO1OVRnC6BsdvGGgUdUWBangwxcWoCwFdCDXm+2TqmURor3v2 K3MPgBeZ/tO87oiknbbonhyut6DBwAGUFPKOccOEne6dCeYDbfEAUzh9ILZSK5lrzVAO VxkQ== 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=nZoHXt5L3yX/B/3Lzm9NXnRqBzYYOwVDoY4YWK4zeAw=; b=eZ1AaEJiQntQXF/g+nmHpM/kYIv3X4t0SSR96jZVsCo06pged9FWmBkUYjh1LvyS6a gLGDE6jwmFdG5OrpzeCiMIhlGhTfejVXqwWW5ZQTmiIguqeHhu1k12em1D15catDZs9h nJyyJrVejmAgqL0gAWTm7GCn9nde8y3QsI+gRHuHhhUPjg0MZ+aZOBTHGXDYnZiqFsxE S3rosa2WtnB/RVlIxBwpXRUWpDNpTEC8k12dK8Lw7Hj1GaTd+O5B3mSDMnk+Hfc96pWR HUdvXc4AAlOZDmeJzavah8SpCFQV5DWlfNsLRDh5rGkbsJe3/iCGI6fq2qdcKfdWFWie dTkw== X-Gm-Message-State: AOUpUlE5j0av3bDUSWFHGXlqKEIbKc80zIGgnCPE0XyWZIY/NlDmdapc NIkd24xoXkZtmiY0mM7rZYaatWIbk2zzG4QxKEOTrw== X-Google-Smtp-Source: AA+uWPy9Z3Uu2CxdTZHv5KUjtzg6GwR3GGr0maxRwfdCp/DC75Ku1Fi+fD5XK2PAMRpVBNaZB/Hl70gznh0C7uSvOAw= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr34953255ioa.299.1534693325573; Sun, 19 Aug 2018 08:42:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 08:42:05 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> From: Warner Losh Date: Sun, 19 Aug 2018 09:42:05 -0600 X-Google-Sender-Auth: X32tfPkd2g38QRA-6FzXsWr3Yl4 Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:42:07 -0000 On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > > > With today's change to LUA as the loader, I seem to have an issue with > > > bhyhve: > > > > > > Consoles: userboot > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > > > Startup error in /boot/lua/loader.lua: > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > > syms=[0x8+0x14cf28+0x8+0x163e57] > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > > > > These VM's have been running for MONTHS. > > > > > > Ideas? > > > > > > > There's no boot/lua/loader.lua. > > > > You can either fix that, or you can recompile with > > LOADER_DEFAULT_INTERP=4th for the moment. > actually on the host there is: > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > total 131 > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > borg.lerctr.org /home/ler $ > > This is when booting the vm, and it's not on the vm's disk. > > So the bhyveload behavior *CHANGED*. > > POLA? > Unlikely, but a couple of questions. Have you always used the LUA loader, or is this a change with the recent default switch? And to be clear, you expect the host's file to be used for this, not the VM filesystem? I'll look into this later today. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 15:47: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 85457106D3BD for ; Sun, 19 Aug 2018 15:47:19 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24B9C7C490; Sun, 19 Aug 2018 15:47:19 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from ler-imac.local (unknown [IPv6:2600:1700:210:b18f:1840:43d6:4770:35e0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ler/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id BA7F419F2F; Sun, 19 Aug 2018 15:47:18 +0000 (UTC) (envelope-from ler@FreeBSD.org) Date: Sun, 19 Aug 2018 10:47:17 -0500 From: Larry Rosenman To: Warner Losh Cc: FreeBSD Current Subject: Re: LUA loader: bhyve now doesn't? Message-ID: <20180819154717.z5bztzo6r5vly5ha@ler-imac.local> Mail-Followup-To: Warner Losh , FreeBSD Current References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gigg5ztclixougdn" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:47:19 -0000 --gigg5ztclixougdn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2018 at 09:42:05AM -0600, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: >=20 > > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wro= te: > > > > > > > With today's change to LUA as the loader, I seem to have an issue w= ith > > > > bhyhve: > > > > > > > > Consoles: userboot > > > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > > > > Startup error in /boot/lua/loader.lua: > > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or direct= ory. > > > > > > > > /boot/kernel/kernel text=3D0x1063d88 data=3D0x12e930+0x283970 > > > > syms=3D[0x8+0x14cf28+0x8+0x163e57] > > > > Hit [Enter] to boot immediately, or any other key for command promp= t. > > > > Booting [/boot/kernel/kernel]... > > > > > > > > These VM's have been running for MONTHS. > > > > > > > > Ideas? > > > > > > > > > > There's no boot/lua/loader.lua. > > > > > > You can either fix that, or you can recompile with > > > LOADER_DEFAULT_INTERP=3D4th for the moment. > > actually on the host there is: > > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > > total 131 > > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > > borg.lerctr.org /home/ler $ > > > > This is when booting the vm, and it's not on the vm's disk. > > > > So the bhyveload behavior *CHANGED*. > > > > POLA? > > >=20 > Unlikely, but a couple of questions. Have you always used the LUA loader, > or is this a change with the recent default switch? I've *NEVER* used the lua loader until today's default change. >=20 > And to be clear, you expect the host's file to be used for this, not the = VM > filesystem? No, but apparently /boot/userboot.so (from the host?) DOES expect the VM's disk to have lua now.=20 >=20 > I'll look into this later today. Thanks. >=20 > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --gigg5ztclixougdn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHBBAABCgCrFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5kQUtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQEZyZWVCU0Qub3JnXxSAAAAAAC4AKGlz c3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRTM4 MjQ5REU3NjE1QjNCQzk4MzA1NzM2OTdDOTlCMUFCNDhBNzdEAAoJEGl8mbGrSKd9 348H/1x0C5zkGfUfEBJWUdS1xJ2RBTsWVewl2DimcUNerkfJ3HyO3+EPakt1sHzN VRbwhIOWfiifShP7F5VxycNoKOjMfmwxGk9K/O3sNpK6VhwRE+NUhGMBnuIcF7kQ Watxqe/5Y5z3pK9WVSfO68IJOfxV7XzcuA5qlJ2Z7DtHqndZ2C5NXXPd1J6e2Ad7 4dpKvEeLW0HERfVE06hqySCXXMXLX9dcwNG8Uu1ZPWo10lsiToYdBfgHhAc7I9Rs NH0426xkvXoSyGkXbMYcdCxHI/P/JDTyB9ijE7VguBNY5zoj2hTGgD5B+Mo5fvVv cwtK5Rf+oE2zeQqD4HXzaDzDtmA= =VPoa -----END PGP SIGNATURE----- --gigg5ztclixougdn-- From owner-freebsd-current@freebsd.org Sun Aug 19 15:55: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 22049106D9A6 for ; Sun, 19 Aug 2018 15:55:04 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C0FE7C985 for ; Sun, 19 Aug 2018 15:55:03 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: by mail-ed1-x536.google.com with SMTP id e19-v6so7066108edq.7 for ; Sun, 19 Aug 2018 08:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=P2UAjEH9FNbqGNUQAe07aQNh766d1mnYudtEs4LRCjE=; b=WuwrKSjA8jmdD+iPEeD63c7SUXQ/IT6dnM+UPbvwhFJ/jatXCqF8tRFjgkPAnOpWFf 4fUZ6NJwt1Amf2wRgPOp+Gbv9shKtShVPwROC4n67ZwbFx7EMe0LAZIQ7XiXZJQEo10Q U3PMctuAf+c7dV/FZbT9IQAXrzVVsQVEex3AbAzgLAWboXSmBmfk/m1aY7ylD0/dx0mC C9fa3mOmK0mvw69oV4RJAhRXJ7ZLIWjhU9xK15ay8BjWOxXc/T3hw+RoTDQcHrIeC2oX jQS2sT/f+U1mAqCV2ZV2uVNHCRMegPy18c7UTVJ/XtHcaqHF08R7uW3zdSvL+EbQgNad uuhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=P2UAjEH9FNbqGNUQAe07aQNh766d1mnYudtEs4LRCjE=; b=RFhSwWXtYs4g2+2h6aTvrEq1aWN4agcQx6Od7x6qykh73aLjGpAQbcoKJaGvc8bKRD 4a4vb227tBPU7cOxpM/GiQyV0iYYJIv5pP9BdwY4MXhlDl4KV1XWHbjdfhecJEXZDHWk m9chhEd+Ds28npviSKJruG4NUz6MxEljQht4xvMr/wa53NMg6pUlbb2E3jb5LnusaoAD cpezpv/DiTzM0AZEGZt4LIpKxRHbdM6YsNEPwY3wMWGC90q8VN2nKYl6B5qRHLuyZngd LMPDa6asHxZRaPbfVsqzjccReRhJNXrH7GLiSRyow/wBwSuz/F4dhFzKjvAi0hMocnoq gyAg== X-Gm-Message-State: AOUpUlGdCVeizGjilmpRPstJs+MmfFPEhL1NjlY6AQjSF9dwqEqh9xHT MWJhD4paj/m9/jSfhvpXWVRrOWnXYUTLSJFRmQVqjA== X-Google-Smtp-Source: AA+uWPzT47+op40jdzenVNLqcax1g5XDycTaB+WzHtER8VKF11ORIA5W0lx3wnkFyig2GpCKBRSTSNufBJzhAxNHmsc= X-Received: by 2002:aa7:c592:: with SMTP id g18-v6mr32017662edq.214.1534694102489; Sun, 19 Aug 2018 08:55:02 -0700 (PDT) MIME-Version: 1.0 References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> In-Reply-To: <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> From: Joe Maloney Date: Sun, 19 Aug 2018 11:54:51 -0400 Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Warner Losh , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 15:55:04 -0000 I ran into this as well months ago. To workaround it I extracted userboot.so for the VM's, and launched bhyve with the alternate userboot.so. You can use a flag as described in the manpage to start userboot.so from an alternate location. https://www.freebsd.org/cgi/man.cgi?query=bhyveload&sektion=8 Also support was recently added for vm-bhyve to specify alternate userboot.so location for one that is compatible with 4th. You just need to extract that somewhere onto the host, and specify it to load when starting the VM. https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample Alternatively you could just use UEFI, or UEFI-CSM firmware. Joe Maloney QA Manager / iXsystems Enterprise Storage & Servers Driven By Open Source On Sun, Aug 19, 2018 at 11:38 AM Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: > > > > > With today's change to LUA as the loader, I seem to have an issue with > > > bhyhve: > > > > > > Consoles: userboot > > > > > > FreeBSD/amd64 User boot, Revision 1.1 > > > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > > > Startup error in /boot/lua/loader.lua: > > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. > > > > > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > > > syms=[0x8+0x14cf28+0x8+0x163e57] > > > Hit [Enter] to boot immediately, or any other key for command prompt. > > > Booting [/boot/kernel/kernel]... > > > > > > These VM's have been running for MONTHS. > > > > > > Ideas? > > > > > > > There's no boot/lua/loader.lua. > > > > You can either fix that, or you can recompile with > > LOADER_DEFAULT_INTERP=4th for the moment. > actually on the host there is: > borg.lerctr.org /home/ler $ ls -l /boot/lua/ > total 131 > -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > borg.lerctr.org /home/ler $ > > This is when booting the vm, and it's not on the vm's disk. > > So the bhyveload behavior *CHANGED*. > > POLA? > > > > > > Warner > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > -- > Larry Rosenman https://people.FreeBSD.org/~ler/ > Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 > From owner-freebsd-current@freebsd.org Sun Aug 19 16:05:05 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 EA703106E10F for ; Sun, 19 Aug 2018 16:05:04 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FCDA7D1E2; Sun, 19 Aug 2018 16:05:04 +0000 (UTC) (envelope-from ler@FreeBSD.org) Received: from ler-imac.local (unknown [IPv6:2600:1700:210:b18f:1840:43d6:4770:35e0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ler/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 3FD951A140; Sun, 19 Aug 2018 16:05:04 +0000 (UTC) (envelope-from ler@FreeBSD.org) Date: Sun, 19 Aug 2018 11:05:03 -0500 From: Larry Rosenman To: Joe Maloney Cc: Warner Losh , freebsd-current Subject: Re: LUA loader: bhyve now doesn't? Message-ID: <20180819160503.nlns5pz6rnt7afzo@ler-imac.local> Mail-Followup-To: Joe Maloney , Warner Losh , freebsd-current References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="txw55ze4olmz6eii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 16:05:05 -0000 --txw55ze4olmz6eii Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2018 at 11:54:51AM -0400, Joe Maloney wrote: > I ran into this as well months ago. To workaround it I extracted > userboot.so for the VM's, and launched bhyve with the alternate > userboot.so. You can use a flag as described in the manpage to start > userboot.so from an alternate location. >=20 > https://www.freebsd.org/cgi/man.cgi?query=3Dbhyveload&sektion=3D8 >=20 > Also support was recently added for vm-bhyve to specify alternate > userboot.so location for one that is compatible with 4th. You just need = to > extract that somewhere onto the host, and specify it to load when starting > the VM. >=20 > https://github.com/churchers/vm-bhyve/blob/d4532f6da3e155a4430acbb9138e59= c0d5abfc39/sample-templates/config.sample >=20 > Alternatively you could just use UEFI, or UEFI-CSM firmware. Ok, so pulling /boot/userboot.so from my non-upgraded 12 system and putting it in /boot/userboot-4th.so on the host allows the VM's to boot after changing the config files to point bhyveload_loader to it (yes, I'm using vm-bhyve).=20 This default change is a POLA violation for bhyve/vm-bhyve users.=20 [snip] --=20 Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: ler@FreeBSD.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --txw55ze4olmz6eii Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHBBAABCgCrFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5lS8tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQEZyZWVCU0Qub3JnXxSAAAAAAC4AKGlz c3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRTM4 MjQ5REU3NjE1QjNCQzk4MzA1NzM2OTdDOTlCMUFCNDhBNzdEAAoJEGl8mbGrSKd9 iuMH/R3VRKZcy4D5+Nr2zfgULwcKMhr/2HDnaLZo+ooKiy3HUgTma4fsxSU9jKrk H++GJxYuS1RX/Kak64SYfjaAOMKjcJTjjD2H//sTlke5A9rtbz8385Nag2ib/Lfs qAUKV6dJMreQlzPL8JQ/wCnRyBLOFFK3ttbYraPYqApwA0GBmMKmW70qH/8Psq8a zTzDT6tm2XwW01yvNONw6QddOqZzFhAQG9YmjmAKD++nQmAxOIKv37ouy+uR6TNn aDNHlfNIbp1/VZeBIXVageg36ifGek5o9ZOFaViQj3zodS4TclxSAHUxd2oSYud4 9U8Po5qPegLa+pRFenDt7HPk5s8= =6eqV -----END PGP SIGNATURE----- --txw55ze4olmz6eii-- From owner-freebsd-current@freebsd.org Sun Aug 19 16:06: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 8BFF3106E19A for ; Sun, 19 Aug 2018 16:06:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 208D67D29F for ; Sun, 19 Aug 2018 16:06:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x236.google.com with SMTP id y12-v6so932374ioj.13 for ; Sun, 19 Aug 2018 09:06:06 -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; bh=xetQqMp/mrJ2E95wWjJHzH3DqHq+jTK/6JtDsQRYLwQ=; b=QJKEcCx07d2mXIg1w/zFkbGfFrWbJmWLlXUAT48MiBPSHc4SteVjTycybWrPV1T6NA 98sMRKxa0WQC+nOzSvU6tF9E9VJ6gmqGiKpsaqWeOPpfpmHUnxuOSiOB8hhoTSFr+NBU PAllKxgMLXbpyaEZgxdqZI9q3WtacO5cQ+cOktC1zk5qqF2M+P+GPsC3Ev90DBD4iHOu OxmO1ZUmvKImq6kjz475edsIOb8+ei0rAhSXfJaEUDJ+yWG0ec8RItxj+GWqo76tSpBz vWSI03j1EKv7atDI7j7kHvPJvJrwmkYke3MgVxRsOmFSq7kmvLhRywWNRpEJF6+M1rWW Lphw== 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=xetQqMp/mrJ2E95wWjJHzH3DqHq+jTK/6JtDsQRYLwQ=; b=NLzu7GhITeG9csLTamOHd8JSfiGa59OoeZGkJFD4BQXlsHHEgm9anZd3kxuhzqhvUn +oLGVamHcmF5ICjiCmnd01bo+2GeLED0tCTrdpae4jQ32On4mqAw3iZhhMJA9pndKfc+ 4X0fuqr+zeOiBLIOJBtdWqpT+kGonGwS//DQg+sm8Bx4NY4wCIbYH4J9yJiiHrIvHZBO ULhquAYcu7He3joO6X6Ajp0NUTHdp3Jqsf7EJAp3Sn4sLFac+iE7rBGYE+r8IaO0zz+k 11zWPHDDaUwGGBtMnqTeYiKqGKBC/8pUxnwn+DndTuyvmpQpblRCtziBxKlqevjX7tVL o+/g== X-Gm-Message-State: AOUpUlGHqr272E8LWG5HQPVYsl0PWaC/FdEYY/OIt3xCohApnB/SYjys 9FThP7U/VwdpRKWBKOWn19n+7zSrOGDv77o2EgFV0w== X-Google-Smtp-Source: AA+uWPxZGfbtjfhe07J856UbdL73hDPDGhR8g1wUkjrAyj8CzB+YJbUDZ317NCGI1dg8KShzxvnGV0wFDP2afTO8ZoY= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr35862140ioa.168.1534694765296; Sun, 19 Aug 2018 09:06:05 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 09:06:04 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180819160503.nlns5pz6rnt7afzo@ler-imac.local> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <20180819160503.nlns5pz6rnt7afzo@ler-imac.local> From: Warner Losh Date: Sun, 19 Aug 2018 10:06:04 -0600 X-Google-Sender-Auth: XQlUPbElWb6Iy6rrmKUEzQwDk3M Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Joe Maloney , Warner Losh , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 16:06:06 -0000 On Sun, Aug 19, 2018 at 10:05 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 11:54:51AM -0400, Joe Maloney wrote: > > I ran into this as well months ago. To workaround it I extracted > > userboot.so for the VM's, and launched bhyve with the alternate > > userboot.so. You can use a flag as described in the manpage to start > > userboot.so from an alternate location. > > > > https://www.freebsd.org/cgi/man.cgi?query=bhyveload&sektion=8 > > > > Also support was recently added for vm-bhyve to specify alternate > > userboot.so location for one that is compatible with 4th. You just need > to > > extract that somewhere onto the host, and specify it to load when > starting > > the VM. > > > > https://github.com/churchers/vm-bhyve/blob/ > d4532f6da3e155a4430acbb9138e59c0d5abfc39/sample-templates/config.sample > > > > Alternatively you could just use UEFI, or UEFI-CSM firmware. > Ok, so pulling /boot/userboot.so from my non-upgraded 12 system and > putting it in /boot/userboot-4th.so on the host allows the VM's to boot > after changing the config files to point bhyveload_loader to it (yes, > I'm using vm-bhyve). > > This default change is a POLA violation for bhyve/vm-bhyve users. OK. We're on it. Thanks for the heads up. We were unaware of the issue when we flipped the switch. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 16:16: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 828B3106E802 for ; Sun, 19 Aug 2018 16:16:59 +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 E80297DA62; Sun, 19 Aug 2018 16:16:58 +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 w7JGGgPO084252 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Aug 2018 19:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7JGGgPO084252 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7JGGgxK084251; Sun, 19 Aug 2018 19:16:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 19 Aug 2018 19:16:42 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180819161642.GP2340@kib.kiev.ua> References: <20180606010625.62632920@bsd64.grem.de> <20180815005106.69402d23@bsd64.grem.de> <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180819165951.274d61b0@bsd64.grem.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 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, 19 Aug 2018 16:16:59 -0000 On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote: > > > On Fri, 17 Aug 2018 10:02:08 +0100 > John Baldwin wrote: > > > On 8/17/18 9:54 AM, Michael Gmelin wrote: > > > > > > > > >> On 17. Aug 2018, at 08:17, John Baldwin wrote: > > >> > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > > >>> > > >>> > > >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov > > >>>> > wrote: > > >>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin wrote: > > >>>>> > > >>>>> > > >>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > >>>>>>> > wrote: > > >>>>>>> > > >>>>>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > > >>>>>>> wrote: Reviving this old thread, since I just updated to > > >>>>>>> r337818 and a similar problem is happening again. Since the > > >>>>>>> fix in r334799 (review https://reviews.freebsd.org/D15675) > > >>>>>>> (mp_)machdep.c have been touched, so maybe this is related > > >>>>>>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). > > >>>>>>> > > >>>>>>> Please see the screenshot of the panic below: > > >>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > > >>>>>>> > > >>>>>>> This is me not digging any deeper, hoping that this is > > >>>>>>> something obvious. Please let me know if you need more > > >>>>>>> input. > > >>>>>> > > >>>>>> I do not see how recent mp_machdep.c changes could affect this. > > >>>>>> Can you try newest kernel but old loader ? > > >>>>> > > >>>>> I will try (but that will take a while). Oh, also, it still > > >>>>> boots in save mode/with smp disabled. > > >>>> > > >>>> Right, this is because the access to that address through DMAP > > >>>> is only needed when configuring AP startup resources. > > >>>> > > >>>> Also, I think it is safe to suggest that the bisect is needed. > > >>> > > >>> Using an older loader didn???t help, but I identified the problem: > > >>> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 > > >>> > > >>> modified the code you introduced in > > >>> > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 > > >>> > > >>> By correcting units to pages it also broke booting the Chromebook > > >>> as a side effect - so the previous fix just worked due to a bug > > >>> it seems. > > >>> > > >>> Is there an easy way to output the content of physmap at that > > >>> point (debug.late_console=0 doesn???t work) - like an existing > > >>> buffer I could use, or would this be more elaborate (I did > > >>> something complicated last time but didn???t save it, so any simple > > >>> solution would be preferred). > > >> > > >> How about reverting the commit for now so you get a working console > > >> and print out the physmap array values along with Maxmem later in > > >> the boot (or just use kgdb to examine them once the system is > > >> running)? > > > > > > This is before the system has a working console (part of calling > > > getmem...), disabling late console makes it hang, physmap changes > > > afterwards, so running kgdb later doesn???t help. Last time I kept a > > > copy of physmap and logged it later to know the original content. I > > > can do that again, I just thought maybe there is a simple mechanism > > > I???m not aware of that would save me some time. > > > > I thought we only modified phys_avail[], but saving a copy of > > physmap[] and dumping it from kgdb is probably the simplest thing to > > do. > > > > Okay, so I had some time to investigate a bit more: > > Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), > physmap looks like this: > > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x30000 0x30 > 2 0x40000 0x40 > 3 0x9e400 0x9e > 4 0x100000 0x100 > 5 0xf00000 0xf00 > 6 0x1000000 0x1000 > 7 0x7bf7a000 0x7bf7a > 8 0x100000000 0x100000 > 9 0x100600000 0x100600 > 10 0x0 0x0 > Maxmem: 0x100600000 0x100600 > > Without using atop (the "buggy" version that actually boots without > crashing), the loop in mp_bootaddress looks like this: > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > 8 0x100000000 0x100600000 0x100600 0x100600 > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > 4 0x100000 0xf00000 0xf00 0x100600 > 2 0x40000 0x9e400 0x9e 0x100600 > > And physmap looks like this afterwards: > > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x30000 0x30 > 2 0x43000 0x43 <-- here > 3 0x9e400 0x9e > 4 0x100000 0x100 > 5 0xf00000 0xf00 > 6 0x1000000 0x1000 > 7 0x7bf7a000 0x7bf7a > 8 0x100000000 0x100000 > 9 0x100600000 0x100600 > 10 0x0 0x0 > mptramp_pagetables is 0x40000 > > So a three page gap was made at 0x40000 (atop(idx 2) is now 0x43 > instead of 0x40) > > In the current version (using atop), the loop in mp_bootaddress > looks like this: > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > 8 0x100000000 0x100600000 0x100600 0x100600 > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > > And physmap looks like this afterwards: > > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x30000 0x30 > 2 0x40000 0x40 > 3 0x9e400 0x9e > 4 0x100000 0x100 > 5 0xf00000 0xf00 > 6 0x1003000 0x1003 <-- here > 7 0x7bf7a000 0x7bf7a > 8 0x100000000 0x100000 > 9 0x100600000 0x100600 > 10 0x0 0x0 > mptramp_pagetables: 0x1000000 > > So a three page gap was made at 0x1000000 (atop(idx 6) is now > 0x1003 instead of 0x1000) > > When changing the code to require a page below 0x1000: > > if (physmap[i] >= GiB(4) || physmap[i + 1] - > round_page(physmap[i]) < PAGE_SIZE * 3 || > atop(physmap[i + 1]) > Maxmem > || atop(physmap[i + 1]) > 0x1000) // <--- this > continue; > > The system boots just fine. It uses page 0x100 > for the bootstrap code in this case: > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > 8 0x100000000 0x100600000 0x100600 0x100600 > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > 4 0x100000 0xf00000 0xf00 0x100600 > > Physmap looks like this: > physmap_idx: 8 > i mem atop > 0 0x0 0x0 > 1 0x30000 0x30 > 2 0x40000 0x40 > 3 0x9e400 0x9e > 4 0x103000 0x103 <-- here > 5 0xf00000 0xf00 > 6 0x1000000 0x1000 > 7 0x7bf7a000 0x7bf7a > 8 0x100000000 0x100000 > 9 0x100600000 0x100600 > 10 0x0 0x0 > mptramp_pagetables: 0x100000 > > So for some reason it's crashing when using pages 0x1000 - 0x1003 for > the bootstrap code, while it boots okay when using 0x40 - 0x43 and > 0x100 - 0x103. > > Any ideas? I in fact misread the page fault state decoding in your photo. It is curiously protection violation on write, instead of non-present page access. Compile ddb into your kernel, then on fault do db> x/x dmaplimit db> x/x dmaplimit+4 db> show pte Also show me the verbose dmesg lines with CPU features identification. > > Best, > Michael > > p.s. This is what biosmem looks like > > Type '?' for a list of command, 'help' for more detailed > help. > OK biosmem > bios_basemem: 0x9e400 > bios_extmem: 0x3ff00000 > memtop: 0x3c000000 > high_heap_base: 0x3c000000 > high_heap_size: 0x4000000 > bios_quirks: 0x01 BQ_DISTRUST_820_EXTMEM > b_bios_probed: 0x0a B_BASEMEM_12 B_EXTMEM_E801 > > -- > Michael Gmelin From owner-freebsd-current@freebsd.org Sun Aug 19 16:28: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 CA89B106ED36 for ; Sun, 19 Aug 2018 16:28:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78FA47E0A2; Sun, 19 Aug 2018 16:28:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 170FA1A33A; Sun, 19 Aug 2018 16:28:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f52.google.com with SMTP id a4-v6so9153270lff.5; Sun, 19 Aug 2018 09:28:32 -0700 (PDT) X-Gm-Message-State: AOUpUlGDGSDM2ROe8eUIQymBZdMgNH5guxOHh8TCx+dReHw9O1iNRRpL b8yqeJG2yF4XRymiO2o8trrMI7o7sQUWolYnqUY= X-Google-Smtp-Source: AA+uWPyxJCoA0AcWh3OL5Sb+3hl1K2o+WmVEx4IF2rAiF8d3EqRBzNv7Ydv2tPxHHIqB5SJRjrkiAj+PJjBcUzMmgRM= X-Received: by 2002:a19:ca09:: with SMTP id a9-v6mr5778599lfg.120.1534696110606; Sun, 19 Aug 2018 09:28:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 09:28:10 -0700 (PDT) In-Reply-To: References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> From: Kyle Evans Date: Sun, 19 Aug 2018 11:28:10 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Warner Losh Cc: FreeBSD Current , John Baldwin , tychon@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 16:28:33 -0000 On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: > >> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: >> > On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: >> > >> > > With today's change to LUA as the loader, I seem to have an issue with >> > > bhyhve: >> > > >> > > Consoles: userboot >> > > >> > > FreeBSD/amd64 User boot, Revision 1.1 >> > > (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) >> > > Startup error in /boot/lua/loader.lua: >> > > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >> > > >> > > /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 >> > > syms=[0x8+0x14cf28+0x8+0x163e57] >> > > Hit [Enter] to boot immediately, or any other key for command prompt. >> > > Booting [/boot/kernel/kernel]... >> > > >> > > These VM's have been running for MONTHS. >> > > >> > > Ideas? >> > > >> > >> > There's no boot/lua/loader.lua. >> > >> > You can either fix that, or you can recompile with >> > LOADER_DEFAULT_INTERP=4th for the moment. >> actually on the host there is: >> borg.lerctr.org /home/ler $ ls -l /boot/lua/ >> total 131 >> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua >> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua >> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua >> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua >> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua >> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua >> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua >> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua >> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua >> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua >> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua >> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua >> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua >> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua >> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua >> borg.lerctr.org /home/ler $ >> >> This is when booting the vm, and it's not on the vm's disk. >> >> So the bhyveload behavior *CHANGED*. >> >> POLA? >> > > Unlikely, but a couple of questions. Have you always used the LUA loader, > or is this a change with the recent default switch? > > And to be clear, you expect the host's file to be used for this, not the VM > filesystem? > (CC'ing jhb@ and tychon@, who might have better insight) If we can swing it, I think the best model here should have always been that userboot uses the host's scripts but the guest's loader.conf. The current model doesn't tolerate any mismatch between host and guest and looks unsustainable. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Sun Aug 19 16:35:22 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 F209D106F1FD for ; Sun, 19 Aug 2018 16:35:21 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94E207E6BD; Sun, 19 Aug 2018 16:35:21 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YvpjoXqGnULV2Kz2K7TF9p/l7I8b96FWedPTg2Owg1I=; b=NTIh8QC2LSePB/XnXJFEmTp/eY 6xaC654XR6rCLuT2LkFH7rY9JiQbvD2+/ZjSD+MDhXx8gAjY3q4srvHrL09IM53yncxBS3W1WDhLf 8Xxh5g1bnDjXV8YB0R8JXmHLUCyZqDjjO5SDgfqXbNJgSf/948MXJjnXvT7XBi7xrYAQ=; Received: from [2600:1700:210:b18f:1840:43d6:4770:35e0] (port=61385 helo=ler-imac.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1frQfg-000Ffh-DH; Sun, 19 Aug 2018 11:35:20 -0500 Date: Sun, 19 Aug 2018 11:35:19 -0500 From: Larry Rosenman To: Kyle Evans Cc: freebsd-current@freebsd.org Subject: Re: LUA loader: bhyve now doesn't? Message-ID: <20180819163519.ss2nyhpxl7abpzzn@ler-imac.local> Mail-Followup-To: Kyle Evans , freebsd-current@freebsd.org References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uanlehr24of4rc4u" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 16:35:22 -0000 --uanlehr24of4rc4u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote: > > filesystem? > > >=20 > (CC'ing jhb@ and tychon@, who might have better insight) >=20 > If we can swing it, I think the best model here should have always > been that userboot uses the host's scripts but the guest's > loader.conf. The current model doesn't tolerate any mismatch between > host and guest and looks unsustainable. Yeah, I have a FreeBSD-10, and a HardendBSD-12 VM, and BOTH failed until I loaded the old /boot/userboot.so to my host.=20 We really need to tolerate this condition, and NOT surprise the user. >=20 > Thanks, >=20 > 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" --=20 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --uanlehr24of4rc4u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHABAABCgCqFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5nEcsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQGxlcmN0ci5vcmdfFIAAAAAALgAoaXNz dWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFFMzgy NDlERTc2MTVCM0JDOTgzMDU3MzY5N0M5OUIxQUI0OEE3N0QACgkQaXyZsatIp33i 7gf+KcoHJUfeodi125ac2/79WhrrUUIHUbTNB4U8fI8BbXuU4guhP5LbYDxgewYf qUIoflQcjrcPYSmeuLV4ah1N19LPm4kB6IHab19/+SwIGr3tPLsIRVp2wuSn5Fe4 VD2f9gmM7vctRimXYxLuO/2TXqH45Q79ECptA2dj/ce/j7W2rOju8RQ3VLQb2ROU NYAaAmtG386JN3rsNTKQR3CU0fsScIxecW2eK8YXmHfzZImwBCODc6rxLgNF/yVg aEGSmZ07XkDY0hvukFaGFIC5x5d5e9QRqEQ6qD5NIFQEuT0VFE4k3GUEqmn1SLaX mdlouoM8ok49e4SP4NNHG5/+tw== =Mcvi -----END PGP SIGNATURE----- --uanlehr24of4rc4u-- From owner-freebsd-current@freebsd.org Sun Aug 19 16:36: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 8B1A1106F334 for ; Sun, 19 Aug 2018 16:36:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9BE7E8D1; Sun, 19 Aug 2018 16:36:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id CFF4A1A44D; Sun, 19 Aug 2018 16:36:58 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f46.google.com with SMTP id r4-v6so2127588lff.12; Sun, 19 Aug 2018 09:36:58 -0700 (PDT) X-Gm-Message-State: AOUpUlHSHzwyaVm0VoX2pSmdZ+KBUoP0htSuxANydHU81xVlA4QrHgAx p6jd0JyMIQbOrNbg2slyjjoBM3xKIDl06YXiHt8= X-Google-Smtp-Source: AA+uWPzDOAnAQQzq3pMpFAoFZtEV9l7L4gqhzk9plFZn6+rPAtc2IRqGV0DW/fFlVF9vKy1kpzjwf/dqmp+zNSZnoLk= X-Received: by 2002:a19:26d2:: with SMTP id m201-v6mr26188603lfm.43.1534696617469; Sun, 19 Aug 2018 09:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 09:36:36 -0700 (PDT) In-Reply-To: <20180819163519.ss2nyhpxl7abpzzn@ler-imac.local> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <20180819163519.ss2nyhpxl7abpzzn@ler-imac.local> From: Kyle Evans Date: Sun, 19 Aug 2018 11:36:36 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Kyle Evans , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 16:36:59 -0000 On Sun, Aug 19, 2018 at 11:35 AM, Larry Rosenman wrote: > On Sun, Aug 19, 2018 at 11:28:10AM -0500, Kyle Evans wrote: >> > filesystem? >> > >> >> (CC'ing jhb@ and tychon@, who might have better insight) >> >> If we can swing it, I think the best model here should have always >> been that userboot uses the host's scripts but the guest's >> loader.conf. The current model doesn't tolerate any mismatch between >> host and guest and looks unsustainable. > > Yeah, I have a FreeBSD-10, and a HardendBSD-12 VM, and BOTH failed until > I loaded the old /boot/userboot.so to my host. > > We really need to tolerate this condition, and NOT surprise the user. Right. That's what we're trying to figure out here, the best route forward to make this stuff reliably work. From owner-freebsd-current@freebsd.org Sun Aug 19 16:58: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 A71CE106FE58 for ; Sun, 19 Aug 2018 16:58:45 +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 4C1357FC16; Sun, 19 Aug 2018 16:58:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [51.52.172.98]) by mail.baldwin.cx (Postfix) with ESMTPSA id 17B4310A87D; Sun, 19 Aug 2018 12:58:44 -0400 (EDT) Subject: Re: LUA loader: bhyve now doesn't? To: Kyle Evans , Warner Losh References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> Cc: FreeBSD Current , tychon@freebsd.org From: John Baldwin Message-ID: <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> Date: Sun, 19 Aug 2018 17:58:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sun, 19 Aug 2018 12:58:44 -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.27 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, 19 Aug 2018 16:58:45 -0000 On 8/19/18 5:28 PM, Kyle Evans wrote: > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: >> >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: >>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: >>>> >>>>> With today's change to LUA as the loader, I seem to have an issue with >>>>> bhyhve: >>>>> >>>>> Consoles: userboot >>>>> >>>>> FreeBSD/amd64 User boot, Revision 1.1 >>>>> (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) >>>>> Startup error in /boot/lua/loader.lua: >>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >>>>> >>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 >>>>> syms=[0x8+0x14cf28+0x8+0x163e57] >>>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>>> Booting [/boot/kernel/kernel]... >>>>> >>>>> These VM's have been running for MONTHS. >>>>> >>>>> Ideas? >>>>> >>>> >>>> There's no boot/lua/loader.lua. >>>> >>>> You can either fix that, or you can recompile with >>>> LOADER_DEFAULT_INTERP=4th for the moment. >>> actually on the host there is: >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ >>> total 131 >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua >>> borg.lerctr.org /home/ler $ >>> >>> This is when booting the vm, and it's not on the vm's disk. >>> >>> So the bhyveload behavior *CHANGED*. >>> >>> POLA? >>> >> >> Unlikely, but a couple of questions. Have you always used the LUA loader, >> or is this a change with the recent default switch? >> >> And to be clear, you expect the host's file to be used for this, not the VM >> filesystem? >> > > (CC'ing jhb@ and tychon@, who might have better insight) > > If we can swing it, I think the best model here should have always > been that userboot uses the host's scripts but the guest's > loader.conf. The current model doesn't tolerate any mismatch between > host and guest and looks unsustainable. Err, normally guests read things out of the a guest disk image (think most VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk image. Now, userboot isn't memory limited like the BIOS boot, so if it's possible to have userboot just include both lua and forth perhaps with some auto-detection based on what is in /boot/loader.rc to determine which interpreter to use, that is really the best path forward. -- John Baldwin From owner-freebsd-current@freebsd.org Sun Aug 19 17:03: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 58FDC10704A5 for ; Sun, 19 Aug 2018 17:03:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B80980157; Sun, 19 Aug 2018 17:03:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9C9C41A743; Sun, 19 Aug 2018 17:03:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f178.google.com with SMTP id s12-v6so9825103ljj.0; Sun, 19 Aug 2018 10:03:23 -0700 (PDT) X-Gm-Message-State: AOUpUlGhS4rjXuPzyIOqD35JiBxoEsb7QJXL/n1TDFI/Z/4i2ALVVqEc J9mTCTi2+oolAUswGmTxV53jyqdPNID5K35Q5Po= X-Google-Smtp-Source: AA+uWPwtgBbAP6llxWR9iR+lmCq10igwkL+xy9Vzywq5Uc+M/QVkduOki6TvSXVbkduHIvyHG2cufQT5h52bgIpk8BE= X-Received: by 2002:a2e:2b0e:: with SMTP id q14-v6mr28277326lje.147.1534698202168; Sun, 19 Aug 2018 10:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:03:01 -0700 (PDT) In-Reply-To: <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Kyle Evans Date: Sun, 19 Aug 2018 12:03:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: John Baldwin Cc: Warner Losh , FreeBSD Current , tychon@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:03:24 -0000 On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrote: >>> >>>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: >>>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wrote: >>>>> >>>>>> With today's change to LUA as the loader, I seem to have an issue with >>>>>> bhyhve: >>>>>> >>>>>> Consoles: userboot >>>>>> >>>>>> FreeBSD/amd64 User boot, Revision 1.1 >>>>>> (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) >>>>>> Startup error in /boot/lua/loader.lua: >>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory. >>>>>> >>>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 >>>>>> syms=[0x8+0x14cf28+0x8+0x163e57] >>>>>> Hit [Enter] to boot immediately, or any other key for command prompt. >>>>>> Booting [/boot/kernel/kernel]... >>>>>> >>>>>> These VM's have been running for MONTHS. >>>>>> >>>>>> Ideas? >>>>>> >>>>> >>>>> There's no boot/lua/loader.lua. >>>>> >>>>> You can either fix that, or you can recompile with >>>>> LOADER_DEFAULT_INTERP=4th for the moment. >>>> actually on the host there is: >>>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ >>>> total 131 >>>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua >>>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua >>>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua >>>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua >>>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua >>>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua >>>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua >>>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua >>>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua >>>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua >>>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua >>>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua >>>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua >>>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua >>>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua >>>> borg.lerctr.org /home/ler $ >>>> >>>> This is when booting the vm, and it's not on the vm's disk. >>>> >>>> So the bhyveload behavior *CHANGED*. >>>> >>>> POLA? >>>> >>> >>> Unlikely, but a couple of questions. Have you always used the LUA loader, >>> or is this a change with the recent default switch? >>> >>> And to be clear, you expect the host's file to be used for this, not the VM >>> filesystem? >>> >> >> (CC'ing jhb@ and tychon@, who might have better insight) >> >> If we can swing it, I think the best model here should have always >> been that userboot uses the host's scripts but the guest's >> loader.conf. The current model doesn't tolerate any mismatch between >> host and guest and looks unsustainable. > > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk image. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. > Right, but userboot is clearly a special monkey... it seems that it would have made a lot more sense to emulate an actual BIOS boot (or something) and boot a real boot1/loader from a guest, but instead we end up with this host dependency of userboot that's invoking scripts from the guest -- which may or may not match. I think including both loaders in userboot is probably a no-start based on the current interface. From owner-freebsd-current@freebsd.org Sun Aug 19 17:04: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 198B8107051F for ; Sun, 19 Aug 2018 17:04:30 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [IPv6:2001:470:1f0f:3ad:bb:dcff:fe50:d900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEF3A80231; Sun, 19 Aug 2018 17:04:29 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VNd0O+XLYOYLIaMHMeRIbl8gMxik2+ZsLSvSDaKPbxE=; b=vGtg6a68h7qeB+79bfbHK1AACM 7LZegTx5ZH6DfRqDvIXc05U9oQYh2tpqrz8fe0vIOjmCDr7OIgj9/kny4+zPazzdrv26vOqW2p3I8 W//EV7oKOvGdHMgoh9rQ0tjTjzm7+N/fgwRZnV+xG8lEHt7LFmKwT/m2O8pDXjnMY17Y=; Received: from [2600:1700:210:b18f:1840:43d6:4770:35e0] (port=63577 helo=ler-imac.local) by thebighonker.lerctr.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1frR7s-000GDA-Qk; Sun, 19 Aug 2018 12:04:28 -0500 Date: Sun, 19 Aug 2018 12:04:28 -0500 From: Larry Rosenman To: John Baldwin Cc: Kyle Evans , Warner Losh , FreeBSD Current , tychon@freebsd.org Subject: Re: LUA loader: bhyve now doesn't? Message-ID: <20180819170428.w676mh2og6syzbcx@ler-imac.local> Mail-Followup-To: John Baldwin , Kyle Evans , Warner Losh , FreeBSD Current , tychon@freebsd.org References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lno55kmn4s22nhzj" Content-Disposition: inline In-Reply-To: <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:04:30 -0000 --lno55kmn4s22nhzj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 19, 2018 at 05:58:43PM +0100, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: > > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman wrot= e: > >> > >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > >>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman wr= ote: > >>>> > >>>>> With today's change to LUA as the loader, I seem to have an issue w= ith > >>>>> bhyhve: > >>>>> > >>>>> Consoles: userboot > >>>>> > >>>>> FreeBSD/amd64 User boot, Revision 1.1 > >>>>> (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > >>>>> Startup error in /boot/lua/loader.lua: > >>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or direct= ory. > >>>>> > >>>>> /boot/kernel/kernel text=3D0x1063d88 data=3D0x12e930+0x283970 > >>>>> syms=3D[0x8+0x14cf28+0x8+0x163e57] > >>>>> Hit [Enter] to boot immediately, or any other key for command promp= t. > >>>>> Booting [/boot/kernel/kernel]... > >>>>> > >>>>> These VM's have been running for MONTHS. > >>>>> > >>>>> Ideas? > >>>>> > >>>> > >>>> There's no boot/lua/loader.lua. > >>>> > >>>> You can either fix that, or you can recompile with > >>>> LOADER_DEFAULT_INTERP=3D4th for the moment. > >>> actually on the host there is: > >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ > >>> total 131 > >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > >>> borg.lerctr.org /home/ler $ > >>> > >>> This is when booting the vm, and it's not on the vm's disk. > >>> > >>> So the bhyveload behavior *CHANGED*. > >>> > >>> POLA? > >>> > >> > >> Unlikely, but a couple of questions. Have you always used the LUA load= er, > >> or is this a change with the recent default switch? > >> > >> And to be clear, you expect the host's file to be used for this, not t= he VM > >> filesystem? > >> > >=20 > > (CC'ing jhb@ and tychon@, who might have better insight) > >=20 > > If we can swing it, I think the best model here should have always > > been that userboot uses the host's scripts but the guest's > > loader.conf. The current model doesn't tolerate any mismatch between > > host and guest and looks unsustainable. >=20 > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk i= mage. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. That won't help (looking at /boot/loader.rc) as my lua updated system still has: borg.lerctr.org /home/ler $ more /boot/loader.rc \ Loader.rc \ $FreeBSD: head/stand/i386/loader/loader.rc 331326 2018-03-21 22:01:51Z ke= vans $ \ \ Includes additional commands include /boot/loader.4th include /boot/efi.4th try-include /boot/loader.rc.local \ Reads and processes loader.conf variables initialize maybe-efi-resizecons \ Tests for password -- executes autoboot first if a password was defined check-password \ Load in the boot menu include /boot/beastie.4th \ Start the boot menu beastie-start borg.lerctr.org /home/ler $ so it still looks forth'ish, but it's using lua. >=20 > --=20 > John Baldwin > _______________________________________________ > 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 Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106 --lno55kmn4s22nhzj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQHABAABCgCqFiEEHjgknedhWzvJgwVzaXyZsatIp30FAlt5oxwsFIAAAAAAFQAO cGthLWFkZHJlc3NAZ251cGcub3JnbGVyQGxlcmN0ci5vcmdfFIAAAAAALgAoaXNz dWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDFFMzgy NDlERTc2MTVCM0JDOTgzMDU3MzY5N0M5OUIxQUI0OEE3N0QACgkQaXyZsatIp30I awgAhycKYirfaHzbsOwalvzZPTRVk6jdsq1aafN3laAaq4LlPXHmn8i7IO97n5UN 6pXUB/PdDWpH5LtVbkW4fvleJSPqjA243slOXUamAsjPoqAVUVCPXZNX9m6JIpxV +TLmTEXVccPuC6590g8S8haaHae3+8us0kx7E9ofUvf2HlbGV0evcKeoBdDSGIQP pT8FQYFubv6d8N9ArfxFN1VPif74sa0fr4A8K+HHkVwreA4vOoowZfBPIo84St+L op3wpcPsFTk8CWm2ADoAYVzo+p+J4OskxUe41KsLTpIjYojLtN8p1Mh0l0ipAXBY 1EC0kxXvhfarDutkf1soHJkKNg== =IFY2 -----END PGP SIGNATURE----- --lno55kmn4s22nhzj-- From owner-freebsd-current@freebsd.org Sun Aug 19 17:04:37 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 EE0C8107053A for ; Sun, 19 Aug 2018 17:04:36 +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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79A5C80240 for ; Sun, 19 Aug 2018 17:04:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id v14-v6so1672447iob.4 for ; Sun, 19 Aug 2018 10:04:36 -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=1UqnvYw7nzCtgPi8eZ/SSDNxNdNUx6cgOBRyr96XjfI=; b=RbSrUK4oHiwt2Eid7RJF3RMuh9utRN5qeh4jagVS00UVJTcwJlg0HGs+0KdaCeYhUz EvufuGb2SgzfLVTewNMoObK5Z3eSBtBk3hzBHK7z4E1nqo8Zn4iGtLeT46akefU1mAJN eEKU35lMbjK/6eu//gNgN60qVOV3MCJByb3qA9VK3Pq76n8W5LRPMY7+A0Ebhiru9L0f enR1WfcslMuvCZYTIwRNKN/IoLE6TH/TKjdcb3LLQMOi03WaJR9GXZ/r1DhQJnTpaE8e SuGlDPwnpX0mLx8rvTVZqaoFi2W0s7Wta6SbMVHJlKpnNjSLGBKD+Zh3J47dmM8qST3o FzDA== 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=1UqnvYw7nzCtgPi8eZ/SSDNxNdNUx6cgOBRyr96XjfI=; b=WquKWHL3D6bp1HFj+boWGAZKYlJFL8f4IdxJxDeVe0IxCYotEwD2CVWL08p3dzlmpx hl1g0I/E6hxwoVJNmBKokIkJOdbKjYhEFy6J2GAkSMBBFoK/y8IJMzadd87E2/lL041h o/NWSCQMMmUeAzFtl8D5rKFsf9F9MHMQ356oILVJfyhgNzLBQMbKqI7dijAeoE++nPy7 W34WdOJTwWuwT8cS/4sgr+K+DPx8/KMGCnyfWcTUdRf5fp/SQLuBLgC2CgFwdNCwTxBD 57SCTeXGhf5PBmAqqBjMcM9JDzCcTOs8IaGToA3w92zTFq+UQX8RbR8S81+JbsskW/8d KrHw== X-Gm-Message-State: AOUpUlHY9Dh93Edtmw2aqWkYQuOOE4Hd9V7DtnYcS0VRMPr6uRB3Y15S wnCoy5/rBi7HKT6CJIHKbJHGu/7kIT+r9ACfE5Fhyg== X-Google-Smtp-Source: AA+uWPwGAtCbeQ7JuV3Pbmr7dpcJGleUn1cvPoXayW1vkqsyj7d/kTawvKATgVExA7SOBXr0H8qoPxVf9FNgQquDIU8= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr35123370ioa.299.1534698275724; Sun, 19 Aug 2018 10:04:35 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:04:35 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Warner Losh Date: Sun, 19 Aug 2018 11:04:35 -0600 X-Google-Sender-Auth: w-lO1tmkDjc5p2-mm5YPnHzZeSc Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: John Baldwin Cc: Kyle Evans , FreeBSD Current , Tycho Nightingale Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:04:37 -0000 On Sun, Aug 19, 2018 at 10:58 AM, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: > > On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman > wrote: > >> > >>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > >>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman > wrote: > >>>> > >>>>> With today's change to LUA as the loader, I seem to have an issue > with > >>>>> bhyhve: > >>>>> > >>>>> Consoles: userboot > >>>>> > >>>>> FreeBSD/amd64 User boot, Revision 1.1 > >>>>> (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > >>>>> Startup error in /boot/lua/loader.lua: > >>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or > directory. > >>>>> > >>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > >>>>> syms=[0x8+0x14cf28+0x8+0x163e57] > >>>>> Hit [Enter] to boot immediately, or any other key for command prompt. > >>>>> Booting [/boot/kernel/kernel]... > >>>>> > >>>>> These VM's have been running for MONTHS. > >>>>> > >>>>> Ideas? > >>>>> > >>>> > >>>> There's no boot/lua/loader.lua. > >>>> > >>>> You can either fix that, or you can recompile with > >>>> LOADER_DEFAULT_INTERP=4th for the moment. > >>> actually on the host there is: > >>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ > >>> total 131 > >>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > >>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > >>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > >>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > >>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > >>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > >>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > >>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > >>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > >>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > >>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > >>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > >>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > >>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > >>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > >>> borg.lerctr.org /home/ler $ > >>> > >>> This is when booting the vm, and it's not on the vm's disk. > >>> > >>> So the bhyveload behavior *CHANGED*. > >>> > >>> POLA? > >>> > >> > >> Unlikely, but a couple of questions. Have you always used the LUA > loader, > >> or is this a change with the recent default switch? > >> > >> And to be clear, you expect the host's file to be used for this, not > the VM > >> filesystem? > >> > > > > (CC'ing jhb@ and tychon@, who might have better insight) > > > > If we can swing it, I think the best model here should have always > > been that userboot uses the host's scripts but the guest's > > loader.conf. The current model doesn't tolerate any mismatch between > > host and guest and looks unsustainable. > > Err, normally guests read things out of the a guest disk image (think most > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk > image. > Now, userboot isn't memory limited like the BIOS boot, so if it's > possible to have userboot just include both lua and forth perhaps with > some auto-detection based on what is in /boot/loader.rc to determine > which interpreter to use, that is really the best path forward. > You can't have both interpreters in the same image. You can't easily determine what the language to use for the interpreter. You can only determine if lua is present or not. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 17:06: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 CDA4A1070812 for ; Sun, 19 Aug 2018 17:06:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AABE8051D for ; Sun, 19 Aug 2018 17:06:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id m4-v6so10768430iop.3 for ; Sun, 19 Aug 2018 10:06:14 -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; bh=hiZjT2wIoMFF9/p3zkrEiis85s2rHCKMfjrRXYO00dE=; b=qx9QK4yOFX/OtrrCQTSaw7gpW4ISxecIKErAkSg77DmbUIJWP+1fR1BgVb7uqL6rAA EP/18xSL6XKKsEo8QJSME48/58uHdS97VjsxA1J+Xb56+6oW2Wbg272mS6hgJd6q8DFg ojnsrfRSsY2uuqzyABwPjpVrS6mh21Num3Wx5es9Nb/jBx4SCGIIhfCLxhkixsUVzGh7 jB0M9RDYp5bIfjDeos60BU0k7PjLyiiM6Z1/WcYvsnAKJ0/rxOe4zVA1+j1UyC//cz8e ulXAvirA1iollwRRQrDreEZJgkudr7yQTiBl+CH3K2GbtUfaf9LSfXxMIpAc84iK7Umk fuXw== 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=hiZjT2wIoMFF9/p3zkrEiis85s2rHCKMfjrRXYO00dE=; b=LWD+4XGyumMU5YNg7Baq98LguuwKippdPtEcirNKVsua06ja+FiZnnFU9qnT2Z9VHl 2hfQ/igXfxjNC1m38IKO3JNA6uOhW9Z6O0ycsoYKuRw7uN/tzS+4i7aRjCCXYd5VIvOX CNb31DWuMLQQVVBfQoDjjVIUekKY7qNUDdWMD+d8Zr6Ht6dzfT7xDocSge3aJwxPOl99 0H7nl8tJgDPomqc12oRV17v1oQUM4j8sCPPQ9W1N2EsagfbGTJv3sglfAjrNTnfN2kpQ cWC3YJ03VllYC1+SI8BFGbnKeioJsWvGflIx4LYZVi8vnd9AlysmhS7wHMvJs5WxbWBt KARA== X-Gm-Message-State: AOUpUlEQX0BZpbWsIFrWyj/VXhTVY3FHPR4lHhD+fTpZ+7WO8e0PNl23 RLzoKkHQ7oK4Vja7BIOcqe7T2SopXlpTgDwGcTu8WQ== X-Google-Smtp-Source: AA+uWPybLvYd24SAiz7vXibtFr2D8JhmcqlkztWxBi3nxqWvjLX0FmDdY/NQy3h1O2ixhC+XBbtKD07BFSVD1PEUsf0= X-Received: by 2002:a6b:7117:: with SMTP id q23-v6mr19958839iog.37.1534698373895; Sun, 19 Aug 2018 10:06:13 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:06:13 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180819170428.w676mh2og6syzbcx@ler-imac.local> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> <20180819170428.w676mh2og6syzbcx@ler-imac.local> From: Warner Losh Date: Sun, 19 Aug 2018 11:06:13 -0600 X-Google-Sender-Auth: 8WFDkcGvVi-b-MGfZUaOp9HaUNg Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: John Baldwin , Kyle Evans , Warner Losh , FreeBSD Current , Tycho Nightingale Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:06:15 -0000 On Sun, Aug 19, 2018 at 11:04 AM, Larry Rosenman wrote: > so it still looks forth'ish, but it's using lua. > It will always look forthish becuase it's unused in loader_lua. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 17:10: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 DE5CE1070D7F for ; Sun, 19 Aug 2018 17:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F29809D8 for ; Sun, 19 Aug 2018 17:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id 139-v6so17668363itf.0 for ; Sun, 19 Aug 2018 10:10:28 -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=EKHf4Pf06C4+5PaarOgohgt5uMoKFhzTVQID7mPReIQ=; b=MkQfxQXe0J0C/Cz8xQJaIRXl6oI6FslUSFAjhGMJxT6v9CpZCnM3Zu2Bnp47LH9gq9 zDa1XP7CyR9euJB3Evp4LVqIVEU+Sh3tCX1/60heCVGf4v1MWH+FTEdfb/BiS/w7fk0Z xHoOL2KhKsnzJ+9ucAhvg3ffJGm9yrVNLpacsMWZceiglCALxA9FzAWaV2sDVsMl/g7D hdkeokUUd4t2n/B9YebmmxZ6Q51LTHnVUKn9YRyFdDEPl8rTIi2DRRkyz+aK10XMX0LJ ujQ+PW17Jr6ZjnIKMWFzJQxRPxC8uUhwxLZldZ890VOYSFyTiWJWIBlGaj1IM1yr7uJu xUXg== 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=EKHf4Pf06C4+5PaarOgohgt5uMoKFhzTVQID7mPReIQ=; b=rWigg9xGM1ZnT+YZ6jbs61+dFo0/9l0h1qJvWBTrYNmxVLLLsqubUrChAFwDPFFuf0 cA+NvnTo0UgOnd5NLs43tBrxjOCszt4lbZSHwlhAqAbxKuPjhXndwQCRh4IxAjgU6cbw iwLXUSBRy/tkFEpTRpuTFxb6wMs49P/VVcvFCUhf2eELvTcbZyT59/BmCinUX0he3979 DtLHDTLghUf94DQhk2Sn+iSNw/A5CMMMKPSCSvmbYZJu3o+gl0Ng8kzadihZbV0ULe89 tNQLz9HFPkpPyY93CId0zHIS3EXsFZ225YjGBW8KBqCXcZZDsPXeszN7ZT1GUocwFz/X 8RXA== X-Gm-Message-State: AOUpUlEqIiTOfbqujWK4u9acdOlp15D8Cwrt9xs1qSs00sHyJzdgGZVY kWvYoDI9wfhEkfskh8wPvqt/s5yFtx7oMn5J1BgKYw== X-Google-Smtp-Source: AA+uWPwovvzI9R1/6EJWCIVqceuKtuqXfDCv6YPojA8wLF1b4K/jd14aDLLQ+lFrEExGdTL+BOmvyXbsZdmTfXAtC0o= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr9964845ite.39.1534698627437; Sun, 19 Aug 2018 10:10:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:10:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Warner Losh Date: Sun, 19 Aug 2018 11:10:26 -0600 X-Google-Sender-Auth: RtvncAG4LzOpo0jisx4S27AqHkA Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Kyle Evans Cc: John Baldwin , FreeBSD Current , Tycho Nightingale Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:10:29 -0000 On Sun, Aug 19, 2018 at 11:03 AM, Kyle Evans wrote: > On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote: > > On 8/19/18 5:28 PM, Kyle Evans wrote: > >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: > >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman > wrote: > >>> > >>>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote: > >>>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman > wrote: > >>>>> > >>>>>> With today's change to LUA as the loader, I seem to have an issue > with > >>>>>> bhyhve: > >>>>>> > >>>>>> Consoles: userboot > >>>>>> > >>>>>> FreeBSD/amd64 User boot, Revision 1.1 > >>>>>> (Thu Nov 16 15:04:02 CST 2017 root@borg.lerctr.org) > >>>>>> Startup error in /boot/lua/loader.lua: > >>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or > directory. > >>>>>> > >>>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970 > >>>>>> syms=[0x8+0x14cf28+0x8+0x163e57] > >>>>>> Hit [Enter] to boot immediately, or any other key for command > prompt. > >>>>>> Booting [/boot/kernel/kernel]... > >>>>>> > >>>>>> These VM's have been running for MONTHS. > >>>>>> > >>>>>> Ideas? > >>>>>> > >>>>> > >>>>> There's no boot/lua/loader.lua. > >>>>> > >>>>> You can either fix that, or you can recompile with > >>>>> LOADER_DEFAULT_INTERP=4th for the moment. > >>>> actually on the host there is: > >>>> borg.lerctr.org /home/ler $ ls -l /boot/lua/ > >>>> total 131 > >>>> -r--r--r-- 1 root wheel 3895 Aug 19 09:46 cli.lua > >>>> -r--r--r-- 1 root wheel 3204 Aug 19 09:46 color.lua > >>>> -r--r--r-- 1 root wheel 14024 Aug 19 09:46 config.lua > >>>> -r--r--r-- 1 root wheel 10302 Aug 19 09:46 core.lua > >>>> -r--r--r-- 1 root wheel 9986 Aug 19 09:46 drawer.lua > >>>> -r--r--r-- 1 root wheel 3324 Aug 19 09:46 hook.lua > >>>> -r--r--r-- 1 root wheel 2543 Aug 19 09:46 loader.lua > >>>> -r--r--r-- 1 root wheel 2431 Aug 19 09:46 logo-beastie.lua > >>>> -r--r--r-- 1 root wheel 2203 Aug 19 09:46 logo-beastiebw.lua > >>>> -r--r--r-- 1 root wheel 1958 Aug 19 09:46 logo-fbsdbw.lua > >>>> -r--r--r-- 1 root wheel 2399 Aug 19 09:46 logo-orb.lua > >>>> -r--r--r-- 1 root wheel 2119 Aug 19 09:46 logo-orbbw.lua > >>>> -r--r--r-- 1 root wheel 12010 Aug 19 09:46 menu.lua > >>>> -r--r--r-- 1 root wheel 3941 Aug 19 09:46 password.lua > >>>> -r--r--r-- 1 root wheel 2381 Aug 19 09:46 screen.lua > >>>> borg.lerctr.org /home/ler $ > >>>> > >>>> This is when booting the vm, and it's not on the vm's disk. > >>>> > >>>> So the bhyveload behavior *CHANGED*. > >>>> > >>>> POLA? > >>>> > >>> > >>> Unlikely, but a couple of questions. Have you always used the LUA > loader, > >>> or is this a change with the recent default switch? > >>> > >>> And to be clear, you expect the host's file to be used for this, not > the VM > >>> filesystem? > >>> > >> > >> (CC'ing jhb@ and tychon@, who might have better insight) > >> > >> If we can swing it, I think the best model here should have always > >> been that userboot uses the host's scripts but the guest's > >> loader.conf. The current model doesn't tolerate any mismatch between > >> host and guest and looks unsustainable. > > > > Err, normally guests read things out of the a guest disk image (think > most > > VMs like VirtualBox, etc.). userboot.so is looking in the guest's disk > image. > > Now, userboot isn't memory limited like the BIOS boot, so if it's > > possible to have userboot just include both lua and forth perhaps with > > some auto-detection based on what is in /boot/loader.rc to determine > > which interpreter to use, that is really the best path forward. > > > > Right, but userboot is clearly a special monkey... it seems that it > would have made a lot more sense to emulate an actual BIOS boot (or > something) and boot a real boot1/loader from a guest, but instead we > end up with this host dependency of userboot that's invoking scripts > from the guest -- which may or may not match. > It's special so that bhyve doesn't have to emulate more.... > I think including both loaders in userboot is probably a no-start > based on the current interface. > Yea, it would be a challenge... Sadly, we have POLA violations either way we jump here. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 17:33:51 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 DBC7D10717FC for ; Sun, 19 Aug 2018 17:33:51 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36BBD818BA for ; Sun, 19 Aug 2018 17:33:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([85.180.124.215]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LtZcC-1g1F9m13K8-010qJ5 for ; Sun, 19 Aug 2018 19:33:42 +0200 Date: Sun, 19 Aug 2018 19:33:06 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: LUA loader: non UEFI boxes have weird ssh output Message-ID: <20180819193333.3e7b5785@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:dn5eweWQr/m1uI6W23ZkFigQkAyq1EJbxvlfVmcfG+y6NV7ozEc lUYukQH0Q8xtFvzAZtgfQDx27gERloM19ESc20N0uhjiAO2L9VbTQ7sfWYIHF9J1ER8bgnc dUE2KpC5h/G7W2o5hztBghggOhXWxhkalyiC9qGaaN1MBMIBld8SHv+o3Tly/LMBvH97dL7 OamYrvNzbz1njB2edKU1w== X-UI-Out-Filterresults: notjunk:1;V01:K0:qOqqIzZbJxs=:4W8ro7V6cXVcGjiad/b6OL LNYmy6L3Fr6CpS85ZK7eRdfTH3kY31x8WBod4Bips4gXfOhwgR3Uun9pt39rexllo0cAbBiUy 1FqGmFAHuT1BSo1aV227bzvmR8Jf1Taob1BcNaOFxgvYUFhsSJpZYaPE5oYNn9aBwXZuZjo4c C4lJZnriCYgx/XHohUMQFSJODS6wYMjMYERZ9cps4GDtBDTBi5/W3tqpNjf6naLGJQAGYr/Fi KMC6Ps37OOYsFAb68zIGjzfKwGa66iZCt5/6827kFU3439ymW/GEQmwVbD4gCccMHFUuR9rR+ slhmSVTYgeNJCdX8oxOuNmWfkZVbf1E+2YGRC1H7gPhtZgzXu/a41gdsUjPMM8dhuqUOevwEa NKAqlmomu8ptFqdySC8cmSXmQaNeJCkWWxszG3jt/WISataZ8yzFLbdZYioWn223+QrzSy6Zu G2aXpPI3Wfn8hEbuliP9kItqIRofgU6TjsoUKCkPwegSFefU210FCqoYE6c08QlXhYi2OWzyM uHajHu33wkMYmAtJ6H9lYBqyFcU3CwlYUmMCPHNwOISivm3utI6a+adWGs8YHjWZ6WmR4S4HI bSNUzZSph7WWcYjSWM5zEYYMEz6Ey9CwK4vdAzNxqp4AfoeqxSJVob4fg6IdGEWm7915nwA+4 NzkwJGaiq7QnPihf9v9Eko1xT1E1OfpPejXoMrY8vREFyxCYt27Iq94SOITa5xNuihJCWPBUA zP4M+x66vZseOAKZdahTyMslG3gN4HF/s4lGWnyV6aN/VsL5laNjZWM3wqw/9oV3jdCVoiMrg ZBB33q7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:33:52 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkp1c3Qg dXBkYXRlZCBzb21lIGJveGVzIHRvIDEyLUNVUlJFTlQgcjMzODA1NyBhbmQgSSBmYWNlIGEgdmVy eSBzdHJhbmdlIGJlaGF2aW91cjoNCg0Kb24gbm9uLVVFRkkgYm9vdGluZyBib3hlcyAob2xkZXIg RnVqaXRzdSBhbmQgRGVsbCBzZXJ2ZXJzIGZyb20gMjAwOC8yMDA5LCBQQ2VuZ2luZSBBUFUNCjJD NCksIGxvZ2dpbmcgaW4gdmlhIHNzaCByZXZlYWxzIGJyb2tlbiBvdXRwdXQ6IGV2ZW4gdG9wIGRv ZXMgc2hvdyBub3RoaW5nLCB0aGUgYm94IGlzDQpzdHVjay4gQ2FsbGluZyB2aSgxKSBvbiBzb21l IGZpbGVzIGRvZXMgYWxvcyBmcmVlemUgdGhlIHRlcm1pbmFsIC0gbm8gcmVzcG9uc2UsIG5vdGhp bmcuDQpPbiB0aGUgUENlbmdpbmUsIGFsc28gYXBwbGljYXRpb25zIGxpa2UgQXN0ZXJpc2sgZG8g bm90IHdvcmsgYW55bW9yZSAtIG5vdCBvdXRwdXQgb24gdGhlDQpjb25zb2xlLiBUaGUgcHJvZ3Jh bSBpcyBydW5uaW5nLCBidXQgc3RvcHBlZCBzZXJ2aWNpbmcuIE9ubHkgdGhlIHNlcmlhbCBjb25z b2xlIHRvIHNvbWUNCm9mIHRoZSAic3NkLWJyYWluLWRlYWQiIHN5c3RlbXMgd29yaywgc3NoZCBp cyBkZWFkLiBUaGlzIGlzbid0IHRoZSBjYXNlIG9uIFVFRkkgYm94ZXMNCndpdGggdGhlIHZlcnkg c2FtZSByZXZpc2lvbiAocjMzODA1NykuDQoNCklzIHRoaXMgYSBjb2luY2lkZW5jZSBvciBpcyB0 aGlzL2NvdWxkIHRoaXMgcmVsYXRlZCB0byB0aGUgc3dpdGNoIHRvIExVQSBsb2FkZXI/DQoNCi0g LS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9kZXIgw5xi ZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8cg0KV2VyYmV6d2Vja2Ugb2RlciBmw7xyIGRpZSBN YXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAowqcgMjggQWJzLiA0IEJEU0cpLg0KLS0tLS1C RUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaUxVRUFSTUtBQjBXSVFRWlZaTXpBdHdDMlQvODZU clM1MjhmeUZoWWxBVUNXM21wN2dBS0NSRFM1MjhmeUZoWQ0KbERKYUFmOUc4aDd1RWdIa0FkV0pO amIrUVNVcE51MVRxRjRncXZKMDFtVmgwZVFxdFllOCtZVFBBNUkvOExNYg0KeDdTN0hYdlJ4QlN3 aUw2WUIydE5FQmd6V1RyeUFnQ1E3RnpwRTF4K2dLSW1WVXErOEJZdmdDVEpFbkFZcVlsQw0KNzlJ YjJNUnpSVTZxeHlDaThxaUN4b1BJLzdoQ1lvTzVsYmphVm1zN3lscEpHdE1qK3dTSQ0KPVlJQkQN Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Sun Aug 19 17:47:51 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 854C71071FCF for ; Sun, 19 Aug 2018 17:47:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3853F8250B for ; Sun, 19 Aug 2018 17:47:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id CBDAD1AB61 for ; Sun, 19 Aug 2018 17:47:50 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f181.google.com with SMTP id p6-v6so9862675ljc.5 for ; Sun, 19 Aug 2018 10:47:50 -0700 (PDT) X-Gm-Message-State: AOUpUlHknAAM7r4DW3uDvJbC7jdDJwkCBeQluMBWX156srKOvqbH2Qms h0tLEKtPe1hi5T5gsy8vo4izC8lBNtXdF+p03YY= X-Google-Smtp-Source: AA+uWPxphLUn/5+d/YVWf2fLDTpFj/brtX6deUohXzPs0eLhGxQfS3cnlgeYoQolAiOVpAv5/kDtFIpbcSDC6rP3tcw= X-Received: by 2002:a2e:4055:: with SMTP id n82-v6mr26320107lja.99.1534700869378; Sun, 19 Aug 2018 10:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:47:28 -0700 (PDT) In-Reply-To: <20180819193333.3e7b5785@thor.intern.walstatt.dynvpn.de> References: <20180819193333.3e7b5785@thor.intern.walstatt.dynvpn.de> From: Kyle Evans Date: Sun, 19 Aug 2018 12:47:28 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA loader: non UEFI boxes have weird ssh output To: "O. Hartmann" Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 17:47:51 -0000 On Sun, Aug 19, 2018 at 12:33 PM, O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Just updated some boxes to 12-CURRENT r338057 and I face a very strange behaviour: > > on non-UEFI booting boxes (older Fujitsu and Dell servers from 2008/2009, PCengine APU > 2C4), logging in via ssh reveals broken output: even top does show nothing, the box is > stuck. Calling vi(1) on some files does alos freeze the terminal - no response, nothing. > On the PCengine, also applications like Asterisk do not work anymore - not output on the > console. The program is running, but stopped servicing. Only the serial console to some > of the "ssd-brain-dead" systems work, sshd is dead. This isn't the case on UEFI boxes > with the very same revision (r338057). > > Is this a coincidence or is this/could this related to the switch to LUA loader? > This is probably a coincidence. Most of the important stuff that happens in loader is independent of the interpreter that's built into it, the exceptions being that the interpreter is tasked with reading loader.conf(5) and sets up some ACPI stuff on x86 BIOS boots. From owner-freebsd-current@freebsd.org Sun Aug 19 18:25:38 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 03B4E1073791 for ; Sun, 19 Aug 2018 18:25:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7799283FE2 for ; Sun, 19 Aug 2018 18:25:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id j81-v6so17696977ite.0 for ; Sun, 19 Aug 2018 11:25:37 -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=P9LwWQn3pb7LTXTVqbyEUdTXdNuX65iODI3hNkT2fBo=; b=C4N/+JLUv0eY7BypWQ6ocoOzll3GRlx/St5M8AojMlA/9zuIKiWzlYAYIhIHTPN3oB IRee+zBBR5974WX9gJvvMMWmR+9ErDWNGZOydyLd0qJVKsOvc8PTf559vDUfBsjpvTWe nt/YWyqfMNxqiklT/PVbii81OBueoxHn6hkrGHJSybWmhwlU6AXY77IMO0vDY7UOYvzG TXkVm8MRJSnRvAIKgIlY+qMrQOfLcq1GSg2uGfcNt0qmJl5nO5vQb78DPhNGh5sJlh80 5o8cnrmoJpDiBgjVTDPmGRtYshma262+92RczLCCt1OH+KJOrfMsi13HU0ovnK67Bq2u BrXw== 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=P9LwWQn3pb7LTXTVqbyEUdTXdNuX65iODI3hNkT2fBo=; b=XwWDFX1RQN99ye3KA519QHnD9HL9r45pxEj+AFDGrwRdjSPfPklPgG3krl8kzfnBGl n1eRqGfcOU/Iw2vxN4am6S1BYGEuzy8ravbqi6vByXFaBdpAEWtQeVmwdxIADANuiz4n JBpJwyplgwUxcAQ85bNuW27+Lkaex1v+05+C1jsU50il5BXVIL/0u9Ye7ZTExH+RwsZL auVBL5Ev5MTmq88YJH4mMNkOHbWcD12L0PzaFMGHqinwyJVVJq8/cYyYr7hWNW9z2QtW s0lPjxm0l0ybr5eJt2tnx7JnpLB4D3wyh9Qvfn2ggL2TpdAUTqo/MLU1TDDLwWg5dI8q 4enQ== X-Gm-Message-State: AOUpUlGjMUUgghVk/njqxI/01aMkHdRGoFnq1GL/nnGF8DZ+knc82JJC YrWBpqXmnUd2Xg/OEEYh7Sh+SKMsc5rpW/u6eeIpHA== X-Google-Smtp-Source: AA+uWPz54dfOX56HbyB+C2wYUm7grjM4Ui4W0N73AJue2yJjubfEoYRApIXojB1kOjS/aiVTTqqqj6sOWDQizhRr5sU= X-Received: by 2002:a02:4306:: with SMTP id s6-v6mr5382789jab.140.1534703136770; Sun, 19 Aug 2018 11:25:36 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 11:25:36 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Warner Losh Date: Sun, 19 Aug 2018 12:25:36 -0600 X-Google-Sender-Auth: Fcr4S3zP-O0wsUUYti73ebg_Enc Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Kyle Evans Cc: John Baldwin , FreeBSD Current , Tycho Nightingale Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 18:25:38 -0000 On Sun, Aug 19, 2018 at 11:10 AM, Warner Losh wrote: > > I think including both loaders in userboot is probably a no-start >> based on the current interface. >> > > Yea, it would be a challenge... Sadly, we have POLA violations either way > we jump here. > Just to summarize the IRC conversation: I just committed r338064 which reverts userboot.so to 4th always. This is a quick band-aide until a longer term solution happens. There was the suggestion of adding a hack so that if there was no lua, we could use the 4th interpreter instead. There's a number of ways to do this, but they all involve a bit of work. There was the suggestion of installing a userboot_{lua,4th}.so and hard linking (but this provides a built-in way to get the right userboot_*.so to use with a bhyveload -l lessening the burden). The notion of putting some smarts into bhyveload to cope, since it's also updated at the same time that userboot.so is, typically. There may be another notion as well. Working through the details and will present a plan when I have it. Warner From owner-freebsd-current@freebsd.org Sun Aug 19 22:45: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 EF524107A91D for ; Sun, 19 Aug 2018 22:45:15 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 6BBD28E240 for ; Sun, 19 Aug 2018 22:45:15 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 54621 invoked by uid 89); 19 Aug 2018 22:45:13 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 19 Aug 2018 22:45:13 -0000 Date: Mon, 20 Aug 2018 00:45:12 +0200 From: Michael Gmelin To: Konstantin Belousov Cc: Michael Gmelin , John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180820004512.5171fa75@bsd64.grem.de> In-Reply-To: <20180819161642.GP2340@kib.kiev.ua> References: <20180606010625.62632920@bsd64.grem.de> <20180815005106.69402d23@bsd64.grem.de> <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd10.3) X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= 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.27 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, 19 Aug 2018 22:45:16 -0000 On Sun, 19 Aug 2018 19:16:42 +0300 Konstantin Belousov wrote: > On Sun, Aug 19, 2018 at 04:59:51PM +0200, Michael Gmelin wrote: > > > > > > On Fri, 17 Aug 2018 10:02:08 +0100 > > John Baldwin wrote: > > > > > On 8/17/18 9:54 AM, Michael Gmelin wrote: > > > > > > > > > > > >> On 17. Aug 2018, at 08:17, John Baldwin > > > >> wrote: > > > >>> On 8/16/18 1:58 PM, Michael Gmelin wrote: > > > >>> > > > >>> > > > >>>> On 15. Aug 2018, at 15:55, Konstantin Belousov > > > >>>> > wrote: > > > >>>>> On Wed, Aug 15, 2018 at 03:52:37PM +0200, Michael Gmelin > > > >>>>> wrote: > > > >>>>> > > > >>>>> > > > >>>>>>> On 15. Aug 2018, at 15:04, Konstantin Belousov > > > >>>>>>> > wrote: > > > >>>>>>> > > > >>>>>>> On Wed, Aug 15, 2018 at 12:51:06AM +0200, Michael Gmelin > > > >>>>>>> wrote: Reviving this old thread, since I just updated to > > > >>>>>>> r337818 and a similar problem is happening again. Since > > > >>>>>>> the fix in r334799 (review > > > >>>>>>> https://reviews.freebsd.org/D15675) (mp_)machdep.c have > > > >>>>>>> been touched, so maybe this is related > > > >>>>>>> (https://svnweb.freebsd.org/base?view=revision&revision=334799). > > > >>>>>>> > > > >>>>>>> Please see the screenshot of the panic below: > > > >>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658 > > > >>>>>>> > > > >>>>>>> This is me not digging any deeper, hoping that this is > > > >>>>>>> something obvious. Please let me know if you need more > > > >>>>>>> input. > > > >>>>>> > > > >>>>>> I do not see how recent mp_machdep.c changes could affect > > > >>>>>> this. Can you try newest kernel but old loader ? > > > >>>>> > > > >>>>> I will try (but that will take a while). Oh, also, it still > > > >>>>> boots in save mode/with smp disabled. > > > >>>> > > > >>>> Right, this is because the access to that address through > > > >>>> DMAP is only needed when configuring AP startup resources. > > > >>>> > > > >>>> Also, I think it is safe to suggest that the bisect is > > > >>>> needed. > > > >>> > > > >>> Using an older loader didn???t help, but I identified the > > > >>> problem: > > > >>> > > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334952 > > > >>> > > > >>> modified the code you introduced in > > > >>> > > > >>> https://svnweb.freebsd.org/base?view=revision&revision=334799 > > > >>> > > > >>> By correcting units to pages it also broke booting the > > > >>> Chromebook as a side effect - so the previous fix just worked > > > >>> due to a bug it seems. > > > >>> > > > >>> Is there an easy way to output the content of physmap at that > > > >>> point (debug.late_console=0 doesn???t work) - like an existing > > > >>> buffer I could use, or would this be more elaborate (I did > > > >>> something complicated last time but didn???t save it, so any > > > >>> simple solution would be preferred). > > > >> > > > >> How about reverting the commit for now so you get a working > > > >> console and print out the physmap array values along with > > > >> Maxmem later in the boot (or just use kgdb to examine them > > > >> once the system is running)? > > > > > > > > This is before the system has a working console (part of calling > > > > getmem...), disabling late console makes it hang, physmap > > > > changes afterwards, so running kgdb later doesn???t help. Last > > > > time I kept a copy of physmap and logged it later to know the > > > > original content. I can do that again, I just thought maybe > > > > there is a simple mechanism I???m not aware of that would save > > > > me some time. > > > > > > I thought we only modified phys_avail[], but saving a copy of > > > physmap[] and dumping it from kgdb is probably the simplest thing > > > to do. > > > > > > > Okay, so I had some time to investigate a bit more: > > > > Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), > > physmap looks like this: > > > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x30000 0x30 > > 2 0x40000 0x40 > > 3 0x9e400 0x9e > > 4 0x100000 0x100 > > 5 0xf00000 0xf00 > > 6 0x1000000 0x1000 > > 7 0x7bf7a000 0x7bf7a > > 8 0x100000000 0x100000 > > 9 0x100600000 0x100600 > > 10 0x0 0x0 > > Maxmem: 0x100600000 0x100600 > > > > Without using atop (the "buggy" version that actually boots without > > crashing), the loop in mp_bootaddress looks like this: > > > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > > 8 0x100000000 0x100600000 0x100600 0x100600 > > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > > 4 0x100000 0xf00000 0xf00 0x100600 > > 2 0x40000 0x9e400 0x9e 0x100600 > > > > And physmap looks like this afterwards: > > > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x30000 0x30 > > 2 0x43000 0x43 <-- here > > 3 0x9e400 0x9e > > 4 0x100000 0x100 > > 5 0xf00000 0xf00 > > 6 0x1000000 0x1000 > > 7 0x7bf7a000 0x7bf7a > > 8 0x100000000 0x100000 > > 9 0x100600000 0x100600 > > 10 0x0 0x0 > > mptramp_pagetables is 0x40000 > > > > So a three page gap was made at 0x40000 (atop(idx 2) is now 0x43 > > instead of 0x40) > > > > In the current version (using atop), the loop in mp_bootaddress > > looks like this: > > > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > > 8 0x100000000 0x100600000 0x100600 0x100600 > > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > > > > And physmap looks like this afterwards: > > > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x30000 0x30 > > 2 0x40000 0x40 > > 3 0x9e400 0x9e > > 4 0x100000 0x100 > > 5 0xf00000 0xf00 > > 6 0x1003000 0x1003 <-- here > > 7 0x7bf7a000 0x7bf7a > > 8 0x100000000 0x100000 > > 9 0x100600000 0x100600 > > 10 0x0 0x0 > > mptramp_pagetables: 0x1000000 > > > > So a three page gap was made at 0x1000000 (atop(idx 6) is now > > 0x1003 instead of 0x1000) > > > > When changing the code to require a page below 0x1000: > > > > if (physmap[i] >= GiB(4) || physmap[i + 1] - > > round_page(physmap[i]) < PAGE_SIZE * 3 || > > atop(physmap[i + 1]) > Maxmem > > || atop(physmap[i + 1]) > 0x1000) // <--- this > > continue; > > > > The system boots just fine. It uses page 0x100 > > for the bootstrap code in this case: > > > > i, physmap[i], physmap[i + 1], atop(physmap[i + 1]), Maxmem > > 8 0x100000000 0x100600000 0x100600 0x100600 > > 6 0x1000000 0x7bf7a000 0x7bf7a 0x100600 > > 4 0x100000 0xf00000 0xf00 0x100600 > > > > Physmap looks like this: > > physmap_idx: 8 > > i mem atop > > 0 0x0 0x0 > > 1 0x30000 0x30 > > 2 0x40000 0x40 > > 3 0x9e400 0x9e > > 4 0x103000 0x103 <-- here > > 5 0xf00000 0xf00 > > 6 0x1000000 0x1000 > > 7 0x7bf7a000 0x7bf7a > > 8 0x100000000 0x100000 > > 9 0x100600000 0x100600 > > 10 0x0 0x0 > > mptramp_pagetables: 0x100000 > > > > So for some reason it's crashing when using pages 0x1000 - 0x1003 > > for the bootstrap code, while it boots okay when using 0x40 - 0x43 > > and 0x100 - 0x103. > > > > Any ideas? > I in fact misread the page fault state decoding in your photo. > It is curiously protection violation on write, instead of non-present > page access. > > Compile ddb into your kernel, then on fault do > db> x/x dmaplimit > db> x/x dmaplimit+4 > db> show pte This was a bit more complicated, as the keyboard doesn't work in ddb at that point (neither internal, nor USB). I ended up hacking sys/ddb/db_script.c to execute these commands on kdb.enter.trap (tunable support for scripting would be cool). Anyway, dmaplimit is 40000000, dmaplimit+4 is 1 See here for a screenshot (also including the output of "show pte 0xfffff80001000000"): https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png > > Also show me the verbose dmesg lines with CPU features identification. > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU) Origin="GenuineIntel" Id=0x40651 Family=0x6 Model=0x45 Stepping=1 Features=0xbfebfbff Features2=0x4ddaebbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x2603 XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4301258752 (4102 MB) avail memory = 1907445760 (1819 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0 irqs 0-39 on motherboard Launching APs: 1 Timecounter "TSC" frequency 1396795536 Hz quality 1000 -m -- Michael Gmelin From owner-freebsd-current@freebsd.org Sun Aug 19 23:31: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 09475107BAA9 for ; Sun, 19 Aug 2018 23:31:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670088.outbound.protection.outlook.com [40.107.67.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C1B98FBA4 for ; Sun, 19 Aug 2018 23:31:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM (52.132.44.160) by YTOPR0101MB1371.CANPRD01.PROD.OUTLOOK.COM (52.132.46.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.21; Sun, 19 Aug 2018 23:31:41 +0000 Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127]) by YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127%3]) with mapi id 15.20.1059.023; Sun, 19 Aug 2018 23:31:41 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" Subject: panic excl->shared for an AF_LOCAL socket Thread-Topic: panic excl->shared for an AF_LOCAL socket Thread-Index: AQHUOBRM4+qxEJX+P0ebgxfNDW4pUA== Date: Sun, 19 Aug 2018 23:31:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1371; 6:aQwb2yXYDrLNSOe9lTh0Psl1DRnzzlzlsf6Rq3sQ2mB0Tzih/AzBbbQYfAg3QFhfEmnfh4vfGvrV/s58Cm3YaNG/vJHr6f0uNvwOxOQbz3hUxXvY0TM0oXLfNcr1gGSvrAyHstp1fa77C++NEPCcixjNNHtyOh5F2UyOZFa9yYjdW6GRTP9DoQIice1TQUz03tYW2LVpnJxfrDxxPd7XVlOHbH/hhOFNCctuNAeIYeOYOsy3YyU2JnETrEEb4Z3zaTEztaJSyBrAc9DLtrxafnZxzVz21nU+yVCiypqj4NL0IDu6FoWwTEB+Jrpx3E5WohSDvwGjQCdeTMMKPXwSj7GFlbUjkUdHy409Psq78iD9cBYbYXNMlMxpB67W/Tax8h3RRv3RBp8s/rp6TVokzdeehO6QdPeR4bDYptGZiB0/ZnfPuD65Kl/xGkf9z/vc8Be3HhRLYn8RvbhtlgAgFg==; 5:wpYTnN0Ogqj3StpYYtXRI4qyKoHZiJu4tnmXiN6UBNwDnBt44KBOE6vG4HMUN9V7QcWcOJBrDrsaOQ+FNHL71WtnqfjOkRmDXIF8xDKIo1ZTu7HbI/3sDAafqPi3cNL2ag9GjYambmMaB0R7kDlP50EXOv1MALLwpuwcvtSunj4=; 7:4D1u09IvixwzSNkO0OEWAe5f0ctKmBE0gn8ECQvIV8AfbFvZOrx2HMXTnbIVjs7Gk8dBxCoL5zZ2G0mc2MvUfeC/CjcYO6yemN6v+FKSXRSnJQ602dos7/J+SUPadBmXH3ZXlSYhbXASaj0grHAQPiQ3WvqzK+otq2e3AGxwbrP/LcOBQpfpQCKLdwi15MuJTbwpRGnFj9Kc8QAsy4RLEBqt4RBU4i5pdbV32b4L8r+gBrNylcowkVZaepOe1Ds6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b2241172-ac7c-4d02-67fd-08d6062bead3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1371; x-ms-traffictypediagnostic: YTOPR0101MB1371: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699016); SRVR:YTOPR0101MB1371; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1371; x-forefront-prvs: 07697999E6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(136003)(376002)(366004)(199004)(189003)(305945005)(33656002)(68736007)(476003)(7696005)(786003)(99286004)(316002)(74316002)(2501003)(5250100002)(26005)(486006)(186003)(106356001)(2351001)(2900100001)(14454004)(6506007)(81166006)(81156014)(8676002)(478600001)(97736004)(256004)(102836004)(8936002)(105586002)(14444005)(25786009)(74482002)(53936002)(55016002)(5640700003)(5660300001)(6436002)(9686003)(86362001)(6916009)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1371; H:YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: thwtXDOVPltFb4iiZGwELTwLvYklVL9wr2ZgchZb72j+pSwaLOBVyY/8bs3Bk3SM1YBKC3q3UEORFxpfIlRmMaflWfasXTNT54L/ebKoNfFwo9u4odAiTX9CGScYS7PJ0DxeA8nzoLTUS+WglZpW7iwOCDD0y9DOkA1qnekLmCfRE11K8zdAK4IzFbCu46psXQsLUdyYDi0mZEd0slsxgDTvo2AsNH8psLBPtUeqKdWgPN810RafEXAyl36W3SKyKUltTm2GYLDHoMMLOQW7iNkEy8eVzXcGk5Hc736wzocsWksho2ISzvR9vC3TBNOiEjetgcK8rQVjKRCkboca4X20O6JFnZbNRHy4S8QZyA0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: b2241172-ac7c-4d02-67fd-08d6062bead3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2018 23:31:41.1897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1371 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 23:31:43 -0000 Hi, PR#230752 shows a witness panic() for "excl->shared" on a vnode lock. In this case, the kernel RPC code is trying to do a soconnect() on an AF_LO= CAL socket. The code is unp_connectat() looks like is does a straightforward namei()/lookup(), so I am surprised to see this. Does anyone know if AF_LOCAL (unix domain) sockets are somehow handled differently for namei()/lookup() which might cause this? I've requested more info from the reporter w.r.t. when this happens. (I'd guess when the nfsuserd is terminating or has terminated or ???) Thanks for any help with this, rick From owner-freebsd-current@freebsd.org Sun Aug 19 23:52: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 51C54107C23C for ; Sun, 19 Aug 2018 23:52:47 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF70670634 for ; Sun, 19 Aug 2018 23:52:46 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id B58581D0F7 for ; Sun, 19 Aug 2018 23:52:46 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f169.google.com with SMTP id y3-v6so6781957ioc.5 for ; Sun, 19 Aug 2018 16:52:46 -0700 (PDT) X-Gm-Message-State: AOUpUlFVIIeUq5gyOq/kmNqhtRfaYBjeBoA34LES0XFuybEchfTcKHyz cGSiI8l6QaFD0Tw+shNa2s7MWapJ9LCEAqrezjo= X-Google-Smtp-Source: AA+uWPxLBIRwpGJxo/VTe7FH2K3BPsoV1jN1thRyK0LN5lqP6kPCyNrb4Xn5cqDJOVIhiDmTKof8NB98ptYfOj1TWiw= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr11823843iog.132.1534722766050; Sun, 19 Aug 2018 16:52:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Sun, 19 Aug 2018 16:52:34 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: panic excl->shared for an AF_LOCAL socket To: Rick Macklem Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 19 Aug 2018 23:52:47 -0000 On Sun, Aug 19, 2018 at 4:32 PM Rick Macklem wrote: > Hi, > > PR#230752 shows a witness panic() for "excl->shared" on a vnode lock. > In this case, the kernel RPC code is trying to do a soconnect() on an > AF_LOCAL > socket. The code is unp_connectat() looks like is does a straightforward > namei()/lookup(), so I am surprised to see this. > > Does anyone know if AF_LOCAL (unix domain) sockets are somehow handled > differently for namei()/lookup() which might cause this? > > I've requested more info from the reporter w.r.t. when this happens. > (I'd guess when the nfsuserd is terminating or has terminated or ???) > > Thanks for any help with this, rick > I don't know what's special in this case, but I did revamp the locking there several months back so I'll take a look next weekend. -M From owner-freebsd-current@freebsd.org Mon Aug 20 00:33: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 55B67107D395 for ; Mon, 20 Aug 2018 00:33:16 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBBB07193C for ; Mon, 20 Aug 2018 00:33:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x234.google.com with SMTP id 72-v6so18368703itw.3 for ; Sun, 19 Aug 2018 17:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wLk/7qoaf8yYkq3z2N0fZPnlpOxHsmfklWGxH+eHTJo=; b=NUjx885O1D4ND2NscnFyD3afGOAkOjEFFM7SEbMxqKaoQHGPXXhFAf8+sYowi+kJYJ UT7vorrOQlY37Hb+1IfDqcVyoP2oPXf6JT0rGiIPJKTj/lb4Hdkw4P8XcklkK/llirRQ 3B3P7sSXVa1hTE8DFPSC6ef4S3U4OFXZ3v0NDgBEQOle40nH96muaM8EG9zP9JBTo6IN nc8CoiP1o1004YOywuCWBmKX95B7og4fdrGn5AxrqTnn8OSJ0lDyO5dSwGv/xtEt685q GuQgXeX2Sa0VEAJsrbs3K8stF57jUlwaq5/QRtaJJRHrJ7LnpKwSRIfYit6IjAdc1TOF 9+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wLk/7qoaf8yYkq3z2N0fZPnlpOxHsmfklWGxH+eHTJo=; b=LvqF7Ho1Oq//bcMu5/KWBI7VjU489jiat7sKrzsGyOpOYyou6OcEDa5K/9vESL1Xjz opR6dJ02K/Ep96haWDHVjvt6YrmpGp6zlXszYAGr3YTgHoeKPk4iuFthKXGE8AuiA+8P boOGGD9IYwnvPIHisUf9eWNos7vX+ElipWPL+7MLjyu4ZB1CTeP69BYgcvjI7lTZDbbx urt4CI/fWmD1ZqWwM0ta01DlHMwQU708ve6/PGNRhgaZ52KEy0w7LIAXbyjMOOJ/oyU6 mpWrudDrmikdNSDr0Sfb+NctG+PdSLq4y9X/1ndwWHGDtlldNpuOJxqhpsG5GzgYVZjI +z6Q== X-Gm-Message-State: AOUpUlFz/Cho71X2v1iNfiOt16T0e+ti2tbLyk8NPCTOAWUUP64nyMxw IhTazB32cal2Rtm15Gm/oEBgY2SocIUsOIQLxS8UQTcj X-Google-Smtp-Source: AA+uWPxlSpV9YOyVmzMapCfav3jB4aVNxRoUqxIPUwWw/aKOaG85FnDGJHZBoDGXwgWI8/ydfDup4tJ3xBtGFJbrHcw= X-Received: by 2002:a02:1643:: with SMTP id a64-v6mr12212138jaa.133.1534725195153; Sun, 19 Aug 2018 17:33:15 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Mon, 20 Aug 2018 08:33:04 +0800 Message-ID: Subject: What's this gregset_t gregs thing To: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 00:33:16 -0000 Linux has gregset_t gregs; https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h Defined above, I also see it in the RISC-V glibc stuff as well. FreeBSD doesn't seem to have this field defined, I see FreeBSD uses /usr/include/x86/ucontext.h but there's no gregs; If I wanted to return mcontext.gregs How could I implement that on FreeBSD? Best, Owen From owner-freebsd-current@freebsd.org Mon Aug 20 03:02: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 502A31081043 for ; Mon, 20 Aug 2018 03:02:01 +0000 (UTC) (envelope-from gurenchan@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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDBDB76F11 for ; Mon, 20 Aug 2018 03:02:00 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22c.google.com with SMTP id h23-v6so18709266ita.5 for ; Sun, 19 Aug 2018 20:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d0sT4LeuZ1jtjoGwkVQ3RmSuSHaAYLGweA2reD9DO2I=; b=LWEC7poN/OxpZGv3IYCGtlMGuWu6D12ykmcL4g5q5kLJV4uJA5u4Ld3zSDbrTlmmoc 5cPvTxI6hyNdCWQ7jHfmZM+A49ZzNL1njGEKKkugHMMyikXTNViOcD4YqPRwBQJaYQZM zFmugRTa/CJnqYWOoYBmEElcOxGxYxPMAQ2i/hXA9YLu1Sq/aI2TyXeT/6ualRX2HY+1 3I+fl8F/Yd3NsxmGdAyL3zit0zhr5N3CyMveqSniQZLWki+wAxVfT8YbQYP45dJdipqD ynXY4MxDL+sA2UT2pVECVOEYpzbDaxEYMuQOOZ4ierb7eb+iFWGOiLWQneL++TwkBnle hZtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d0sT4LeuZ1jtjoGwkVQ3RmSuSHaAYLGweA2reD9DO2I=; b=uVmNUFZHw0QDWvNciSuJ7Nq/Yw+XrcyQGKYETqTW7dmg63TfB6gh0WdUMSaV2xtMDR AZ6LBYSdnfPs0sFgJoaA8+ikmobSO4xZo2itDjOkx2PMJBLML1BcPvklKdACX/3GR/Q4 zoDq8XRaGiFRQo2wQXSDV32NLHSHBIG0FzqzXCF6UBfgSPI8svm7TZFlfp2k+v8/Gw6y HM/6WGUCBtNeZIfWEdc0MLrNlZHywjIzvPaMYh8c3eXV76wx262tnToX0+qNXh199gBG /yWcqMHrVTzwhvkrkftIcbueZuheddQ+JOkwg2UH1VelmjWBSzSBbNsoqu9Em1y/eo0W 99kw== X-Gm-Message-State: AOUpUlEfASWwiQvXAyyA+2SObpPfsKogFwOC7UR0DYHDpNcwBN2TMO2S dkzVgliwiYxHnAnTu5XigH/AEQidSjUFfJNGNausYf2T X-Google-Smtp-Source: AA+uWPzOndc0m6Aiwt2sGguLDRK1njgiL/WFU0T/Qh0BqFKP8X1Ysm8HTzUsXda7PW5wfVqOuVnx00G060u/NM0bRUg= X-Received: by 2002:a24:7f94:: with SMTP id r142-v6mr33394243itc.137.1534734119924; Sun, 19 Aug 2018 20:01:59 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Mon, 20 Aug 2018 11:01:48 +0800 Message-ID: Subject: building LLVM threads gets killed To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 03:02:01 -0000 I am running current compiling LLVM60 and when it comes to linking basically all the processes on my computer gets killed; Chrome, Firefox and some of the LLVM threads as well I am using ninja which is a little better but gmake or make are a lot worse. uname -a: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336196: Wed Jul 11 21:52:50 CST 2018 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 me@blubee:~ % uname -K 1200072 me@blubee:~ % uname -U 1200072 building with -j1 still crashes and burns. Basically everything on my machine gets killed. This machine has sysctl hw.physmem hw.physmem: 34246332416 last pid: 20965; load averages: 0.64, 5.79, 7.73 up 12+01:35:46 11:00:36 76 processes: 1 running, 75 sleeping CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% idle Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other 630M Compressed, 2G Uncompressed, 2.74:1 Ratio Swap: 2G Total, 1G Used, 739M Free, 63% Inuse llvm/build % ninja -j8 [2408/2473] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes -Iinclude -I../include -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -fno-exceptions -fno-rtti -MD -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c ../lib/Passes/PassBuilder.cpp c++: error: unable to execute command: Killed c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.cpp c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.sh c++: note: diagnostic msg: ******************** --------------- llvm/build % ninja -j8 [54/59] Linking CXX executable bin/opt FAILED: bin/opt : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,--export-dynamic -Wl,-z,origin tools/opt/CMakeFiles/opt.dir/AnalysisWrappers.cpp.o tools/opt/CMakeFiles/opt.dir/BreakpointPrinter.cpp.o tools/opt/CMakeFiles/opt.dir/Debugify.cpp.o tools/opt/CMakeFiles/opt.dir/GraphPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/NewPMDriver.cpp.o tools/opt/CMakeFiles/opt.dir/PassPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/PrintSCC.cpp.o tools/opt/CMakeFiles/opt.dir/opt.cpp.o -o bin/opt -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmParser.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcDesc.a lib/libLLVMSparcDisassembler.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZDisassembler.a lib/libLLVMSystemZInfo.a lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmParser.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Desc.a lib/libLLVMX86Disassembler.a lib/libLLVMX86Info.a lib/libLLVMX86Utils.a lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreDisassembler.a lib/libLLVMXCoreInfo.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMAnalysis.a lib/libLLVMBitWriter.a lib/libLLVMCodeGen.a lib/libLLVMCore.a lib/libLLVMCoroutines.a lib/libLLVMipo.a lib/libLLVMIRReader.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMMC.a lib/libLLVMObjCARCOpts.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTarget.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a lib/libLLVMPasses.a -lpthread lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a lib/libLLVMGlobalISel.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libLLVMCodeGen.a lib/libLLVMipo.a lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMLinker.a lib/libLLVMInstrumentation.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a lib/libLLVMVectorize.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMObject.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMBitReader.a lib/libLLVMProfileData.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lrt -lexecinfo -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) [55/59] Linking CXX executable bin/llvm-lto2 FAILED: bin/llvm-lto2 : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,-z,origin tools/llvm-lto2/CMakeFiles/llvm-lto2.dir/llvm-lto2.cpp.o -o bin/llvm-lto2 -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmParser.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcDesc.a lib/libLLVMSparcDisassembler.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZDisassembler.a lib/libLLVMSystemZInfo.a lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmParser.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Desc.a lib/libLLVMX86Disassembler.a lib/libLLVMX86Info.a lib/libLLVMX86Utils.a lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreDisassembler.a lib/libLLVMXCoreInfo.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMLinker.a lib/libLLVMLTO.a lib/libLLVMMC.a lib/libLLVMObject.a lib/libLLVMSupport.a lib/libLLVMTarget.a -lpthread lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a lib/libLLVMGlobalISel.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libLLVMObjCARCOpts.a lib/libLLVMPasses.a lib/libLLVMCodeGen.a lib/libLLVMTarget.a lib/libLLVMipo.a lib/libLLVMLinker.a lib/libLLVMScalarOpts.a lib/libLLVMVectorize.a lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMProfileData.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lrt -lexecinfo -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) [56/59] Linking CXX executable bin/llvm-opt-fuzzer FAILED: bin/llvm-opt-fuzzer : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,-z,origin tools/llvm-opt-fuzzer/CMakeFiles/llvm-opt-fuzzer.dir/DummyOptFuzzer.cpp.o tools/llvm-opt-fuzzer/CMakeFiles/llvm-opt-fuzzer.dir/llvm-opt-fuzzer.cpp.o -o bin/llvm-opt-fuzzer -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmParser.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcDesc.a lib/libLLVMSparcDisassembler.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZDisassembler.a lib/libLLVMSystemZInfo.a lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmParser.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Desc.a lib/libLLVMX86Disassembler.a lib/libLLVMX86Info.a lib/libLLVMX86Utils.a lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreDisassembler.a lib/libLLVMXCoreInfo.a lib/libLLVMAnalysis.a lib/libLLVMBitReader.a lib/libLLVMBitWriter.a lib/libLLVMCodeGen.a lib/libLLVMCore.a lib/libLLVMCoroutines.a lib/libLLVMipo.a lib/libLLVMIRReader.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMFuzzMutate.a lib/libLLVMMC.a lib/libLLVMObjCARCOpts.a lib/libLLVMScalarOpts.a lib/libLLVMSupport.a lib/libLLVMTarget.a lib/libLLVMTransformUtils.a lib/libLLVMVectorize.a lib/libLLVMPasses.a -lpthread lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a lib/libLLVMGlobalISel.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libLLVMCodeGen.a lib/libLLVMipo.a lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMLinker.a lib/libLLVMInstrumentation.a lib/libLLVMScalarOpts.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTarget.a lib/libLLVMVectorize.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMProfileData.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lrt -lexecinfo -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) [57/59] Linking CXX executable bin/llvm-lto FAILED: bin/llvm-lto : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,-z,origin tools/llvm-lto/CMakeFiles/llvm-lto.dir/llvm-lto.cpp.o -o bin/llvm-lto -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmParser.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcDesc.a lib/libLLVMSparcDisassembler.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZDisassembler.a lib/libLLVMSystemZInfo.a lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmParser.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Desc.a lib/libLLVMX86Disassembler.a lib/libLLVMX86Info.a lib/libLLVMX86Utils.a lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreDisassembler.a lib/libLLVMXCoreInfo.a lib/libLLVMBitReader.a lib/libLLVMBitWriter.a lib/libLLVMCore.a lib/libLLVMIRReader.a lib/libLLVMLTO.a lib/libLLVMMC.a lib/libLLVMObject.a lib/libLLVMSupport.a lib/libLLVMTarget.a -lpthread lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a lib/libLLVMGlobalISel.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libLLVMObjCARCOpts.a lib/libLLVMPasses.a lib/libLLVMCodeGen.a lib/libLLVMTarget.a lib/libLLVMipo.a lib/libLLVMBitWriter.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMScalarOpts.a lib/libLLVMVectorize.a lib/libLLVMLinker.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMProfileData.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lrt -lexecinfo -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) [58/59] Linking CXX shared library lib/libLTO.so.7svn FAILED: lib/libLTO.so.7svn : && /usr/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-z,origin -Wl,--version-script,/home/blubee/dev/fortran/FLANG/flang-llvm/build/tools/lto/LTO.exports -shared -Wl,-soname,libLTO.so.7 -o lib/libLTO.so.7svn tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMMSP430Desc.a lib/libLLVMMSP430Info.a lib/libLLVMNVPTXCodeGen.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMNVPTXDesc.a lib/libLLVMNVPTXInfo.a lib/libLLVMPowerPCCodeGen.a lib/libLLVMPowerPCAsmParser.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMPowerPCDesc.a lib/libLLVMPowerPCDisassembler.a lib/libLLVMPowerPCInfo.a lib/libLLVMSparcCodeGen.a lib/libLLVMSparcAsmParser.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSparcDesc.a lib/libLLVMSparcDisassembler.a lib/libLLVMSparcInfo.a lib/libLLVMSystemZCodeGen.a lib/libLLVMSystemZAsmParser.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZDisassembler.a lib/libLLVMSystemZInfo.a lib/libLLVMX86CodeGen.a lib/libLLVMX86AsmParser.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Desc.a lib/libLLVMX86Disassembler.a lib/libLLVMX86Info.a lib/libLLVMX86Utils.a lib/libLLVMXCoreCodeGen.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMXCoreDesc.a lib/libLLVMXCoreDisassembler.a lib/libLLVMXCoreInfo.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMLTO.a lib/libLLVMMC.a lib/libLLVMMCDisassembler.a lib/libLLVMSupport.a lib/libLLVMTarget.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMDesc.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMSP430AsmPrinter.a lib/libLLVMNVPTXAsmPrinter.a lib/libLLVMPowerPCAsmPrinter.a lib/libLLVMSparcAsmPrinter.a lib/libLLVMSystemZDesc.a lib/libLLVMSystemZAsmPrinter.a lib/libLLVMSystemZInfo.a lib/libLLVMGlobalISel.a lib/libLLVMX86AsmPrinter.a lib/libLLVMX86Utils.a lib/libLLVMXCoreAsmPrinter.a lib/libLLVMAsmPrinter.a lib/libLLVMSelectionDAG.a lib/libLLVMMCDisassembler.a lib/libLLVMObjCARCOpts.a lib/libLLVMPasses.a lib/libLLVMCodeGen.a lib/libLLVMTarget.a lib/libLLVMipo.a lib/libLLVMScalarOpts.a lib/libLLVMVectorize.a lib/libLLVMBitWriter.a lib/libLLVMLinker.a lib/libLLVMIRReader.a lib/libLLVMAsmParser.a lib/libLLVMAggressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMInstrumentation.a lib/libLLVMTransformUtils.a lib/libLLVMAnalysis.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMMCParser.a lib/libLLVMMC.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMDebugInfoMSF.a lib/libLLVMProfileData.a lib/libLLVMCore.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lrt -lexecinfo -ltinfo -lpthread -lm lib/libLLVMDemangle.a && : c++: error: unable to execute command: Killed c++: error: linker command failed due to signal (use -v to see invocation) From owner-freebsd-current@freebsd.org Mon Aug 20 03:34: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 23F0C1081B96 for ; Mon, 20 Aug 2018 03:34:47 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by mx1.freebsd.org (Postfix) with ESMTP id 4F11077F87 for ; Mon, 20 Aug 2018 03:34:45 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp118-210-140-229.bras1.adl6.internode.on.net (HELO leader.local) ([118.210.140.229]) by ipmail06.adl6.internode.on.net with ESMTP; 20 Aug 2018 13:04:37 +0930 Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. To: freebsd-current@freebsd.org References: <20180818223420.rjisst4vuxzxbcrl@kazhap> <0b28a679-b13c-149b-a7db-12c9f5f41100@ShaneWare.Biz> <2098a6d6-733f-14c4-b4c9-8bc6b3d2fddc@FreeBSD.org> From: Shane Ambler Message-ID: Date: Mon, 20 Aug 2018 13:04:34 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <2098a6d6-733f-14c4-b4c9-8bc6b3d2fddc@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 03:34:47 -0000 On 19/8/18 5:31 pm, Matthew Seaman wrote: > On 19/08/2018 01:55, Shane Ambler wrote: >>> I run 12-CURRENT on few machines, some more powerful that other (all >>> of them x86_64, march varies). > >> You can use freebsd-update by setting up your own update server >> https://www.freebsd.org/doc/en/articles/freebsd-update-server > > freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP > specified. While I haven't used it to make releases from current, I would be surprised if it doesn't work for current. The default config for release.sh is to checkout and build HEAD, so without setup, current would be used when building for the update server. I do expect an incremental numbering scheme would need to be used to differentiate each build, patch level builds should fit that. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Mon Aug 20 06:25:21 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 E3B2B1085AB4 for ; Mon, 20 Aug 2018 06:25:20 +0000 (UTC) (envelope-from mail@dbalan.in) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92B107D96C for ; Mon, 20 Aug 2018 06:25:20 +0000 (UTC) (envelope-from mail@dbalan.in) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4A82421841; Mon, 20 Aug 2018 02:25:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 20 Aug 2018 02:25:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dbalan.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=IHSaB7mMfU+q0KIJcTc+2GOuitABkSG9X9loYXKMfvk=; b=PDgThEYI AkObzegTj8QjorvhSGdyp6lZPLQoeT9fIdLCmVEpwwP9pZQYOxRjCP2yUzJr0dr7 CtW5aC34sSxm2ctpo4mqoYXVZ96GVoSlR75fDdlShKbvbX/RzP6zqim+mCgjzTTJ yUYIyCPvmqPBtZl9dx35XtCH7gBSjMGHvxdPPSo/HV8+PcoHIXA8AC8B3gnGW0sh 7TpL5Sjpfd2gFRUGamfH4ta0SRvThPFoKZ5FP7zG5LozbUlw7ByMexuEG7IPN25p MasmDQY+31m/pmvSFXrH3K0xcww/wexUi9/GVlpvjvCnvXhcRH9BttKZWHG0mvWl wIMWT+U8/iPzzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=IHSaB7mMfU+q0KIJcTc+2GOuitABk SG9X9loYXKMfvk=; b=s4Bn4Le3eiw91A3oxlxuASEUHAA/qYVSBPyokl0tUf0bI ZPc+ZkmqsU0k8boGQVfS+D4CW58AosZgXhB5tZQqrYad7cLCpi6G9/kmb/wEJDx4 e8kKaQ66STMktb64rZ3vrnQi5Lb1YS9ARtatm4oiSfeeVoz+H0FJPePAh7h+Hg3t n155/LfAkKzxk1AdlyannxSh5Wi7/iPlXJKAg4l+0bw6gm9yHB1y5RdobANFFt6x vAAwK+lN8eNPNVnu5RHrJ8aQrRSJs/D7mm6t+Hoi0PTACWD9DMQmd2tk60lbOj3P ncc88kR9aBEsaAe5IpSKmIoUkdyONp5cVDjGKWJyA== X-ME-Proxy: X-ME-Sender: Received: from localhost (p5090fab3.dip0.t-ipconnect.de [80.144.250.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D097E454E; Mon, 20 Aug 2018 02:25:13 -0400 (EDT) Date: Mon, 20 Aug 2018 08:25:11 +0200 From: Dhananjay Balan To: Cy Schubert Cc: freebsd-current@freebsd.org Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. Message-ID: <20180820062511.yaa2rimgmwpv3hxx@kazhap> References: <20180818223420.rjisst4vuxzxbcrl@kazhap> <201808182336.w7INaF5J088304@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808182336.w7INaF5J088304@slippy.cwsent.com> User-Agent: NeoMutt/20180512 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 06:25:21 -0000 On Sat, Aug 18, 2018 at 04:36:15PM -0700, Cy Schubert wrote: > You can use NFS or rsync. Make sure the src and obj path names are > exactly the same on all thes servers. I used to use NFS until a year or > two ago when I started using different patches on different machines. > On occasion I've used rsync followed by a NO_CLEAN, WORLDFAST, KERNFAST > build on the target machine or simply installkernel and installworld. > I had a quick try of this, with rsync. installkernel worked properly and I can boot, howver installworld fails with lot of $PROGRAM not found erroer for env, mktemp etc. Thanks for all the suggestions I will grok at the installworld a bit more, and will also give PkgBase a try. - Dhananjay Balan From owner-freebsd-current@freebsd.org Mon Aug 20 06:37: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 20DB51085E52 for ; Mon, 20 Aug 2018 06:37:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-2.consmr.mail.bf2.yahoo.com (sonic307-2.consmr.mail.bf2.yahoo.com [74.6.134.41]) (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 A4EC37DDC1 for ; Mon, 20 Aug 2018 06:37:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Daeo0DcVM1mLQO39Zll4MNywkv74cGaXgJxjUsxLDm05SyInFWR8_955MJcb74E jArYJvz5nvt396i.7uA_51tuXxV7LG1Iobnm5HtAWdNCWyLfahYr0B121zoP4YGJnQS09eK_O5ZZ umTfnEqPnRbT92KSpXAmlmr_dDGYDGrtN5LciQjrl5tIpenD8QPyqY.klGCvZwzAUgoSft.rmd9x DZqIprb4f6QBjSGZcdE1O7cCHuh0cfcxA22i8RFcGoGxwoWSwtsLbCzm1h3vp9qcV39tQDrC8Dx5 eNyaTGQZTSfjVFBqJFCavagw1aKStknBPGe7KpmpXD8272jZHxE_xeQ_jzJjJh2EQSEJxJvddX8H eKX.5DBSMkgltfwHOuhr8VRbdNd_KXdR.zS1az5WF_9C2ZKyqLS30V37lk6WnWqsJmmu4wy3KPJA 3YdwPPMYNjzu52z.flD_tndy5e2O7ikmQORcSa9leWoKcYh7T.apBGErgCzcJairLNk6EXx9Eq63 MzvrV8DLvRAVC0Yj0AC22iGUYy62XxyVPk7iX9KUkuJoNzyctoM1J71hDQR7qBeTDezqf31RNtzq hvWXrzg9OUYUNExdZ_GKW3apa0v9VQKmH9vyTNRtLi3fi4bszrPBIRZrVSgqvp9NTNq9I.IAsr_Z fEPDntFEmWEIQoy4lbHdeg3dnJ71T210RkRJ8GaNnbC9EOH4aYya3WoL7Fnax4eLGSvHXOVfNRPt Ya71qJssXl9HIw0YPHmdcb34oDqIruN91E2C3YHLzCEcAUOPG0XDJpP5SkYIqQdsgmld_iw5emhJ bwlMrIjvKDP6j9xLeT.xXAxinEsYgCKjf5ZF9ssPNo0k45XL.cv0pkweLL9nU05EQYdONUkx5vsE ABhSKZf8Q9R1B4bFyHUNsR9XwLXdEmlY18tcqVWU37TaQXVeNxdmW.7pBa0fOgsTsxcbxzpEawyR LSYlMSARO13RVO.9GmAxCus.FEfo9SC1Fnu4VsE3Dgzkpi1LyycNZ8QcLn_jPY25sv0o9fzPNEIB OBRh8zmsTAw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Mon, 20 Aug 2018 06:37:32 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp415.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0eb3d29fa6783bb2e3620bd6fec10b41; Mon, 20 Aug 2018 06:37:29 +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.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Date: Sun, 19 Aug 2018 23:37:27 -0700 References: To: gurenchan@gmail.com, FreeBSD Current In-Reply-To: Message-Id: <048B761D-E1A0-4EE3-AA55-E2FFBD19F9F6@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 06:37:40 -0000 [In part a resend from the right Email account. In part adding a note about another Mark Johnston patch for reporting information.] On 2018-Aug-19, at 11:25 PM, Mark Millard = wrote: > blubee blubeeme gurenchan at gmail.com wrote on > Mon Aug 20 03:02:01 UTC 2018 : >=20 >> I am running current compiling LLVM60 and when it comes to linking >> basically all the processes on my computer gets killed; Chrome, = Firefox and >> some of the LLVM threads as well >=20 >> . . . >=20 >> last pid: 20965; load averages: 0.64, 5.79, 7.73 >> up 12+01:35:46 11:00:36 >> 76 processes: 1 running, 75 sleeping >> CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% = idle >> Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free >> ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other >> 630M Compressed, 2G Uncompressed, 2.74:1 Ratio >> Swap: 2G Total, 1G Used, 739M Free, 63% Inuse >> . . . >=20 > The timing of that top output relative to the first or > any OOM kill of a process is not clear. After? Just > before? How long before? What it is like leading up > to the first kill is of interest. >=20 > Folks that deal with this are likely to want do know > if you got console messages ( or var/log/messages content) > such as: >=20 > pid 49735 (c++), uid 0, was killed: out of swap space >=20 > (Note: "out of swap space" can be a misnomer for having > low Free RAM for "too long" [vm.pageout_oom_seq based], > even with swap unused or little used.) >=20 > And: Were you also getting messages like: >=20 > swap_pager_getswapspace(4): failed >=20 > and/or: >=20 > swap_pager: out of swap space >=20 > (These indicate the "killed: out of swap space" is not > necessarily a misnomer relative to swap space, even if > low free RAM over a time drives the process kills.) >=20 > How about messages like: >=20 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: = 65536 >=20 > or any I/O error reports or retry reports? >=20 >=20 >=20 > Notes: >=20 > Mark Johnston published a patch used for some investigations of > the OOM killing: >=20 > https://people.freebsd.org/~markj/patches/slow_swap.diff >=20 > But this is tied to the I/O swap latencies involved and if they > are driving some time frames. It just adds more reporting to > the console ( and /var/log/messages ). It is not a fix. IT may > not be likely to report much for your context. >=20 >=20 > vm.pageout_oom_seq controls the "how long is low free RAM > tolerated" (my hprasing), though the units are not directly > time. In various arm contexts with small boards going from > the default of 12 to 120 allowed things to complete or get > much farther. So: >=20 > sysctl vm.pageout_oom_seq=3D120 >=20 > but 120 is not the limit: it is a C int parameter. >=20 > I'll note that "low free RAM" is as FreeBSD classifies it, > whatever the details are. >=20 >=20 >=20 > Most of the arm examples have been small memory contexts > and many of them likely avoid ZFS and use UFS instead. > ZFS and its ARC and such an additional complicated > context to the type of issue. There are lots of reports > around of the ARC growing too big. I do not know the > status of -r336196 relative to ZFS/ARC memory management > or if more recent versions have improvements. (I do not > use ZFS normally.) I've seen messages making suggestions > for controlling the growth but I'm no ZFS expert. >=20 >=20 > Just to give an idea what is sufficient to build > devel/llvm60: >=20 > I will note that on a Pine64+ 2GB (so 2 GiBytes of RAM > in a aarch64 context with 4 cores, 1 HW-thread per core) > running -r337400, and using UFS on a USB drive and a > swap partition that drive too, I have built devel/llvm60 > 2 times via poudriere-devel: just one builder > allowed but it being allowed to use all 4 cores in > parallel, about 14.5 hr each time. (Different USB media > each time.) This did require the: >=20 > sysctl vm.pageout_oom_seq=3D120 >=20 > Mark Johnston's slow_swap.diff patch code did not > report any I/O latency problems in the swap subsystem. >=20 > I've also built lang/gcc8 2 times, about 12.5 hrs > each time. >=20 > No ZFS, no ARC, no Chrome, no FireFox. Nothing else > major going on beyond the devel/llvm60 build (or, later, > the lang/gcc8 build) in each case. Mark Johnston in the investigation for the arm context also had us use the following patch: diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 264c98203c51..9c7ebcf451ec 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int = page_shortage, * start OOM. Initiate the selection and signaling of the * victim. */ + printf("v_free_count: %u, v_inactive_count: %u\n", + vmd->vmd_free_count, = vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt); vm_pageout_oom(VM_OOM_MEM); /* This patch is not about the I/O latencies but about the free RAM and inactive RAM at exactly the point of the OOM kill activity. =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 Aug 20 06:26: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 842651085AE8 for ; Mon, 20 Aug 2018 06:26:00 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 128327D9DF for ; Mon, 20 Aug 2018 06:25:59 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: GL263FEVM1kqKYtaZqt1Z2X2zGFVzp1S5oh6PvSZeVdRnI.Ss8Oz36Kw9iI6O5a XWmu2eGnHUuXHlmNxHt3.Beqea8lcP.qajW2ms9QRy6rFaMlp0YAdSiUEt0yGsUk3SFfJaR3wfFP 9SOtPRzpay6HHIn0zNAluzw9h5hOk5jgsRioRdE4sE.Gn26JXkd8PVcl3oU0oVVpEHlYvbvSzvha capZq1_RT7cLGAl1s.TQ95m_5bF3tBjiJyBg6gUgBSKOY9vUMxSWyyjcNREGpmidUU_RKuR6iqbR 1HgYQx.PrRoQA7MrHdmVD51Kmu2BCh_W3rL7._DdHnHb3HXNmvqgZnw0UjchCQIi2sINJZqT4TbM WIQIEzL4FVcdLv1ttWiwrfdQVj9k6fnJ4Mqw1TTvHPr30Qw8lr9z_sd5sn1luPt5nsG1oFzTJMEm BGOdc2C3AxpyMerri4RFRbLO2nf8B4xANsH5prrdEDrxp3NTqMeQT9HwO40p2ZjSN1N0EbFknDSd Zh_IWwy1Z8VyX7IrZ6TDif8mGu52dof_WW8ahSJ0_rzNR7veLJN7mA858do02.gSIskb8NotV6O. qJWTznOHLzN5ZCoES1W4OH8mI54ORExH.d61aXt8Xaj5brvn49SGIdusGdOvui1lBU6xxsxGCyLE ulVtsjDQEHl6UI752GaqhNFPoabeDyJlfozaHlAWacKao6zgA7k.bQrnGX7FDnBnpCQ5_y.kJQtO a05ne1uIKOnGDj7IkllnkIYYY_nEoXQ51dlaA.J50O4gWm1aj3aLTyBYasCbJkB4DHW4GjBlITMI 4WgPitOLB5CGVW2ViWyo_LaMh6RV7wBA1j_DO7ankgjbKG5hcJj_gw.8E.4qNy7kMolZSRLiTbBV wUmYsfHfVUzsU2VisJiNhrWQBDsexDbi2R7Y.5Zl0aP5edLssWtTQnbXRdcmeyot1WhtDlcfyAwN 6AxBgLZSAbnNOoaqWFVU0TI.lqRS6HvlfR5nYb4aopNokeNTWItcUVp6zcu.0THUgMtJIZkcrN34 pft3ITEPB Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Aug 2018 06:25:52 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 128dcba1945941093717531b25c769b3; Mon, 20 Aug 2018 06:25:51 +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.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Message-Id: Date: Sun, 19 Aug 2018 23:25:48 -0700 To: gurenchan@gmail.com, FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-Mailman-Approved-At: Mon, 20 Aug 2018 10:12:22 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 06:26:00 -0000 blubee blubeeme gurenchan at gmail.com wrote on Mon Aug 20 03:02:01 UTC 2018 : > I am running current compiling LLVM60 and when it comes to linking > basically all the processes on my computer gets killed; Chrome, Firefox and > some of the LLVM threads as well > . . . > last pid: 20965; load averages: 0.64, 5.79, 7.73 > up 12+01:35:46 11:00:36 > 76 processes: 1 running, 75 sleeping > CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% idle > Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free > ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other > 630M Compressed, 2G Uncompressed, 2.74:1 Ratio > Swap: 2G Total, 1G Used, 739M Free, 63% Inuse > . . . The timing of that top output relative to the first or any OOM kill of a process is not clear. After? Just before? How long before? What it is like leading up to the first kill is of interest. Folks that deal with this are likely to want do know if you got console messages ( or var/log/messages content) such as: pid 49735 (c++), uid 0, was killed: out of swap space (Note: "out of swap space" can be a misnomer for having low Free RAM for "too long" [vm.pageout_oom_seq based], even with swap unused or little used.) And: Were you also getting messages like: swap_pager_getswapspace(4): failed and/or: swap_pager: out of swap space (These indicate the "killed: out of swap space" is not necessarily a misnomer relative to swap space, even if low free RAM over a time drives the process kills.) How about messages like: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 or any I/O error reports or retry reports? Notes: Mark Johnston published a patch used for some investigations of the OOM killing: https://people.freebsd.org/~markj/patches/slow_swap.diff But this is tied to the I/O swap latencies involved and if they are driving some time frames. It just adds more reporting to the console ( and /var/log/messages ). It is not a fix. IT may not be likely to report much for your context. vm.pageout_oom_seq controls the "how long is low free RAM tolerated" (my hprasing), though the units are not directly time. In various arm contexts with small boards going from the default of 12 to 120 allowed things to complete or get much farther. So: sysctl vm.pageout_oom_seq=120 but 120 is not the limit: it is a C int parameter. I'll note that "low free RAM" is as FreeBSD classifies it, whatever the details are. Most of the arm examples have been small memory contexts and many of them likely avoid ZFS and use UFS instead. ZFS and its ARC and such an additional complicated context to the type of issue. There are lots of reports around of the ARC growing too big. I do not know the status of -r336196 relative to ZFS/ARC memory management or if more recent versions have improvements. (I do not use ZFS normally.) I've seen messages making suggestions for controlling the growth but I'm no ZFS expert. Just to give an idea what is sufficient to build devel/llvm60: I will note that on a Pine64+ 2GB (so 2 GiBytes of RAM in a aarch64 context with 4 cores, 1 HW-thread per core) running -r337400, and using UFS on a USB drive and a swap partition that drive too, I have built devel/llvm60 2 times via poudriere-devel: just one builder allowed but it being allowed to use all 4 cores in parallel, about 14.5 hr each time. (Different USB media each time.) This did require the: sysctl vm.pageout_oom_seq=120 Mark Johnston's slow_swap.diff patch code did not report any I/O latency problems in the swap subsystem. I've also built lang/gcc8 2 times, about 12.5 hrs each time. No ZFS, no ARC, no Chrome, no FireFox. Nothing else major going on beyond the devel/llvm60 build (or, later, the lang/gcc8 build) in each case. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Mon Aug 20 10:53: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 A6DBE108C6B2 for ; Mon, 20 Aug 2018 10:53:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46B388706A; Mon, 20 Aug 2018 10:53:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.1.32] (ip-213-127-237-35.ip.prioritytelecom.net [213.127.237.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8F20839EF4; Mon, 20 Aug 2018 12:53:05 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_2B610DB7-B17B-4891-BA6B-8A66000FB859"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Date: Mon, 20 Aug 2018 12:53:00 +0200 In-Reply-To: Cc: FreeBSD Current , Brooks Davis To: blubee blubeeme References: X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 10:53:13 -0000 --Apple-Mail=_2B610DB7-B17B-4891-BA6B-8A66000FB859 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 20 Aug 2018, at 05:01, blubee blubeeme wrote: > > I am running current compiling LLVM60 and when it comes to linking > basically all the processes on my computer gets killed; Chrome, Firefox and > some of the LLVM threads as well ... > llvm/build % ninja -j8 > [2408/2473] Building CXX object > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes > -Iinclude -I../include -isystem /usr/local/include -fPIC > -fvisibility-inlines-hidden -Werror=date-time > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > -Wmissing-field-initializers -pedantic -Wno-long-long > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions -fno-rtti -MD > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > ../lib/Passes/PassBuilder.cpp > c++: error: unable to execute command: Killed It is running out of RAM while running multiple parallel link jobs. If you are building using WITH_DEBUG, turn that off, it consumes large amounts of memory. If you must have debug info, try adding the following flag to the CMake command line: -D LLVM_PARALLEL_LINK_JOBS:STRING="1" That will limit the amount of parallel link jobs to 1, even if you specify -j 8 to gmake or ninja. Brooks, it would not be a bad idea to always use this CMake flag in the llvm ports. :) -Dimitry --Apple-Mail=_2B610DB7-B17B-4891-BA6B-8A66000FB859 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW3qdjQAKCRCwXqMKLiCW o9OZAKDR3Zsrvi+f5WaVale/+5GUXQ4gxACfRh6g7ZjvUwa90xaixxR3DKKjK8k= =oiOx -----END PGP SIGNATURE----- --Apple-Mail=_2B610DB7-B17B-4891-BA6B-8A66000FB859-- From owner-freebsd-current@freebsd.org Mon Aug 20 11:26:41 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 D523B108D1E8 for ; Mon, 20 Aug 2018 11:26:41 +0000 (UTC) (envelope-from jbeich@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 9110388A8C; Mon, 20 Aug 2018 11:26:41 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 8A03016140; Mon, 20 Aug 2018 11:26:41 +0000 (UTC) From: Jan Beich To: blubee blubeeme Cc: FreeBSD current Subject: Re: What's this gregset_t gregs thing References: Date: Mon, 20 Aug 2018 13:26:37 +0200 In-Reply-To: (blubee blubeeme's message of "Mon, 20 Aug 2018 08:33:04 +0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 11:26:42 -0000 blubee blubeeme writes: > Linux has gregset_t gregs; > https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h > > Defined above, I also see it in the RISC-V glibc stuff as well. > > FreeBSD doesn't seem to have this field defined, I see FreeBSD uses > /usr/include/x86/ucontext.h > > but there's no gregs; __gregs exists on FreeBSD arm*, inherited from NetBSD. > If I wanted to return mcontext.gregs > > How could I implement that on FreeBSD? Only as gregset_t? If not return registers individually e.g., https://searchfox.org/mozilla-central/rev/83562422ecb0f5683da7a9a26ce05ce62bc0c882/js/src/wasm/WasmSignalHandlers.cpp#244 From owner-freebsd-current@freebsd.org Mon Aug 20 12:48:05 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 BCD1E106C64E for ; Mon, 20 Aug 2018 12:48:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1656F8B992 for ; Mon, 20 Aug 2018 12:48:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id rjbFfpHLwp5A1rjbGfvA94; Mon, 20 Aug 2018 06:48:02 -0600 X-Authority-Analysis: v=2.3 cv=JLKPTPCb c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=dapMudl6Dx4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=hVpOVGfYMOYRxJUr7kEA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 5B93A17A; Mon, 20 Aug 2018 05:48:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w7KCm634002917; Mon, 20 Aug 2018 05:48:06 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w7KCm46k002914; Mon, 20 Aug 2018 05:48:06 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201808201248.w7KCm46k002914@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Dhananjay Balan cc: Cy Schubert , freebsd-current@freebsd.org Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. In-Reply-To: Message from Dhananjay Balan of "Mon, 20 Aug 2018 08:25:11 +0200." <20180820062511.yaa2rimgmwpv3hxx@kazhap> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Aug 2018 05:48:04 -0700 X-CMAE-Envelope: MS4wfD0WShsskQyaVzdShjpBVdEjfFNsrpT7riDQ6oLFKoOG6oZgwFDMOpu07g60wZVF0eBd/L3Hr3ejnmtt2CEB1K5wPx5ZsKSy8uQY6e86Y3Fud+Uc8NpY mCAFh8pRUMFwNOKvsyJiqMkO+Oe+0yr0JROKUFub0gqQfs8NnrTZtWEtk19enJTdsdimOiMgZiuhnJO/jdM9ITAlgVLBb/NMQIT15/t3NdYQ6G0iMq2CEuex X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 12:48:05 -0000 In message <20180820062511.yaa2rimgmwpv3hxx@kazhap>, Dhananjay Balan writes: > On Sat, Aug 18, 2018 at 04:36:15PM -0700, Cy Schubert wrote: > > You can use NFS or rsync. Make sure the src and obj path names are > > exactly the same on all thes servers. I used to use NFS until a year or > > two ago when I started using different patches on different machines. > > On occasion I've used rsync followed by a NO_CLEAN, WORLDFAST, KERNFAST > > build on the target machine or simply installkernel and installworld. > > > > I had a quick try of this, with rsync. installkernel worked properly > and I can boot, howver installworld fails with lot of $PROGRAM not > found erroer for env, mktemp etc. > > Thanks for all the suggestions I will grok at the installworld a bit > more, and will also give PkgBase a try. Make sure the archs are the same. Make sure the src and obj pathnames on both servers are exactly the same. Make sure /usr/src (or wherever you put it) is the same, it too needs to be rsynced. The tiniest differences will lead to this error. Don't do this _during_ a build on the source machine, and other common sense things. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Aug 20 13:49: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 8193B106E504 for ; Mon, 20 Aug 2018 13:49:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0BA08DB82 for ; Mon, 20 Aug 2018 13:49:28 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x236.google.com with SMTP id t25-v6so13922333wmi.3 for ; Mon, 20 Aug 2018 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EQHqhmjbhxoBTHKYeA2XNbSzF5pKdm2Iz0Oa2glHTBk=; b=VkaKkUqy9PJ/YiMpPTCvIwsOAvuf53urZ9f4x6TNOKPIwPFOvXsptLA1Bmf18X3SaQ JLqwzcx7GCsvMIcbuHClJEkXtfHvVooe9RutAHVzyJENxWiIaQzofvgGOQKRIJYVmQBR g3yFxf2NhbcB1gU2cBMmRMzwaHV8iRVApI//IMepb7/bmFU+FiZ8YWsZ+dc46XAAeQhR jsrklKnTvkEusnnU8OVikm+ZaEh3OeVv4pV6Fcrijl4AKbbZm4BQcoOJrxkixp5qH68e XJGsJKUNbvVUN63FJu2pncA1KFg93Nci52uGDvey4O1VfOb5+qg4+U22JvBQZNzqv2fA ysUA== 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=EQHqhmjbhxoBTHKYeA2XNbSzF5pKdm2Iz0Oa2glHTBk=; b=YYwMKZplnAecUFT2dW2v3RvzCwpa1hEmLWTL2lqFUAJp8ylJEXc8O3a1UbOe5GPfms 6RUONhBnMMlvZYtBY6TwdHSsFFBlvmanfqfikRCXgTg7FNR4pjqDBxAZ/t24SMTGklp0 HKVOqcBuKpcvNV3xgAU75T8OjWL+7q7p6Ge347nRGkfcv7ykBZhl79OL+LaFIB0T/0mB NRmLLlncQqz6klEYv2dbr2SE0YwbYIz9NyUEa0/VLkxFMhiABJ7Vq+MQvvbzLjehXkrz pcbR+YJmvyItChYXe3QhcZnpFPUcZSskf4LwU+SiOgxHRRAls8hZc2Z/EwX2nefI/UkD BHyQ== X-Gm-Message-State: AOUpUlFMgHqobS5UXm20kyuEle3Pjp8jrhvgerfk4pey5dMaIgR/659p dAgCPrQ+vs3ZpzfDaK1wkfXLug== X-Google-Smtp-Source: AA+uWPxTsoaMnwhdifZgdelf1iQxgXIMTdVMDYjjC+iBM0E+pekDlkPIHs/F5mGIywS5BL/qcwaz1w== X-Received: by 2002:a1c:b756:: with SMTP id h83-v6mr18294927wmf.8.1534772967689; Mon, 20 Aug 2018 06:49:27 -0700 (PDT) Received: from mutt-hbsd ([50.7.151.127]) by smtp.gmail.com with ESMTPSA id c15-v6sm7934916wmb.2.2018.08.20.06.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 06:49:26 -0700 (PDT) Date: Mon, 20 Aug 2018 09:48:37 -0400 From: Shawn Webb To: blubee blubeeme Cc: FreeBSD current Subject: Re: What's this gregset_t gregs thing Message-ID: <20180820134837.ckkdmls4z5lmkkai@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7nxbr7hyd3qmoqus" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 13:49:29 -0000 --7nxbr7hyd3qmoqus Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2018 at 08:33:04AM +0800, blubee blubeeme wrote: > Linux has gregset_t gregs; > https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/= sys/ucontext.h Please note that that repo is hopelessly old and out-of-date. I created it as a mirror of the official glibc repo because I was doing some offensive research against GNU's RTLD way back in 2011-2012. The repo hasn't been updated since. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --7nxbr7hyd3qmoqus Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlt6xrAACgkQaoRlj1JF bu6feBAAqfD+1ONL0vuDN4ssOtgz37ugcCuU27yDIQR9/EaBr+9VOFCygLMc3YqB HeJY/fHk5xsYRlh1N4zVxX710Vgq1kRHo8PTxyKqf+bZ+px7ZM2CtcosbB6Sf7Jd RG8BzS0IFCBOeW7LJVgbgKu6nrOMzt8u+fCO3J/L2VejB7c0F/qIYmVirYt+9Kvy rgSMhm1TpUTJztpJTRPfkDB34ccUz204i1w7so5nv79KDGP5WMb0DAhVK7jLeOh2 ckLm2+y3I81RnU/5DyuUD6wkjWkin0faDMh4MCZLvC+tdIPL1kbvGjWXKzK5Q+Xb 6gVOuMWeZkEkxo6Xw+5d0kJIjFURXGv4/+igUfJWfeFHOzT6RJ8gUSW7a+xFBGGa k3oUp6pVuL9ToPVITiBuuQYKiIApCGKsPTnvCw2CX9Nd4Xc7xGXgVn7gF+GeuhZY GuWe+EuSPI/uS79f7Pug+y4NXfzh8N8QOoY3Di2kIqOAMbrtQKe7V6PAR8oya3vt uf6NrCOrLtiaDky1EtoLC+Uu+4NMskPYoV98PQwkDhvrJ2NakYgAhKF7yo0yn9jF owRXdfO8CLBjTQTzauYBIPxLDpXArr0bC7YQdRu8UUDP7DQX4ZbajBMQuqjBOPIG M4FXdygvJIbX+7KlRtnDsXsnFbLjg6DLDeCQ2aQ2vZs1BfxkFtc= =QdU8 -----END PGP SIGNATURE----- --7nxbr7hyd3qmoqus-- From owner-freebsd-current@freebsd.org Mon Aug 20 14:26: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 C779A106F93C for ; Mon, 20 Aug 2018 14:26:43 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A28B8F5DF for ; Mon, 20 Aug 2018 14:26:43 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 29A1B22911 for ; Mon, 20 Aug 2018 14:26:43 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-pg1-f169.google.com with SMTP id z25-v6so2179045pgu.7 for ; Mon, 20 Aug 2018 07:26:43 -0700 (PDT) X-Gm-Message-State: AOUpUlFj1Y6vaI3MIvOmPPXYFLu48c58A0HAyAEUmd9ArnApH3fXofkD p7LGO1VBbw5GrL63s5+wVaO2kUUQUgzSsG+TNMA= X-Google-Smtp-Source: AA+uWPxV0HitL+HMvuU1C1bUsmabrFvwdbfWZt/OQIHUNvJCSeAEbAOvho6hmJ/k/iZeQ0xLZMN/TmHHUD2sNyK36d0= X-Received: by 2002:a65:60cf:: with SMTP id r15-v6mr43267136pgv.41.1534775201838; Mon, 20 Aug 2018 07:26:41 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Mon, 20 Aug 2018 16:26:29 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Loading carp module crash i386 (12-ALPHA2), seems VNET related To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 14:26:44 -0000 Just loading carp kernel module is enough to panic it: [root@router]~# uname -a FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M i386 [root@router]~# kldload carp Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14de0f4c fault code = supervisor write, page not present instruction pointer = 0x20:0x1201657c stack pointer = 0x28:0x11f3e804 frame pointer = 0x28:0x11f3e80c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 55291 (kldload) [ thread pid 55291 tid 100070 ] Stopped at vnet_carpstats_init+0x2c: movl %eax,__stop_set_vnet(%ecx,%esi,1) A backtrace on kgdb gives this output: (kgdb) bt #0 __curthread () at ./machine/pcpu.h:226 #1 doadump (textdump=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_shutdown.c:366 #2 0x009f69ee in db_dump (dummy=302081404, dummy2=false, dummy3=-1, dummy4=0x11f3e4fc "") at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:574 #3 0x009f67c7 in db_command (last_cmdp=, cmd_table=, dopager=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:481 #4 0x009f6520 in db_command_loop () at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:534 #5 0x009f978d in db_trap (type=12, code=0) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_main.c:252 #6 0x0113e29e in kdb_trap (type=12, code=0, tf=0x11f3e7c4) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/subr_kdb.c:693 #7 0x016d593c in trap_fatal (frame=0x11f3e7c4, eva=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:989 #8 0x016d5a43 in trap_pfault (frame=, usermode=0, eva=350097228) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:827 #9 0x016d508f in trap (frame=0x11f3e7c4) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:519 #10 0xffc0315d in ?? () #11 0x11f3e7c4 in ?? () #12 0x0121c7ef in vnet_register_sysinit (arg=0x120182cc ) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/net/vnet.c:500 #13 0x010c18f0 in linker_file_sysinit (lf=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:236 #14 linker_load_file (filename=, result=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:462 #15 linker_load_module (kldname=, modname=0x11449c00 "carp", parent=0x0, verinfo=0x0, lfpp=0x11f3ea6c) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:2092 #16 0x010c30d1 in kern_kldload (td=0x1157c380, file=0x11449c00 "carp", fileid=0x11f3ea98) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:1071 #17 0x010c31ee in sys_kldload (td=0x1157c380, uap=0x1157c604) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:1097 #18 0x016d6217 in syscallenter (td=) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/../../kern/subr_syscall.c:135 #19 syscall (frame=0x11f3eba8) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:1152 #20 0xffc033a7 in ?? () #21 0x11f3eba8 in ?? () Backtrace stopped: Cannot access memory at address 0xffbfecec (kgdb) frame 12 #12 0x0121c7ef in vnet_register_sysinit (arg=0x120182cc ) at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/net/vnet.c:500 500 vs->func(vs->arg); Regards, Olivier From owner-freebsd-current@freebsd.org Mon Aug 20 14:26: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 96EE6106F95E for ; Mon, 20 Aug 2018 14:26: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 03E588F62D; Mon, 20 Aug 2018 14:26: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 w7KEQoGV074810; Mon, 20 Aug 2018 07:26:50 -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 w7KEQo9j074809; Mon, 20 Aug 2018 07:26:50 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> Subject: Re: building LLVM threads gets killed In-Reply-To: To: Dimitry Andric Date: Mon, 20 Aug 2018 07:26:50 -0700 (PDT) CC: blubee blubeeme , FreeBSD Current , Brooks Davis 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.27 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, 20 Aug 2018 14:26:55 -0000 > On 20 Aug 2018, at 05:01, blubee blubeeme wrote: > > > > I am running current compiling LLVM60 and when it comes to linking > > basically all the processes on my computer gets killed; Chrome, Firefox and > > some of the LLVM threads as well > ... > > llvm/build % ninja -j8 > > [2408/2473] Building CXX object > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > -fvisibility-inlines-hidden -Werror=date-time > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > -Wmissing-field-initializers -pedantic -Wno-long-long > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions -fno-rtti -MD > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > ../lib/Passes/PassBuilder.cpp > > c++: error: unable to execute command: Killed > > It is running out of RAM while running multiple parallel link jobs. If > you are building using WITH_DEBUG, turn that off, it consumes large > amounts of memory. If you must have debug info, try adding the > following flag to the CMake command line: > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > That will limit the amount of parallel link jobs to 1, even if you > specify -j 8 to gmake or ninja. > > Brooks, it would not be a bad idea to always use this CMake flag in the > llvm ports. :) And this may also fix the issues that all the small memory (aka, RPI*) buliders are facing when trying to do -j4? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Aug 20 14:53: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 0D103107093F for ; Mon, 20 Aug 2018 14:53:56 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BFC970C66; Mon, 20 Aug 2018 14:53:55 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x235.google.com with SMTP id g141-v6so20776934ita.4; Mon, 20 Aug 2018 07:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tVE5CLxlT5Y0x2W3RYHAbtJr5opGGzrE+DaODmcg4fM=; b=YZxbryrsPktXE1wiHAQ8EhrlIwtZjueEBg3k7keIFpbhHNW40Th6xoJ684C8c9Zv1c 9aJ268diuYzOp0o5NwzuB27MaW7dcvNMf0csyE1//XE7bZWKrZk3FQ3IsF3Jfgp+0URV UfyuZDm0ZfpoOttRvz3kTY3ZS8zy/M05es1R3jnHIuSUnqQHAT0qD/iTfIUXRZQFjZz8 HadOUh0HUAbGKOHuMyMf6ZiPx7sl6ccOcVj9jYbHdG4uo3VVjixPayEuk44RrePS62/n IN6sPHDFvX8Vg9YDdwyFgUaeIMZDLOpglq7ql6YXaV967umjuWAq04hlhUFMxr/tMfb4 Gt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tVE5CLxlT5Y0x2W3RYHAbtJr5opGGzrE+DaODmcg4fM=; b=gyntEFrURISGvPkrKuNWPWGH2mAnzb8f2YwKYJlnLkzAiAZIi9Pv9FTLqi8qwQ5U7A xO4fRFnGF/vBoE0UAe+/GcFPgfWdlEBV9o1vKdoWgRaKy6KsmROIVE0vFqKSFvp8/75I tjSjf0ldAc/KkVb9Gs9sJNE8lXths9OlqKejyNYbP59qSjq1wK6FcUwoYNrlzz6Ek+SZ stTkJx4HkEyPZhuiVXvilrJlAUNtTGTFrP1pFsxtkd1nc0XGKOxBHzudjkQ2crI/8WMV feUa11rAhQwyASH9Fkd2FFlJYRz2m5J6SORJn8/pf16rsKPV1goP8oQAcbOgJZSFWlz9 n81Q== X-Gm-Message-State: AOUpUlFOsHvD5OQDlCCynonTOrhh+qaK/Ea6lp2PlZFEImYRb0K0O7Vs kbVVI1tL3vOUCwuS70zhbxciXV7i4PQEMW9dErS9tg== X-Google-Smtp-Source: AA+uWPwCx+yqk83N/6O6NwFRssTr8LtcNJlJJytm4qeqcI6ej3KfuxyVxED1b84OUeqHXkMc5B69iCF6+jmEtP4TAh8= X-Received: by 2002:a24:d0d6:: with SMTP id m205-v6mr495778itg.89.1534776835084; Mon, 20 Aug 2018 07:53:55 -0700 (PDT) MIME-Version: 1.0 References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> From: blubee blubeeme Date: Mon, 20 Aug 2018 22:53:43 +0800 Message-ID: Subject: Re: building LLVM threads gets killed To: freebsd-rwg@pdx.rh.cn85.dnsmgr.net Cc: Dimitry Andric , FreeBSD current , Brooks Davis Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 14:53:56 -0000 On Mon, Aug 20, 2018 at 10:26 PM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On 20 Aug 2018, at 05:01, blubee blubeeme wrote: > > > > > > I am running current compiling LLVM60 and when it comes to linking > > > basically all the processes on my computer gets killed; Chrome, > Firefox and > > > some of the LLVM threads as well > > ... > > > llvm/build % ninja -j8 > > > [2408/2473] Building CXX object > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes > -I../lib/Passes > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > -fvisibility-inlines-hidden -Werror=date-time > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions > -fno-rtti -MD > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > ../lib/Passes/PassBuilder.cpp > > > c++: error: unable to execute command: Killed > > > > It is running out of RAM while running multiple parallel link jobs. If > > you are building using WITH_DEBUG, turn that off, it consumes large > > amounts of memory. If you must have debug info, try adding the > > following flag to the CMake command line: > > > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > > > That will limit the amount of parallel link jobs to 1, even if you > > specify -j 8 to gmake or ninja. > > > > Brooks, it would not be a bad idea to always use this CMake flag in the > > llvm ports. :) > > And this may also fix the issues that all the small > memory (aka, RPI*) buliders are facing when trying > to do -j4? > > > -- > Rod Grimes > rgrimes@freebsd.org Someone mentioned earlier that debug builds cause a lot of memory usage and it's true that I am building with debug. I couldn't grab the relevant text from top but the posted was after everything settled down. The memory situation got so bad that xserver died and I was booted to terminal. I saw ld.lld using up to 12GB of ram for each process, that will definitely use up 32GB of ram. I can't avoid building w/ debug symbols since I have to debug the program are there any other options other than building with only 1 thread? Reason being even when I set gmake -j1 the problem comes just a lot later during linking stage. Best, Owen From owner-freebsd-current@freebsd.org Mon Aug 20 14:55: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 31FEF10709AE for ; Mon, 20 Aug 2018 14:55:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE50470D78 for ; Mon, 20 Aug 2018 14:55:14 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x229.google.com with SMTP id p81-v6so20796531itp.1 for ; Mon, 20 Aug 2018 07:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKwRyYZzLoiaQ9rVC1Nvgn9NR4IEt1nm9+qSVlqvh9s=; b=h/+lPMEyLBevAhStwJ5GRexgDzwvpnJPYoEhR+ZD4FmT9L9s0yeh8MUVZrJe4TYhVH V01NfafNLiI18joLR09t4JvfLFaJpvKuQfbjSEBZdqxWn1HO65X/chzIpRywMVlITLbD 9V+Suxt+6sKboxgLkzYb52v1JW1tCZKh/FFRdYqg9kWfTtaksE/FwzqTrUVEd+nzL/S7 8Mn/QDmiVzwOyJQmE6/mEaDdaRKqlGSFutAhEXzRtnZYxOobHNPQ+g4/yszrCMar5VX4 c3GQm6gqKKOkrLKEmHN+f0LPN02p51DEuIF1aGJSYqQxqzTHzDeEbXIQS+YdMvb3IB0P pYeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKwRyYZzLoiaQ9rVC1Nvgn9NR4IEt1nm9+qSVlqvh9s=; b=UIPjwG95FIo+yi72S20K/8irkUsQwNhFJCmaqZ/oCX7fChzCvScoy25GsK1nBewUWR tl/8uMPrFZolVH4nlapgTRDkufpBoWE+FHMYy16ei6dgfxX8Ae2gp7+0yX8EYzAaKc1i s5b2KkrR5MZn9nbeORRePMTYUXGbGExRlcb+vcERVYa0zoSgauUqu5Lp72GfDCO6iDn4 yjonUvXIoxflz/FiXQINqFHnaEIw08V8gTEf9sTF+dQoHZQRZyFx09Invp+FkO0UyZJ+ Tdpz839nfEeMOWMigtenKKacAwBBIVVRynGYGlGEOGoUUGp4cI2B3jVjM08nOVk+AVcg AWiw== X-Gm-Message-State: AOUpUlGAvvnhlgEBniMT/QyhckqIxc5mg7vly0qeqgWwYl9b11jrXCjk YiOXP9RwOXw/LaTaPQ6kq3DSFjtP8vnXHgRC2WkEug== X-Google-Smtp-Source: AA+uWPy3KoRUN8QGSbJEptI6rXpKaA/ttLWTnQrXm5BcHCUIiuEXNdgoi3NfJgI/vHm65Dtv4ot3MnABFSTtqefjAmo= X-Received: by 2002:a24:d0d6:: with SMTP id m205-v6mr500143itg.89.1534776914314; Mon, 20 Aug 2018 07:55:14 -0700 (PDT) MIME-Version: 1.0 References: <20180820134837.ckkdmls4z5lmkkai@mutt-hbsd> In-Reply-To: <20180820134837.ckkdmls4z5lmkkai@mutt-hbsd> From: blubee blubeeme Date: Mon, 20 Aug 2018 22:55:02 +0800 Message-ID: Subject: Re: What's this gregset_t gregs thing To: shawn.webb@hardenedbsd.org Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 14:55:15 -0000 On Mon, Aug 20, 2018 at 9:49 PM Shawn Webb wrote: > On Mon, Aug 20, 2018 at 08:33:04AM +0800, blubee blubeeme wrote: > > Linux has gregset_t gregs; > > > https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h > > Please note that that repo is hopelessly old and out-of-date. I > created it as a mirror of the official glibc repo because I was doing > some offensive research against GNU's RTLD way back in 2011-2012. The > repo hasn't been updated since. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > Thanks for all the replies, I think OSX also lacks this gregs_t thing as well I was able to lock it up behind some ifdefs and all is well. Best, Owen From owner-freebsd-current@freebsd.org Mon Aug 20 14:58:22 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 7B93B1070ADC for ; Mon, 20 Aug 2018 14:58:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.42]) (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 254C470F82 for ; Mon, 20 Aug 2018 14:58:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: HkooCzIVM1nUbGwjjs43NyMIK9lmckmLO_nlmsW81lr8l.B5Oo9ah0xBwpytXx5 6qOw9f2Y8lVikO5vtcrQoJXTkdLw6C1LRkyvk_3bkFsoLhCjwY8uk6cp5PNgZQXtwVqQ57H5rmjN .XcnPlBuDVvsT8DSYvley2pdLhX0HdJRTPidpEjtr18uqKESEnGlkfj2E0oMJxET3FbY.d7JvdZi 9ZJxD.ASLdQyxPrCtcneX9Gd4mM.iyf7PiYBOn_hvaERVw36aXsu4rtjpeXLdprgqtGoA9w2VG5n RbTAoAU8AnkfCAV_ZU1EAIRxc8ynQ0h89W26CMZaq6bkX3h_Yd8LEn3jWSRBV7c7r03.IOc2gU6U tm20msXdG0SjF11AMOq1Fwfh0zhSiyurriJu5wRx_.VVky5Djh91y4bBhh.aoONReyrxgR_T6SZ6 5yqtrz3ZUbp_wptEL3PFv.wiiCueFTTcx7lQKvQq2xPjYedqK_j3EZ6ueER3AmigucHW_vUUtFGG WEG1.Oq3TUpKQYiEc4ASyWvk_eqYCasQ.OK8oJO6Qgu_tFyqa_gNiITRT8BQW28vgqrlvRPcUTsd XLAgC0jgiZf60yTiWKiEbCHnK5exIWqRmZ7zNaFmPWVcQTOwuBGw9lastBuuxeSQo8zjlRJA460b dMKSO9Q6qGNdPx9Xd6WCL256QQn5DFF9WcCfoMbiruKyR8l0fkykKmMx2V.fsSsWpdxGjoxFjmsD wq_2sAJp6cZGpFN8hjIp6EGxuiDDgAD50Sq9uSZqb7A1gKCVF9jA9gs6sLy0S_SNUK5vJap10wAC dJ_fVI8Ulfo6NXrcWZ7AFVW1KLJi0_Qw1LDo2KMa_P4u9ICYB8iNr7C2.hOaLeNPBjGiqq0E5PJI S.swAgmP69oilIPqidt7vc02qsylxi.FOWgpwkpH70lzm0TVtCaAEt1.fjWJjMIXtzz5OZcRpNIH pC9gHtD_LdSTSSmF2Pq867th_3UZ.AN.PsaeBeYzDujQnaXwFzPDWZCmLtki2P6LWMpJ713Oh11D dtggrTESbdrhYCCpfHBh5sMzn9f0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 20 Aug 2018 14:58:21 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1e26d093bcee1be57370e1547a46f5e5; Mon, 20 Aug 2018 14:58:16 +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.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Message-Id: <61A99917-931B-45C0-8F6E-6BC0BE5DEAFB@yahoo.com> Date: Mon, 20 Aug 2018 07:58:14 -0700 To: "Rodney W. Grimes" , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 14:58:22 -0000 Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on Mon Aug 20 14:26:55 UTC 2018 : > > On 20 Aug 2018, at 05:01, blubee blubeeme = wrote: > > >=20 > > > I am running current compiling LLVM60 and when it comes to linking > > > basically all the processes on my computer gets killed; Chrome, = Firefox and > > > some of the LLVM threads as well > > ... > > > llvm/build % ninja -j8 > > > [2408/2473] Building CXX object > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > /usr/bin/c++ -DGTEST_HAS_RTTI=3D0 -D_DEBUG = -D__STDC_CONSTANT_MACROS > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes = -I../lib/Passes > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > -fvisibility-inlines-hidden -Werror=3Ddate-time > > > -Werror=3Dunguarded-availability-new -std=3Dc++11 -Wall -Wextra > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > -Wcovered-switch-default -Wnon-virtual-dtor = -Wdelete-non-virtual-dtor > > > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions = -fno-rtti -MD > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > ../lib/Passes/PassBuilder.cpp > > > c++: error: unable to execute command: Killed > >=20 > > It is running out of RAM while running multiple parallel link jobs. = If > > you are building using WITH_DEBUG, turn that off, it consumes large > > amounts of memory. If you must have debug info, try adding the > > following flag to the CMake command line: > >=20 > > -D LLVM_PARALLEL_LINK_JOBS:STRING=3D"1" > >=20 > > That will limit the amount of parallel link jobs to 1, even if you > > specify -j 8 to gmake or ninja. > >=20 > > Brooks, it would not be a bad idea to always use this CMake flag in = the > > llvm ports. :) >=20 > And this may also fix the issues that all the small > memory (aka, RPI*) buliders are facing when trying > to do -j4? It may help, but: Even just compiles with no links running can get the kills in such small system contexts. And going for a simpler context that can demonstrate the behavior . . . Taking a Pine64+ 2GB as an example (4 cores with 1 HW-thread per core, 2 GiBytes of RAM, USB device for root file system and swap partition): In another login: # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 That "4" and "536870912" total to the 2 GiBytes so swapping is induced for the context in question. (Scale --vm-bytes appropriately to context.) [Note: I had 3 GiBytes of swap space in a partition for the below.] [stress is from the port sysutils/stress .] I had left the default vm.pageout_oom_seq=3D12 in place for this, making the kills easier to get than the 120 figure would. It does not take very long generally for some sort of message to show up. Sometimes kills happen: My test environment has Mark Johnston patches to report things not normally reported: waited 9s for async swap write waited 9s for swap buffer waited 9s for async swap write waited 9s for async swap write waited 9s for async swap write v_free_count: 1357, v_inactive_count: 1 Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out = of swap space waited 5s for async swap write waited 5s for swap buffer waited 5s for async swap write waited 5s for async swap write waited 5s for async swap write waited 13s for async swap write waited 12s for swap buffer waited 13s for async swap write waited 12s for async swap write waited 12s for async swap write swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: = 65536 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: = 12288 . . . (I made multiple runs, most manually stopped. None run for all that long.) (Warning: the swap space part of "killed: out of swap space" can be a misnomer. Killing is driven by having low free RAM for sufficiently long. vm.pageout_oom_seq controls how long. Swap space may be unused, little used, or actually be low. With 3 GiBytes of swap space in the partition, these runs were not low on swap space.) Even with fairly stable ms/w figures the queue depths can get to be large, implying long times before the last queued write completes. For example (for a USB storage device for the root file system and swap partition): dT: 1.006s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| mmcsd0 56 312 0 0 0.0 312 19985 142.6 0 0 = 0.0 99.6| da0 Large quantities of bytes are being queued in a short time relative to the around 20 MiByte/sec figure that can be sustained. The quantity is spread over the queue entries. Note: The Pine46+ 2GB builds devel/llvm60 in 14.5hr just fine with vm.pageout_oom_seq=3D120 when using all 4 cores. But it has twice the RAM as a rpi3/rpi2 while having the same number of cores. It simply does not have as much to write out as often. (The same sort of point goes for buildworld buildkernel sorts of activities.) =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 Aug 20 15:09: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 0CEE210715CB for ; Mon, 20 Aug 2018 15:09:16 +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 7BCEC71BB4; Mon, 20 Aug 2018 15:09:15 +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 w7KF94gD096730 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Aug 2018 18:09:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7KF94gD096730 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7KF94Jh096729; Mon, 20 Aug 2018 18:09:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Aug 2018 18:09:04 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180820150904.GS2340@kib.kiev.ua> References: <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180820004512.5171fa75@bsd64.grem.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 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, 20 Aug 2018 15:09:16 -0000 On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: > > See here for a screenshot (also including the output of "show pte > 0xfffff80001000000"): > > https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png It is too early for ddb routines to register. Ok can you try the following debugging patch, to verify my guess ? diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 18777d23f09..cd05fdb763f 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) pd_p = (pd_entry_t *)DMPDkernphys; for (i = 0; i < (NPDEPG * nkdmpde); i++) pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | - X86_PG_M | X86_PG_A | pg_nx | - bootaddr_rwx(i << PDRSHIFT); + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; for (i = 0; i < nkdmpde; i++) pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW | X86_PG_V; From owner-freebsd-current@freebsd.org Mon Aug 20 15:39:42 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 2235A1072ACE for ; Mon, 20 Aug 2018 15:39:42 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9743C72F98; Mon, 20 Aug 2018 15:39:41 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: by mail-pl0-x230.google.com with SMTP id j8-v6so7286982pll.12; Mon, 20 Aug 2018 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=u7l6ZkjMaXUfKV1DijHV60ZrIE89a0SEnBJB0XY2n48=; b=py7USZanxmhLSnXmMd+FMQECsu22hgFmcHkxtl+J13B/hkH29TtQwkqWZePqllUXrH CgUxrJCMF4/YeixmfUVb+3ow4SlKUU/uBWfoInkh+SnP4GQyCcLLC8/e+8qaRckUq2wJ UlzbyR16QluHJUfAs9ah/IL2+CVS0QwFXWBt4prpxPK7cP23Z+eR5X3v3kgVz8HvmVt9 J+dSItPbV8IsLjNWXJQS6YSzvCOODDaX+InJqa9gzEMQYAAVj2vFCxH7WcUaEMMTOPro 7dWzbTII/5GsGHxMvByA9Fa+X+F0KQWBDKY5N2J3yhQuV9eqxcppRSQXFzKw7raVS9SZ +t1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=u7l6ZkjMaXUfKV1DijHV60ZrIE89a0SEnBJB0XY2n48=; b=VrLqdxCZ6CsyK4Uc5iTe5rUObAdZUzR0l+mNUuJchwBWVT1gr58YV3rBqBlEAUP2za +93Vzja+xhwghyqzMiKBj9ifAHtrBi+k36RN0uZ9cnznfJbxug+Ps2p3yXJ6EjquclTa dBQrF1i8kSV1sq0XrKM12Q5D2TMTJDE9q8Cg38m1PNRQ/o/AwlETXKXHWKN9XhddV3hZ UybTycmEjc/xFoqN498TrKgZX1VifVxCIKYlNO/BnkgPLqM2M2sl5+/6e2xPoEsdvEiv XaE0CjcmWPd209w6pAtRTvrXN8pRKF23Qk+Aj4GxdvYnQjNMxQMqC3nnHmhXwB2yGK8P Fu0w== X-Gm-Message-State: AOUpUlG1jKCRpUJnv9lK+n23niYAsukvXK+2IXoQZQNvBZ0mGOuAG6EM tPZ5MLGwSc5wYdpvr8BK0NE8ksVvnUM= X-Google-Smtp-Source: AA+uWPwhPXlbR4bsg7Vz5Tqt4l3T2aLVAfDXRTBtEbZm8B9oAXKo+fgpM+Yyox3MLtIRQOybH5LnDQ== X-Received: by 2002:a17:902:7d93:: with SMTP id a19-v6mr7277518plm.215.1534779580364; Mon, 20 Aug 2018 08:39:40 -0700 (PDT) Received: from octo.pozo.com (50-197-129-138-static.hfc.comcastbusiness.net. [50.197.129.138]) by smtp.gmail.com with ESMTPSA id u30-v6sm2607912pgk.66.2018.08.20.08.39.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 08:39:39 -0700 (PDT) From: Manfred Antar Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: LUA boot loader coming very soon Message-Id: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> Date: Mon, 20 Aug 2018 08:39:38 -0700 Cc: imp@freebsd.org To: FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 15:39:42 -0000 Hi How do i get the menu back after switching to LUA loader? I=E2=80=99m using a comconsole. Before the switch to LUA I had a menu = and a little devil with pitchfork:) Now just get the countdown from 10 , then boot. Here is my loader.conf.local: console=3D"comconsole" beastie_disable=3D"NO" hw.vga.textmode=3D1 kern.vt.spclkeys=3D15 nvidia_load=3D"YES" linux_common_load=3D"YES" linux_load=3D"YES" linprocfs_load=3D"YES" linsysfs_load=3D=E2=80=9CYES" I also had a loader.rc file but it does not seem relevant to LUA: \ Loader.rc \ $FreeBSD: head/stand/i386/loader/loader.rc 332413 2018-04-11 18:02:13Z = imp $ \ \ Includes additional commands include /boot/loader.4th include /boot/efi.4th try-include /boot/loader.rc.local \ Reads and processes loader.conf variables initialize maybe-efi-resizecons \ Tests for password -- executes autoboot first if a password was = defined check-password \ Load in the boot menu include /boot/beastie.4th \ Start the boot menu beastie-start Thanks Manfred= From owner-freebsd-current@freebsd.org Mon Aug 20 15:56: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 4049C107325F for ; Mon, 20 Aug 2018 15:56:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4669739A4 for ; Mon, 20 Aug 2018 15:56:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7948423234 for ; Mon, 20 Aug 2018 15:56:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f48.google.com with SMTP id y200-v6so11273467lfd.7 for ; Mon, 20 Aug 2018 08:56:21 -0700 (PDT) X-Gm-Message-State: AOUpUlHNUBK396ydb2BhkkPi+E2PANvZqoaD5Ibhm1mecR+htfI8nOT4 lzfvnh2cA/S1Q6cytsIgV/WfpRPuzYrE1FHmGg0= X-Google-Smtp-Source: AA+uWPzLPLaqKzQHApJDmPGi7dzYaiVZ/jwauCLn95jKjkA+NyHY90pLrTliQrSAwT74wl30MhO8/WpkBkJTX2os1rU= X-Received: by 2002:a19:ea52:: with SMTP id i79-v6mr4936042lfh.75.1534780579951; Mon, 20 Aug 2018 08:56:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 08:55:59 -0700 (PDT) In-Reply-To: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> References: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> From: Kyle Evans Date: Mon, 20 Aug 2018 10:55:59 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA boot loader coming very soon To: Manfred Antar Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 15:56:25 -0000 On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar wr= ote: > Hi > How do i get the menu back after switching to LUA loader? > I=E2=80=99m using a comconsole. Before the switch to LUA I had a menu and= a little devil with pitchfork:) > Now just get the countdown from 10 , then boot. > Here is my loader.conf.local: > > console=3D"comconsole" > beastie_disable=3D"NO" > hw.vga.textmode=3D1 > kern.vt.spclkeys=3D15 > nvidia_load=3D"YES" > linux_common_load=3D"YES" > linux_load=3D"YES" > linprocfs_load=3D"YES" > linsysfs_load=3D=E2=80=9CYES" > Hmm... seems that there was a miscommunication at some point, and the menu is disabled explicitly on serial boots. console=3D"comconsole" is enough to disable this in lualoader land. An excerpt from an e-mail I was forwarded regarding this: if $console contains (space or comma separated) "efi" then do not draw a menu (fall back to autoboot routine). if $beastie_disable is set to "YES" (case insensitive), then do not draw a menu (fall back to autoboot routine). We are clearly doing this wrong. I will fix it ASAP. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Mon Aug 20 16:20: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 B5CD6107444F for ; Mon, 20 Aug 2018 16:20:43 +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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5697502F for ; Mon, 20 Aug 2018 16:20:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x230.google.com with SMTP id w11-v6so13062099iob.2 for ; Mon, 20 Aug 2018 09:20:43 -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=qR+dEpcdLC0Vi61iDh6NTi6e8u6b7Mlrs+1W/hKrsaI=; b=iNujvT+MvX++V3jB+9RU2YvqgGO0QV2vH9JFASwTIu23vvT8VEgj4OKF5zMR3v0XzB 1mAyGQyEEUuF+BT2OvPfVLNWF/jVzzBpYz1+Hc6a6twK+vcPoXr66kX6iBel7wsFRDs/ BFSz35LUIcpZys/1mJbJe9GyCf2OjdK+pC6oXIWr6GkYAl7M1f9FTc4JcTcgQLtI+Wns HA12QITFtAMPHSXEyrr50vBjkXacEaWjBdItP9KlXV1GvBlONy5NPwgc1O4gbfr3p3fj K9FHyU1rA3wQ7QWHE9fwzv3VAwZiKqVxZ/Bx+zS48XQCTxq7s1NajgJ74dybAz73VwUx eUvQ== 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=qR+dEpcdLC0Vi61iDh6NTi6e8u6b7Mlrs+1W/hKrsaI=; b=o9YyOtlyXlVclRnOazeFWQ4B0cBl/+FNAc/uOogWGvfUvVXcn0metzpJKCLOlhF+lP TKLN29WLTOrqP4rTuEU1iY1pmG7ad+JYwdaQZdZ09mSv/IZ9WJE1M1ETa05DxWBZMPRa DyiPmv3UgP3E18YhYg2V94hb7p6UojoNu3xCTo7577CrS5MAlE5dZ/McTM90OCL3UvT9 ZMDWB17qa4a79c8ZG1RLD+iJcad12mA8INCeQCxijn9/EN8WlLCwfS4tdYIQXDuIkpJR G3hhrcc1cUgOZtqHY65imKGik4cENZ4TE7yz4BnYmHmOLTaq/9VHeEG2qMKExLSep182 KG+A== X-Gm-Message-State: AOUpUlF/TyMT6qjebwOpaergk5IMz2PJ0qvUYp6lin527ZyIg0ao5uPu EPA2ND8PLwXnmNZb75oJW1qDR+5Iky8XIPTbiACQyA== X-Google-Smtp-Source: AA+uWPzHAkVk+exnuVQ55FEXp17kRl50Etl8zlQ14Mt/XyEGXdP/lgGo+N2tW0nBE3p7shSldXKQdqbQi6GnZQR/Xd4= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr38980731ioa.168.1534782042440; Mon, 20 Aug 2018 09:20:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 09:20:41 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: References: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> From: Warner Losh Date: Mon, 20 Aug 2018 10:20:41 -0600 X-Google-Sender-Auth: O1_-4obJZOzLVaHL-XDNG3qO3mM Message-ID: Subject: Re: LUA boot loader coming very soon To: Kyle Evans Cc: Manfred Antar , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 16:20:44 -0000 On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans wrote: > On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar > wrote: > > Hi > > How do i get the menu back after switching to LUA loader? > > I=E2=80=99m using a comconsole. Before the switch to LUA I had a menu a= nd a > little devil with pitchfork:) > > Now just get the countdown from 10 , then boot. > > Here is my loader.conf.local: > > > > console=3D"comconsole" > > beastie_disable=3D"NO" > > hw.vga.textmode=3D1 > > kern.vt.spclkeys=3D15 > > nvidia_load=3D"YES" > > linux_common_load=3D"YES" > > linux_load=3D"YES" > > linprocfs_load=3D"YES" > > linsysfs_load=3D=E2=80=9CYES" > > > > Hmm... seems that there was a miscommunication at some point, and the > menu is disabled explicitly on serial boots. console=3D"comconsole" is > enough to disable this in lualoader land. An excerpt from an e-mail I > was forwarded regarding this: > > if $console contains (space or comma separated) "efi" then do > not draw a menu (fall back to autoboot routine). > > if $beastie_disable is set to "YES" (case insensitive), then do not > draw a menu (fall back to autoboot routine). > > We are clearly doing this wrong. I will fix it ASAP. > I think that we need https://reviews.freebsd.org/D16816 to fix all the bits. Warner From owner-freebsd-current@freebsd.org Mon Aug 20 17:33: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 32B211076657 for ; Mon, 20 Aug 2018 17:33:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A61BC78760; Mon, 20 Aug 2018 17:33:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 259DA39F26; Mon, 20 Aug 2018 19:33:45 +0200 (CEST) From: Dimitry Andric Message-Id: <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_6ADE5990-1E46-4E8D-BFB1-AC2177E2A668"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Date: Mon, 20 Aug 2018 19:33:32 +0200 In-Reply-To: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> Cc: blubee blubeeme , FreeBSD Current , Brooks Davis To: "Rodney W. Grimes" References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 17:33:47 -0000 --Apple-Mail=_6ADE5990-1E46-4E8D-BFB1-AC2177E2A668 Content-Type: multipart/mixed; boundary="Apple-Mail=_7B8AAAE0-4E90-421F-A983-8D414354B4E9" --Apple-Mail=_7B8AAAE0-4E90-421F-A983-8D414354B4E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Aug 2018, at 16:26, Rodney W. Grimes = wrote: >=20 >> On 20 Aug 2018, at 05:01, blubee blubeeme = wrote: >>>=20 >>> I am running current compiling LLVM60 and when it comes to linking >>> basically all the processes on my computer gets killed; Chrome, = Firefox and >>> some of the LLVM threads as well ... >=20 >> It is running out of RAM while running multiple parallel link jobs. = If >> you are building using WITH_DEBUG, turn that off, it consumes large >> amounts of memory. If you must have debug info, try adding the >> following flag to the CMake command line: >>=20 >> -D LLVM_PARALLEL_LINK_JOBS:STRING=3D"1" >>=20 >> That will limit the amount of parallel link jobs to 1, even if you >> specify -j 8 to gmake or ninja. >>=20 >> Brooks, it would not be a bad idea to always use this CMake flag in = the >> llvm ports. :) >=20 > And this may also fix the issues that all the small > memory (aka, RPI*) buliders are facing when trying > to do -j4? Possibly, as linking is usually the most memory-consuming part of the build process (and more so, if debugging is enabled). Are there build logs available somewhere for those RPI builders? I have attached a patch for most of the llvm ports, which sets the LLVM_PARALLEL_LINK_JOBS CMake flag during the configure phase. -Dimitry --Apple-Mail=_7B8AAAE0-4E90-421F-A983-8D414354B4E9 Content-Disposition: attachment; filename=devel__llvm-all-parallel-link-jobs-1.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="devel__llvm-all-parallel-link-jobs-1.diff" Content-Transfer-Encoding: 7bit Index: devel/llvm-cheri/Makefile =================================================================== --- devel/llvm-cheri/Makefile (revision 477662) +++ devel/llvm-cheri/Makefile (working copy) @@ -36,6 +36,7 @@ STACK_ALIGN?= -mstack-alignment=32 CMAKE_INSTALL_PREFIX= ${LLVM_PREFIX} CMAKE_ARGS+= -DLLVM_BUILD_LLVM_DYLIB=ON \ -DLLVM_DEFAULT_TARGET_TRIPLE=cheri-unknown-freebsd +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 USE_GITHUB= yes GH_ACCOUNT= CTSRD-CHERI Index: devel/llvm-devel/Makefile =================================================================== --- devel/llvm-devel/Makefile (revision 477662) +++ devel/llvm-devel/Makefile (working copy) @@ -46,6 +46,7 @@ CMAKE_ARGS+= -DLLVM_HOST_TRIPLE=${CONFIGURE_TARGET # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 USE_GITHUB= yes GH_ACCOUNT= llvm-mirror Index: devel/llvm38/Makefile =================================================================== --- devel/llvm38/Makefile (revision 477662) +++ devel/llvm38/Makefile (working copy) @@ -42,6 +42,7 @@ CMAKE_ARGS= # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 OPTIONS_DEFINE= CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_DEFINE_amd64= GOLD OPENMP Index: devel/llvm40/Makefile =================================================================== --- devel/llvm40/Makefile (revision 477662) +++ devel/llvm40/Makefile (working copy) @@ -47,6 +47,7 @@ CMAKE_ARGS+= -DLLVM_HOST_TRIPLE=${CONFIGURE_TARGET # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 OPTIONS_DEFINE= CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_DEFINE_amd64= COMPILER_RT GOLD OPENMP Index: devel/llvm50/Makefile =================================================================== --- devel/llvm50/Makefile (revision 477662) +++ devel/llvm50/Makefile (working copy) @@ -47,6 +47,7 @@ CMAKE_ARGS+= -DLLVM_HOST_TRIPLE=${CONFIGURE_TARGET # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 OPTIONS_DEFINE= CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_DEFINE_amd64= COMPILER_RT GOLD OPENMP Index: devel/llvm60/Makefile =================================================================== --- devel/llvm60/Makefile (revision 477662) +++ devel/llvm60/Makefile (working copy) @@ -47,6 +47,7 @@ CMAKE_ARGS+= -DLLVM_HOST_TRIPLE=${CONFIGURE_TARGET # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 OPTIONS_DEFINE= CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_DEFINE_amd64= COMPILER_RT GOLD OPENMP Index: devel/llvm70/Makefile =================================================================== --- devel/llvm70/Makefile (revision 477662) +++ devel/llvm70/Makefile (working copy) @@ -47,6 +47,7 @@ CMAKE_ARGS+= -DLLVM_HOST_TRIPLE=${CONFIGURE_TARGET # we need to either change the whole man-shuffle below, or simply # redefine CMAKE_INSTALL_MANDIR CMAKE_ARGS+= -DCMAKE_INSTALL_MANDIR:PATH="share/man" +CMAKE_ARGS+= -DLLVM_PARALLEL_LINK_JOBS=1 OPTIONS_DEFINE= CLANG DOCS EXTRAS LIT LLD LLDB OPTIONS_DEFINE_amd64= COMPILER_RT GOLD OPENMP --Apple-Mail=_7B8AAAE0-4E90-421F-A983-8D414354B4E9-- --Apple-Mail=_6ADE5990-1E46-4E8D-BFB1-AC2177E2A668 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW3r7bAAKCRCwXqMKLiCW o7wPAJ4tMmNVYgpFHsA2jq8rT58mHhD+dACfYo+mPuqiElP2fOpyVHArE5VsLow= =9NYZ -----END PGP SIGNATURE----- --Apple-Mail=_6ADE5990-1E46-4E8D-BFB1-AC2177E2A668-- From owner-freebsd-current@freebsd.org Mon Aug 20 17:44: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 E62AD10769D9 for ; Mon, 20 Aug 2018 17:44:18 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67DAD790A7; Mon, 20 Aug 2018 17:44:18 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: by mail-pl0-x236.google.com with SMTP id g23-v6so4500255plq.9; Mon, 20 Aug 2018 10:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XqmtWsgF0k79mIegTSL5VXRNdo8ucj9eDgMmDcxoFag=; b=sHjX/DeE3j3gJlqCQ/+JLATK9CcV54j1g1lj+PIPxJeBrFRSqLX/WCPpQpLdo2DWKw fcxkxTBvEJko570R3vkQGwKvmVKB1sRgLnHi4gjLgxCSqsNFWRphQBHP+zXouzuUPhiT godeMMU3RVBZn3POaI9m/FtZv1aKiUqk8kFZpmR8xQnsp9+IgEPOsbPlhdWPxX20KD0i M+Xg0rsqdWr+I0zd8GPiXkaJhpy1XkMgKtEJOkMirnExsTHBdKV5rVeeMqHf4/v6xxyM BUQODayubKl12wsDjwjeW0CPgkjGjH6L2+4igRG9UvgMYxVYwcyIhFsgqLKka/9OTE/d AawA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XqmtWsgF0k79mIegTSL5VXRNdo8ucj9eDgMmDcxoFag=; b=chqJlEUSZq28EyU9qLg16OLwgsTQKfrP11GldXNVu8hmnFwHeoqedZ8qpz1E63gc52 rU3KTAkPLiKXuUM3i1W4aKooHlsuERPzFzLherymkZpJPSDZg/paqFQgqJqjay6s5dSc 0TfNjs20drGWcOodMp538FhB/NqkwGIUTCAyv9WlSjmFzkjKRlL5qc1t3gaA6dteH1X+ XTiiGv2xqLMJ54XsISPFDxqieWFqHpbu5fJF3vkqwpvl1iJ2e3nd7qPD7GH0jhWBwxFo 3UC8l91IbFuUg1oLUZalW3i8Yijyxfp8unuWWruH7dZxag0/NAo2sGd09otG9ecw4pJK SIBg== X-Gm-Message-State: AOUpUlF9/ow8+LGQ+9wFpKP/btIemPLt0o8CoocBrf4NZalFacs2kEzS YeidYAqC8svCY+nQvlp2eSU3MiZ/zZxBFg== X-Google-Smtp-Source: AA+uWPxzdfBfRz5iVk9i1iX99SVzl3OSJluAxJeKlQMcPFRb72jhDlMqU0aHT0SmdXn1HqnnDRa6PQ== X-Received: by 2002:a17:902:a40b:: with SMTP id p11-v6mr47037047plq.228.1534787057328; Mon, 20 Aug 2018 10:44:17 -0700 (PDT) Received: from octo.pozo.com (50-197-129-138-static.hfc.comcastbusiness.net. [50.197.129.138]) by smtp.gmail.com with ESMTPSA id c4-v6sm17858204pfb.71.2018.08.20.10.44.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 10:44:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: LUA boot loader coming very soon From: Manfred Antar In-Reply-To: Date: Mon, 20 Aug 2018 10:44:15 -0700 Cc: FreeBSD Current , Kyle Evans Content-Transfer-Encoding: quoted-printable Message-Id: References: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 17:44:19 -0000 > On Aug 20, 2018, at 9:20 AM, Warner Losh wrote: >=20 >=20 >=20 > On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans = wrote: > On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar = wrote: > > Hi > > How do i get the menu back after switching to LUA loader? > > I=E2=80=99m using a comconsole. Before the switch to LUA I had a = menu and a little devil with pitchfork:) > > Now just get the countdown from 10 , then boot. > > Here is my loader.conf.local: > > > > console=3D"comconsole" > > beastie_disable=3D"NO" > > hw.vga.textmode=3D1 > > kern.vt.spclkeys=3D15 > > nvidia_load=3D"YES" > > linux_common_load=3D"YES" > > linux_load=3D"YES" > > linprocfs_load=3D"YES" > > linsysfs_load=3D=E2=80=9CYES" > > >=20 > Hmm... seems that there was a miscommunication at some point, and the > menu is disabled explicitly on serial boots. console=3D"comconsole" is > enough to disable this in lualoader land. An excerpt from an e-mail I > was forwarded regarding this: >=20 > if $console contains (space or comma separated) "efi" then do > not draw a menu (fall back to autoboot routine). >=20 > if $beastie_disable is set to "YES" (case insensitive), then do not > draw a menu (fall back to autoboot routine). >=20 > We are clearly doing this wrong. I will fix it ASAP. >=20 > I think that we need https://reviews.freebsd.org/D16816 to fix all = the bits. >=20 > Warner=20 Ok that works I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, = otherwise just have devilhead. drawer.default_color_logodef =3D 'orb' drawer.default_bw_logodef =3D =E2=80=98orbbw' to: drawer.default_color_logodef =3D 'beastie' drawer.default_bw_logodef =3D =E2=80=98beastiebw' and it=E2=80=99s pretty much the same as the 4th menu i had before. Is there a way to put: drawer.default_color_logodef =3D 'beastie' drawer.default_bw_logodef =3D 'beastiebw' somewhere else ie loader.rc or loader.lua.local so I don=E2=80=99t have = to edit the /boot/lua/drawer.lua everytime I rebuild world? It doesn=E2=80=99t work to put in loader.conf.local Thanks Manfred= From owner-freebsd-current@freebsd.org Mon Aug 20 17:47: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 B3E6C1076D0D for ; Mon, 20 Aug 2018 17:47:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6658D793AB for ; Mon, 20 Aug 2018 17:47:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 040E523D50 for ; Mon, 20 Aug 2018 17:47:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f173.google.com with SMTP id l15-v6so12239688lji.6 for ; Mon, 20 Aug 2018 10:47:24 -0700 (PDT) X-Gm-Message-State: AOUpUlE5JrQGAHcCSGODDuN4aJUyJo41J/2KgNIONzj649ASNVw5imvY cCaBnnn7Ps+gvdFSmwDQ570gqg63u84TmC2KZ5w= X-Google-Smtp-Source: AA+uWPysrZSHnV1l7WOpU/bghU8xehOQs8OzzZHVawDJP2Frn8NklqdPTBPIcmiPw6YxcYR68aJ9bL0OSCcieSkSMUU= X-Received: by 2002:a2e:498:: with SMTP id a24-v6mr33336959ljf.27.1534787243518; Mon, 20 Aug 2018 10:47:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 10:47:02 -0700 (PDT) In-Reply-To: References: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> From: Kyle Evans Date: Mon, 20 Aug 2018 12:47:02 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA boot loader coming very soon To: Manfred Antar Cc: Warner Losh , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 17:47:25 -0000 On Mon, Aug 20, 2018 at 12:44 PM, Manfred Antar wr= ote: > > >> On Aug 20, 2018, at 9:20 AM, Warner Losh wrote: >> >> >> >> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans wrote: >> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar = wrote: >> > Hi >> > How do i get the menu back after switching to LUA loader? >> > I=E2=80=99m using a comconsole. Before the switch to LUA I had a menu = and a little devil with pitchfork:) >> > Now just get the countdown from 10 , then boot. >> > Here is my loader.conf.local: >> > >> > console=3D"comconsole" >> > beastie_disable=3D"NO" >> > hw.vga.textmode=3D1 >> > kern.vt.spclkeys=3D15 >> > nvidia_load=3D"YES" >> > linux_common_load=3D"YES" >> > linux_load=3D"YES" >> > linprocfs_load=3D"YES" >> > linsysfs_load=3D=E2=80=9CYES" >> > >> >> Hmm... seems that there was a miscommunication at some point, and the >> menu is disabled explicitly on serial boots. console=3D"comconsole" is >> enough to disable this in lualoader land. An excerpt from an e-mail I >> was forwarded regarding this: >> >> if $console contains (space or comma separated) "efi" then do >> not draw a menu (fall back to autoboot routine). >> >> if $beastie_disable is set to "YES" (case insensitive), then do not >> draw a menu (fall back to autoboot routine). >> >> We are clearly doing this wrong. I will fix it ASAP. >> >> I think that we need https://reviews.freebsd.org/D16816 to fix all the = bits. >> >> Warner > > Ok that works > I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, other= wise just have devilhead. > > drawer.default_color_logodef =3D 'orb' > drawer.default_bw_logodef =3D =E2=80=98orbbw' > > to: > > drawer.default_color_logodef =3D 'beastie' > drawer.default_bw_logodef =3D =E2=80=98beastiebw' > > and it=E2=80=99s pretty much the same as the 4th menu i had before. > Is there a way to put: > > drawer.default_color_logodef =3D 'beastie' > drawer.default_bw_logodef =3D 'beastiebw' > > somewhere else ie loader.rc or loader.lua.local so I don=E2=80=99t have t= o edit the /boot/lua/drawer.lua everytime I rebuild world? > It doesn=E2=80=99t work to put in loader.conf.local In loader.conf(5) land, this is called "loader_logo" e.g. loader_logo=3D"beastie" Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Mon Aug 20 17:50:35 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 C992B1076FD5 for ; Mon, 20 Aug 2018 17:50:35 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73A97964A; Mon, 20 Aug 2018 17:50:34 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: by mail-pg1-x529.google.com with SMTP id f14-v6so7128061pgv.13; Mon, 20 Aug 2018 10:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D8c6BGSKEhdLbsE59L0zYRkuNI6wNPL+MVMZtXRjkLc=; b=rU9gdf80GGm1YyxiPivtV2FbQ7m9VfOUMcZzcKL4o3lC7JZJJIQAIg3qRXWYDl+pQr 4bKedobXBI44Vp9xtwknlIjtDMXZHfekvBKxtQjVIwYwJsWG3E2MoanOFgNSNQBzCD37 UhDR7ViyvvYPk1xDcN8xR9XjcRA5+EMa+JX1+BYMWUC3K2YSe2MOQBXem7IMCX+oJlks 2MTczB7PAyM1VK8f0ks3w+uhRA4a4ZhXQZgm1BBU4cMaXVhhOhQey5rYDR9FQfpZwJBR rcAFWPZCX/x8M4xfnmh5nhF2Etj9y4d6DVrMhIk9Vb06EmOKG6JIo7TSTXyBbJr/0Syi N0Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D8c6BGSKEhdLbsE59L0zYRkuNI6wNPL+MVMZtXRjkLc=; b=cB+RvDb4k4Cqt8NEDmNELE/SfMnUdoOlXmAFqRgwNbDSme+cNgFOCUbW6NTuDqWBp1 UF7VtDMduQehAwqxnZJNJplzB6REXXWkuyBSX4rR6upYngdEQGTTGwBKKfZ112TxI5zP jWiJ/UlrH/ojP9BM3/NmgNRDkossr2vsWTKRo5ajNv5FtsVKlpTyPk5rzabaU9oPu6zk QCfJFuClV2WmE/y7HtJ4WrpgyUsT7oFeUxHYNX0p4WZAjAf5WVRit/yEkrxhn5GLPTeI i2KFuVCSRL3h8U9gqkmPOLs5Mkvn9qRBBM1BKIWRA+iRQhBzPSQWG6lpfsHpdrCU0Y7J vUWA== X-Gm-Message-State: AOUpUlEY/e4B07MdjsDE5LpjQ/VmjBRKBzuJxjmRKbTq8M+SCQIIJEcr Pw8uxQx10sd0kexcNCt0lCev5vM+LIVnjw== X-Google-Smtp-Source: AA+uWPyV80o4AjUKeKqWwJ4NrZ9w+mohygBUhTZwYqZfsHcjpXbqQA3YfXsIFT/YqpAPd56i8X/7sg== X-Received: by 2002:a62:591a:: with SMTP id n26-v6mr49451542pfb.94.1534787433914; Mon, 20 Aug 2018 10:50:33 -0700 (PDT) Received: from octo.pozo.com (50-197-129-138-static.hfc.comcastbusiness.net. [50.197.129.138]) by smtp.gmail.com with ESMTPSA id z22-v6sm17504897pgc.67.2018.08.20.10.50.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 10:50:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: LUA boot loader coming very soon From: Manfred Antar In-Reply-To: Date: Mon, 20 Aug 2018 10:50:32 -0700 Cc: Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <031D39D4-3890-4FEE-A968-541578E8F7A6@gmail.com> To: Kyle Evans X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 17:50:36 -0000 > On Aug 20, 2018, at 10:47 AM, Kyle Evans wrote: >=20 > On Mon, Aug 20, 2018 at 12:44 PM, Manfred Antar = wrote: >>=20 >>=20 >>> On Aug 20, 2018, at 9:20 AM, Warner Losh wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Aug 20, 2018 at 9:55 AM, Kyle Evans = wrote: >>> On Mon, Aug 20, 2018 at 10:39 AM, Manfred Antar = wrote: >>>> Hi >>>> How do i get the menu back after switching to LUA loader? >>>> I=E2=80=99m using a comconsole. Before the switch to LUA I had a = menu and a little devil with pitchfork:) >>>> Now just get the countdown from 10 , then boot. >>>> Here is my loader.conf.local: >>>>=20 >>>> console=3D"comconsole" >>>> beastie_disable=3D"NO" >>>> hw.vga.textmode=3D1 >>>> kern.vt.spclkeys=3D15 >>>> nvidia_load=3D"YES" >>>> linux_common_load=3D"YES" >>>> linux_load=3D"YES" >>>> linprocfs_load=3D"YES" >>>> linsysfs_load=3D=E2=80=9CYES" >>>>=20 >>>=20 >>> Hmm... seems that there was a miscommunication at some point, and = the >>> menu is disabled explicitly on serial boots. console=3D"comconsole" = is >>> enough to disable this in lualoader land. An excerpt from an e-mail = I >>> was forwarded regarding this: >>>=20 >>> if $console contains (space or comma separated) "efi" then do >>> not draw a menu (fall back to autoboot routine). >>>=20 >>> if $beastie_disable is set to "YES" (case insensitive), then do not >>> draw a menu (fall back to autoboot routine). >>>=20 >>> We are clearly doing this wrong. I will fix it ASAP. >>>=20 >>> I think that we need https://reviews.freebsd.org/D16816 to fix all = the bits. >>>=20 >>> Warner >>=20 >> Ok that works >> I had to edit /boot/lua/drawer.lua to get the devil-pitchfork back, = otherwise just have devilhead. >>=20 >> drawer.default_color_logodef =3D 'orb' >> drawer.default_bw_logodef =3D =E2=80=98orbbw' >>=20 >> to: >>=20 >> drawer.default_color_logodef =3D 'beastie' >> drawer.default_bw_logodef =3D =E2=80=98beastiebw' >>=20 >> and it=E2=80=99s pretty much the same as the 4th menu i had before. >> Is there a way to put: >>=20 >> drawer.default_color_logodef =3D 'beastie' >> drawer.default_bw_logodef =3D 'beastiebw' >>=20 >> somewhere else ie loader.rc or loader.lua.local so I don=E2=80=99t = have to edit the /boot/lua/drawer.lua everytime I rebuild world? >> It doesn=E2=80=99t work to put in loader.conf.local >=20 > In loader.conf(5) land, this is called "loader_logo" >=20 > e.g. loader_logo=3D=E2=80=9Cbeastie" I got it now. I was putting the wrong line in loader.conf.local loader_logo works!! Thanks From owner-freebsd-current@freebsd.org Mon Aug 20 18:30: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 83B3B107840E for ; Mon, 20 Aug 2018 18:30:52 +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 004B57AF7A; Mon, 20 Aug 2018 18:30:51 +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 w7KIV27h078871 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Aug 2018 11:31:03 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7KIV2lx078870; Mon, 20 Aug 2018 11:31:02 -0700 (PDT) (envelope-from fbsd) Date: Mon, 20 Aug 2018 11:31:02 -0700 From: bob prohaska To: Dimitry Andric Cc: "Rodney W. Grimes" , blubee blubeeme , FreeBSD Current , Brooks Davis , bob prohaska Subject: Re: building LLVM threads gets killed Message-ID: <20180820183101.GA76172@www.zefox.net> References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 18:30:52 -0000 On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote: > On 20 Aug 2018, at 16:26, Rodney W. Grimes wrote: > > > >> It is running out of RAM while running multiple parallel link jobs. If > >> you are building using WITH_DEBUG, turn that off, it consumes large > >> amounts of memory. If you must have debug info, try adding the > >> following flag to the CMake command line: > >> > >> -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > >> > >> That will limit the amount of parallel link jobs to 1, even if you > >> specify -j 8 to gmake or ninja. > >> > >> Brooks, it would not be a bad idea to always use this CMake flag in the > >> llvm ports. :) > > > > And this may also fix the issues that all the small > > memory (aka, RPI*) buliders are facing when trying > > to do -j4? > > Possibly, as linking is usually the most memory-consuming part of the > build process (and more so, if debugging is enabled). Are there build > logs available somewhere for those RPI builders? > There is a collection of RPI3 buildworld logs in http://www.zefox.net/~fbsd/rpi3/swaptests/ The more recent experiments are sorted by revision first, then swap config and then other modifications. If I can do anything to make the records more useful please let me know. hth, bob prohaska From owner-freebsd-current@freebsd.org Mon Aug 20 18:01: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 7DCC91077AD6 for ; Mon, 20 Aug 2018 18:01:40 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05FCC7A15A for ; Mon, 20 Aug 2018 18:01:39 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w7KI1bnr060299 for ; Mon, 20 Aug 2018 20:01:37 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 46C9C6DD for ; Mon, 20 Aug 2018 20:01:37 +0200 (CEST) To: FreeBSD Current From: Harry Schmalzbauer Subject: Loader post r338064 deletes GOP screen when asking geli passphrase Organization: OmniLAN Message-ID: <9061553f-89ca-ffb4-b1ed-ca7ca5bea83b@omnilan.de> Date: Mon, 20 Aug 2018 20:01:33 +0200 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-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: ACL 130 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Mon, 20 Aug 2018 20:01:37 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Mon, 20 Aug 2018 19:15:36 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 18:01:40 -0000 Hello, as far as I understand, r338064 should bring back default loader environment. I'm UEFI booting r338093/amd64 (LynxPoint/Haswell). Since today, the GOP-console output of the first loader lines get deleted when the geli passphrase prompt shows up. Nothing uncommon here, and never seen that before, but I guess this can be considered a bug. Or is that an intended behaviour? Thanks, -harry From owner-freebsd-current@freebsd.org Mon Aug 20 19:24:57 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 6A734107A11A for ; Mon, 20 Aug 2018 19:24:57 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB9787D731 for ; Mon, 20 Aug 2018 19:24:56 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([2.245.37.209]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0McVGq-1faIwY1KfA-00HeJl for ; Mon, 20 Aug 2018 21:24:54 +0200 Date: Mon, 20 Aug 2018 21:24:21 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools Message-ID: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:txbrttOpydjyPDBtpfyAGVCuqJ1+GDfMJMfUIuYDFy5/FgDBs2W N2j/Dq8LpKl+0UG4B229FpfAAYQdnDraMYXxK/nLwRb75VNewViTNE6tWMdVsjJjoqOcCXc VWWv+IscOccluiFMhwT1FQwuulolcLi+xdGVsM/WkaIM/4f2fGuSUa+DU6ZOUJ0pVWxqBdm nExdSYh+mf4P3DB4txtQw== X-UI-Out-Filterresults: notjunk:1;V01:K0:UMUNR0iQMwo=:q3Kk/LHRbHAAiGlMQicemR lMO0PNpHoJlJATc/2m1aWsaNcqVrizszSeKGE8GPBEZ6Gpyvq/9r84pF1t7wUIxeQ3vbJeu0K FJ4PMdHLfCu8smjMgye6kbuVXQYLBjNtIz+FNgm9wpWKRd81JaSVTF5sDA3gdvluy5mNcfUHY m5NEajeKpe4iAxUiExQ1574QdvWX0oI4vIsCiaassVgRkoLBQNEUU9beEcvDO/+GYUE3EE2IL RL9JRH6httZv1GKw+YKtm65MKz8FzwrytoJWbPqfu04/cmQT6y/j6tnOSmKQZSbwFcq1Kmnkx IB8o+wotib+EKaGQJjZEDyAtxJViKoo179c+F0HEuxdthH/OtVRi7pAp2uZBJDggTlZNCbrSD U+xXNxnZ0OKghk8vXU16O0V1sjlE5i/vaAhqCIqtYeFqFVMOnmdg7Z3MkTwVd64oFYDrF7GAD 8S+GHXZ4HoVok9akLXNvuT9JpYHY75hrdKPKaEHNpJYov/KbD+8r7UhBLPSWJqSjlq7F1uJ8/ alyyNeR9RaE4tdWrhoromt831IEq0piVkTNbo8NQPC5NmyD6E8EWoc4Qo36/s19Lz0/54+GJd 0eCsj0toKODRQnekcpra/IrtK0esr31uHWiLC8fGJZwjaNefcM7hWm+X3nQ+AiOTus83S9E13 2EzXlRwj8dsd3smu2VqrqP4AzCDpCJ6ezdwdi83qCWweeKZYCG/6neDrfOMG1kf5GvTuYWDup 1HwE45XtbfaxKM+9QERDeeGjHDuyBNLcvthMFLhcYu2ozpjGrgw+VRvWz0gpgCHbO/j+9oFZi H3CRAnn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 19:24:57 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkJ1aWxk aW5nIE5hbm9CU0Qgd29ybGQgb24gQ1VSUkVOVCByMzM4MTEzIGZhaWxzIGR1ZSB0bzoNCg0KWy4u Ll0NCmNkIC9wb29sL3NvdXJjZXMvQ1VSUkVOVC9zcmMvcmVzY3VlL3Jlc2N1ZS8uLi8uLi9zYmlu L2diZGUgJiYgIE1LX1RFU1RTPW5vDQpVUERBVEVfREVQRU5ERklMRT1ubyAgX1JFQ1VSU0lOR19D UlVOQ0g9MQ0KTUFLRU9CSkRJUlBSRUZJWD0vcG9vbC9uYW5vYnNkL2FtZDY0L0FMRVJJQ0hfYW1k NjQvcG9vbC9zb3VyY2VzL0NVUlJFTlQvc3JjL2FtZDY0LmFtZDY0L3Jlc2N1ZS9yZXNjdWUNCm1h a2UgIE1LX0FVVE9fT0JKPW5vICBESVJQUkZYPXJlc2N1ZS9yZXNjdWUvZ2JkZS8gLURSRVNDVUUg Q1JVTkNIX0NGTEFHUz0tRFJFU0NVRQ0KTUtfQVVUT19PQko9bm8gICBvYmogbWFrZVs1XTogIi9w b29sL3NvdXJjZXMvQ1VSUkVOVC9zcmMvdG9vbHMvYnVpbGQvbWsvTWFrZWZpbGUuYm9vdCINCmxp bmUgMTg6IERvIG5vdCBpbmNsdWRlICR7U1JDVE9QfS9zeXMgd2hlbiBidWlsZGluZyBib290c3Ry YXAgdG9vbHMuICBDb3B5IHRoZSBoZWFkZXIgdG8NCiR7V09STERUTVB9L2xlZ2FjeSBpbiB0b29s cy9idWlsZC9NYWtlZmlsZSBpbnN0ZWFkLiAgRXJyb3Igd2FzIGNhdXNlZCBieSBNYWtlZmlsZQ0K aW4gL3Bvb2wvc291cmNlcy9DVVJSRU5UL3NyYy9zYmluL2diZGUgKioqIFtvYmpfY3J1bmNoZGly X2diZGVdIEVycm9yIGNvZGUgMQ0KDQptYWtlWzRdOiBzdG9wcGVkIGluIC9wb29sL3NvdXJjZXMv Q1VSUkVOVC9zcmMvcmVzY3VlL3Jlc2N1ZQ0KWy4uLl0NCg0KDQpUaGlzIHByb2JsZW0gb2NjdXJl ZCBkdXJpbmcgdG9kYXkncyBzb3VyY2UgdXBkYXRlcyBzaW5jZSBJIHdhcyBhYmxlIHRvIGJ1aWxk IHRoZSBOYW5vQlNEDQppbWFnZSBJIGludGVuZCB0byBidWlsZCB5ZXN0ZXJkYXkgfiByMzM4MDYw Lg0KDQpXaGF0IGlzIGdvaW5nIHdyb25nPw0KDQpJJ3ZlIHNldCB0aGUgZm9sbG93aW5nIGZvciBO YW5vQlNEJ3MgYnVpbGQgYW5kIGluc3RhbGw6DQoNCiMgQlVJTERXT1JMRCBPTkxZDQojIE9wdGlv bnMgdG8gcHV0IGluIG1ha2UuY29uZiBkdXJpbmcgYnVpbGR3b3JsZCBvbmx5DQpDT05GX0JVSUxE PScNCkNGTEFHUz0tTzMgLXBpcGUNCk1BTExPQ19QUk9EVUNUSU9OPVlFUw0KSU5TVEFMTF9OT0RF QlVHPVlFUw0KJw0KIyBPcHRpb25zIHRvIHB1dCBpbiBtYWtlLmNvbmYgZHVyaW5nIGluc3RhbGx3 b3JsZCBvbmx5DQpDT05GX0lOU1RBTEw9Jw0KV0lUSE9VVF9UT09MQ0hBSU49WUVTDQpXSVRIT1VU X0NST1NTX0NPTVBJTEVSPVlFUw0KV0lUSE9VVF9ET0NDT01QUkVTUz1ZRVMNCldJVEhPVVRfSU5T VEFMTExJQj1ZRVMNCldJVEhPVVRfQklOVVRJTFM9WUVTDQojDQojV0lUSE9VVF9BQ0NUPVlFUw0K V0lUSE9VVF9BTUQ9WUVTDQpXSVRIT1VUX0FQTT1ZRVMNCldJVEhPVVRfQVNTRVJUX0RFQlVHPVlF Uw0KV0lUSE9VVF9BVD1ZRVMNCldJVEhPVVRfQVRNPVlFUw0KV0lUSE9VVF9CSFlWRT1ZRVMNCldJ VEhPVVRfQkxVRVRPT1RIPVlFUw0KV0lUSE9VVF9CT09UUEFSQU1EPVlFUw0KV0lUSE9VVF9CT09U UEQ9WUVTDQpXSVRIT1VUX0JTRElOU1RBTEw9WUVTDQojV0lUSE9VVF9CU0RfQ1BJTz1ZRVMNCiNX SVRIT1VUX0JTTk1QPVlFUw0KI1dJVEhPVVRfQlpJUDI9WUVTDQpXSVRIT1VUX0NBTEVOREFSPVlF Uw0KI1dJVEhPVVRfQ0NEPVlFUw0KV0lUSE9VVF9DRERMPVlFUw0KV0lUSE9VVF9DTEFOR19GVUxM PVlFUw0KV0lUSE9VVF9DVE09WUVTDQojV0lUSE9VVF9DVVNFPVlFUw0KV0lUSE9VVF9DWFg9WUVT DQpXSVRIT1VUX0RJQ1Q9WUVTDQpXSVRIT1VUX0RJQUxPRz1ZRVMNCldJVEhPVVRfRVhBTVBMRVM9 WUVTDQpXSVRIT1VUX0VFPVlFUw0KV0lUSE9VVF9GSU5HRVI9WUVTDQpXSVRIT1VUX0ZMT1BQWT1Z RVMNCldJVEhPVVRfRlJFRUJTRF9VUERBVEU9WUVTDQpXSVRIT1VUX0ZEVD1ZRVMNCldJVEhPVVRf R0FNRVM9WUVTDQpXSVRIT1VUX0dDT1Y9WUVTDQpXSVRIT1VUX0dEQj1ZRVMNCldJVEhPVVRfSEFT VD1ZRVMNCldJVEhPVVRfSFRNTD1ZRVMNCldJVEhPVVRfSFlQRVJWPVlFUw0KI1dJVEhPVVRfSU5F VDY9WUVTDQojV0lUSE9VVF9JTkVURD1ZRVMNCldJVEhPVVRfSVBGSUxURVI9WUVTDQpXSVRIT1VU X0lTQ1NJPVlFUw0KV0lUSE9VVF9LRFVNUD1ZRVMNCldJVEhPVVRfS0VSTkVMX1NZTUJPTFM9WUVT DQojV0lUSE9VVF9MRE5TPVlFUw0KV0lUSE9VVF9MT0NBVEU9WUVTDQpXSVRIT1VUX0xQUj1ZRVMN CiNXSVRIT1VUX01BSUw9WUVTDQojV0lUSE9VVF9NQUlMV1JBUFBFUj1ZRVMNCiNXSVRIT1VUX01B S0U9WUVTDQpXSVRIT1VUX01BTj1ZRVMNCldJVEhPVVRfTUFOX1VUSUxTPVlFUw0KV0lUSE9VVF9O RElTPVlFUw0KI1dJVEhPVVRfTkVUQ0FUPVlFUw0KI1dJVEhPVVRfTklTPVlFUw0KI1dJVEhPVVRf TkxTX0NBVEFMT0dTPVlFUw0KI1dJVEhPVVRfTlNfQ0FDSElORz1ZRVMNCldJVEhPVVRfTkFORD1Z RVMNCldJVEhPVVRfT0ZFRD1ZRVMNCldJVEhPVVRfUENfU1lTSU5TVEFMTD1ZRVMNCldJVEhPVVRf UEY9WUVTDQpXSVRIT1VUX1BLR0JPT1RTVFJBUD1ZRVMNCldJVEhPVVRfUE1DPVlFUw0KV0lUSE9V VF9QT1JUU05BUD1ZRVMNCiNXSVRIT1VUX1BQUD1ZRVMNCldJVEhPVVRfUVVPVEFTPVlFUw0KV0lU SE9VVF9SQk9PVEQ9WUVTDQpXSVRIT1VUX1JDTURTPVlFUw0KI1dJVEhPVVRfUkVTQ1VFPVlFUw0K I1dJVEhPVVRfUk9VVEVEPVlFUw0KI1dJVEhPVVRfU0VORE1BSUw9WUVTDQpXSVRIT1VUX1NIQVJF RE9DUz1ZRVMNCldJVEhPVVRfU1ZOTElURT1ZRVMNCldJVEhPVVRfVEFMSz1ZRVMNCiNXSVRIT1VU X1RDU0g9WUVTDQpXSVRIT1VUX1RFTE5FVD1ZRVMNCldJVEhPVVRfVEVYVFBST0M9WUVTDQpXSVRI T1VUX1RGVFA9WUVTDQojV0lUSE9VVF9XSVJFTEVTUz1ZRVMNCldJVEhPVVRfWkZTPVlFUw0KJw0K DQojIEJVSUxEIGFuZCBJTlNUQUxMIQ0KIyBPcHRpb25zIHRvIHB1dCBpbiBtYWtlLmNvbmYgZHVy aW5nIGJvdGggYnVpbGQtICYgaW5zdGFsbHdvcmxkLg0KIyBTZWUgbWFuIHNyYy5jb25mKDUpIGZv ciBtb3JlIGRldGFpbHMgb24gV0lUSE9VVF8gdGFncy4NCkNPTkZfV09STEQ9Jw0KV0lUSF9LRVJO RUxfUkVUUE9MSU5FPVlFUw0KV0lUSF9MTFZNX1RBUkdFVF9CUEY9WUVTDQpXSVRIT1VUX1RFU1RT PVlFUw0KV0lUSE9VVF9URVNUU19TVVBQT1JUPVlFUw0KV0lUSE9VVF9BU1NFUlRfREVCVUc9WUVT DQpXSVRIT1VUX0NDRD1ZRVMNCiNXSVRIT1VUX0JJTlVUSUxTX0JPT1RTVFJBUD1ZRVMNCldJVEhP VVRfREVCVUdfRklMRVM9WUVTDQojV0lUSE9VVF9JQ09OVj1ZRVMNCldJVEhPVVRfSVNDU0k9WUVT DQpXSVRIT1VUX0xJQjMyPVlFUw0KI1dJVEhPVVRfTExWTV9UQVJHRVRfQUxMPVlFUw0KV0lUSF9a T05FSU5GT19MRUFQU0VDT05EU19TVVBQT1JUPVlFUw0KV0lUSE9VVF9TVk49WUVTDQpXSVRIX1NP UlRfVEhSRUFEUz1ZRVMNCldJVEhfRVhUUkFfVENQX1NUQUNLUz1ZRVMNCiMNCklOU1RBTExfTk9E RUJVRz1ZRVMNCicNCg0KDQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lkZXJzcHJlY2hl IGRlciBOdXR6dW5nIG9kZXIgw5xiZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8cg0KV2VyYmV6 d2Vja2Ugb2RlciBmw7xyIGRpZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAowqcgMjgg QWJzLiA0IEJEU0cpLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaUxVRUFSTUtB QjBXSVFRWlZaTXpBdHdDMlQvODZUclM1MjhmeUZoWWxBVUNXM3NWZ0FBS0NSRFM1MjhmeUZoWQ0K bEw0TUFnQ2FTOFVlRTZGd0pJZVVhNVErOWhmODBESmtkZStvb3B0dElMMkp6OUxjYk4xQ1JVNUpU YzJqSjlWYg0Kdk8zODBSVlROTzRNMEdlME0wbTJ3REN4NHh6dUFmOVlZZGpXL3hUWGJoMDlZY1Rs dDNsMjJwbjFhYUhZcmRNaw0KcE9ZQTNGVXc4eGkwOWNuaXlRSEJPcjRtdmpLSTA3R3RnTEtURUlO VTNTdVM5Q21GakN6Zw0KPXZGUCsNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Mon Aug 20 19:35: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 51C6C107A76E for ; Mon, 20 Aug 2018 19:35:39 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06FF17DF68 for ; Mon, 20 Aug 2018 19:35:39 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 97C082485A for ; Mon, 20 Aug 2018 19:35:38 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f177.google.com with SMTP id u7-v6so12515759lji.3 for ; Mon, 20 Aug 2018 12:35:38 -0700 (PDT) X-Gm-Message-State: AOUpUlFnG382AHcgnX13MNogp2KGwVtMJ9Jc+WQ+gLHiulyDQ5VAD9F2 +osknDAJryMlSuFdoLJinwPpTna2nK/Z2CGfLVk= X-Google-Smtp-Source: AA+uWPx+fvzWg0OoiU9O2Ps5OOeHpKp2ODmlXaXxAr+SnxE4RmXOFmacxjrja5xJfswOW1CCXYuSB+46xtjPX+hABN0= X-Received: by 2002:a2e:498:: with SMTP id a24-v6mr33560461ljf.27.1534793737231; Mon, 20 Aug 2018 12:35:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:91d2:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 12:35:16 -0700 (PDT) In-Reply-To: <9061553f-89ca-ffb4-b1ed-ca7ca5bea83b@omnilan.de> References: <9061553f-89ca-ffb4-b1ed-ca7ca5bea83b@omnilan.de> From: Kyle Evans Date: Mon, 20 Aug 2018 14:35:16 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Loader post r338064 deletes GOP screen when asking geli passphrase To: Harry Schmalzbauer Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 19:35:39 -0000 On Mon, Aug 20, 2018 at 1:01 PM, Harry Schmalzbauer wrote: > Hello, > > as far as I understand, r338064 should bring back default loader > environment. > > I'm UEFI booting r338093/amd64 (LynxPoint/Haswell). > > Since today, the GOP-console output of the first loader lines get deleted > when the geli passphrase prompt shows up. > > Nothing uncommon here, and never seen that before, but I guess this can be > considered a bug. > Or is that an intended behaviour? > It is intended behavior, but I won't claim that it isn't a bug. =) I *think* I added the screen clear prior to going into the passphrase prompt because the cursor position was ending up all wrong and it the passphrase prompt was obscured by lots of noisy text that it ended up drawing in the middle of. I'm certainly willing to go back on that position if there turns out to be a better solution, one of which I think I see. Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Mon Aug 20 19:35: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 C640F107A777; Mon, 20 Aug 2018 19:35:39 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 397357DF6A; Mon, 20 Aug 2018 19:35:39 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id w7KJeu29072094; Mon, 20 Aug 2018 12:40:56 -0700 (PDT) (envelope-from mckusick@mckusick.com) Message-Id: <201808201940.w7KJeu29072094@chez.mckusick.com> From: Kirk McKusick To: FreeBSD Current , FreeBSD Filesystems Subject: CFT: TRIM Consolodation on UFS/FFS filesystems X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick MIME-Version: 1.0 Content-ID: <71992.1534793715.0@chez.mckusick.com> Date: Mon, 20 Aug 2018 12:40:56 -0700 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Mailman-Approved-At: Mon, 20 Aug 2018 19:45:53 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 19:35:40 -0000 I have recently added TRIM consolodation support for the UFS/FFS filesystem. This feature consolodates large numbers of TRIM commands into a much smaller number of commands covering larger blocks of disk space. Best described by the commit message: Author: mckusick Date: Sun Aug 19 16:56:42 2018 New Revision: 338056 URL: https://svnweb.freebsd.org/changeset/base/338056 Log: Add consolodation of TRIM / BIO_DELETE commands to the UFS/FFS filesys= tem. = When deleting files on filesystems that are stored on flash-memory (solid-state) disk drives, the filesystem notifies the underlying disk of the blocks that it is no longer using. The notification allows the drive to avoid saving these blocks when it needs to flash (zero out) one of its flash pages. These notifications of no-longer-being-used blocks are referred to as TRIM notifications. In FreeBSD these TRIM notifications are sent from the filesystem to the drive using the BIO_DELETE command. = Until now, the filesystem would send a separate message to the drive for each block of the file that was deleted. Each Gigabyte of file size resulted in over 3000 TRIM messages being sent to the drive. This burst of messages can overwhelm the drive's task queue causing multiple second delays for read and write requests. = This implementation collects runs of contiguous blocks in the file and then consolodates them into a single BIO_DELETE command to the drive. The BIO_DELETE command describes the run of blocks as a single large block being deleted. Each Gigabyte of file size can result in as few as two BIO_DELETE commands and is typically less than ten. Though these larger BIO_DELETE commands take longer to run, they do not clog the drive task queue, so read and write commands can intersperse effectively with them. = Though this new feature has been throughly reviewed and tested, it is being added disabled by default so as to minimize the possibility of disrupting the upcoming 12.0 release. It can be enabled by running ``sysctl vfs.ffs.dotrimcons=3D1''. Users are encouraged to test it. If no problems arise, we will consider requesting that it be enabled by default for 12.0. = Reviewed by: kib Tested by: Peter Holm Sponsored by: Netflix This support is off by default, but I am hoping that I can get enough testing to ensure that it (a) works, and (b) is helpful that it will be reasonable to have it turned on by default in 12.0. The cutoff for turning it on by default in 12.0 is September 19th. So I am requesting your testing feedback in the near-term. Please let me know if you have managed to use it successfully (or not) and also if it provided any performance difference (good or bad). To enable TRIM consolodation either use `sysctl vfs.ffs.dotrimcons=3D1' or just set the `dotrimcons' variable in sys/ufs/ffs/ffs_alloc.c to 1. Everything you need to test TRIM consolodation is obtained by setting the above sysctl. However, if you want to collect statistics on how effective the TRIM consolodation is working, the attached diff will allow you to easily get statitics on how the TRIM is going. Compile your kernel and the mount command. Note that if you do not do a buildworld, you will need to copy /sys/sys/mount.h to /usr/include/sys/mount.h to get the patched mount command to compile. Then run `mount -v' (or `mount -v | grep /mnt' to get just the statistics for /mnt). Removing a 30Mb file without TRIM consolodation: /dev/md0 on /mnt (ufs, local, writes: sync 10 async 482, reads: sync 7 asy= nc 0, fsid d43f795b6a7d34fb, TRIM: total 952 total blocks 7616) While removing the same file with TRIM consolodation: /dev/md0 on /mnt (ufs, local, writes: sync 10 async 482, reads: sync 7 asy= nc 0, fsid d43f795b6a7d34fb, TRIM: total 3 total blocks 7616) It also tracks pending blocks and pending files. These numbers are only printed out when they are non-zero. Here is an example running with soft updates right after a file has been rm'ed, but its blocks not yet released= : /dev/md0 on /mnt (ufs, local, soft-updates, writes: sync 2 async 251, read= s: sync 5 async 0, fsid 303f795b1be0c459, pending blocks 7616, pending fil= es 1) Finally it tracks inflight BIO_DELETEs and total blocks represented by those inflight BIO_DELETEs. These numbers are also only printed out when they are non-zero. These statistics let you see how much of a backlog of BIO_DELETEs you have backed up at/in the disk drive and you can track how quickly they drain. Kirk McKusick From owner-freebsd-current@freebsd.org Mon Aug 20 19:53: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 C8246107AF42; Mon, 20 Aug 2018 19:53:46 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 56F9F7F2A4; Mon, 20 Aug 2018 19:53:46 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id w7KJx3iK072721; Mon, 20 Aug 2018 12:59:03 -0700 (PDT) (envelope-from mckusick@mckusick.com) Message-Id: <201808201959.w7KJx3iK072721@chez.mckusick.com> From: Kirk McKusick To: FreeBSD Current , FreeBSD Filesystems Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: <201808201940.w7KJeu29072094@chez.mckusick.com> Comments: In-reply-to Kirk McKusick message dated "Mon, 20 Aug 2018 12:40:56 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72719.1534795143.1@chez.mckusick.com> Date: Mon, 20 Aug 2018 12:59:03 -0700 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com X-Mailman-Approved-At: Mon, 20 Aug 2018 20:44:40 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 19:53:47 -0000 From: Kirk McKusick To: FreeBSD Current , FreeBSD Filesystems Subject: CFT: TRIM Consolodation on UFS/FFS filesystems Date: Mon, 20 Aug 2018 12:40:56 -0700 Oops, forgot that attachments get stripped. Below are the diffs for gathering statistics. Sorry to those of you on Gmail for whom they will be mangled. Kirk McKusick =-=-= Index: sbin/mount/mount.c =================================================================== --- sbin/mount/mount.c (revision 338054) +++ sbin/mount/mount.c (working copy) @@ -686,6 +686,18 @@ prmount(struct statfs *sfp) for (i = 0; i < sizeof(sfp->f_fsid); i++) printf("%02x", ((u_char *)&sfp->f_fsid)[i]); } + if (sfp->f_trim_total != 0 || sfp->f_trim_total_blks != 0) + (void)printf(", TRIM: total %ju total blocks %ju", + (uintmax_t)sfp->f_trim_total, + (uintmax_t)sfp->f_trim_total_blks); + if (sfp->f_trim_inflight != 0 || sfp->f_trim_inflight_blks != 0) + (void)printf(", TRIM: inflight %ju inflight blocks %ju", + (uintmax_t)sfp->f_trim_inflight, + (uintmax_t)sfp->f_trim_inflight_blks); + if (sfp->f_pendingblks != 0 || sfp->f_pendingfiles != 0) + (void)printf(", pending blocks %ju, pending files %ju", + (uintmax_t)sfp->f_pendingblks, + (uintmax_t)sfp->f_pendingfiles); } (void)printf(")\n"); } Index: sys/sys/mount.h =================================================================== --- sys/sys/mount.h (revision 338054) +++ sys/sys/mount.h (working copy) @@ -85,7 +85,13 @@ struct statfs { uint64_t f_asyncwrites; /* count of async writes since mount */ uint64_t f_syncreads; /* count of sync reads since mount */ uint64_t f_asyncreads; /* count of async reads since mount */ - uint64_t f_spare[10]; /* unused spare */ + uint64_t f_trim_total; /* count of TRIM ops since mount */ + uint64_t f_trim_total_blks; /* count of TRIM blocks since mount */ + uint64_t f_trim_inflight; /* count of TRIM ops in progress */ + uint64_t f_trim_inflight_blks; /* count of TRIM blocks in progress */ + int64_t f_pendingblks; /* pending free blocks */ + int64_t f_pendingfiles; /* pending free nodes */ + uint64_t f_spare[4]; /* unused spare */ uint32_t f_namemax; /* maximum filename length */ uid_t f_owner; /* user that mounted the filesystem */ fsid_t f_fsid; /* filesystem id */ Index: sys/ufs/ffs/ffs_vfsops.c =================================================================== --- sys/ufs/ffs/ffs_vfsops.c (revision 338081) +++ sys/ufs/ffs/ffs_vfsops.c (working copy) @@ -1398,7 +1398,13 @@ ffs_statfs(mp, sbp) sbp->f_bsize = fs->fs_fsize; sbp->f_iosize = fs->fs_bsize; sbp->f_blocks = fs->fs_dsize; + sbp->f_pendingblks = dbtofsb(fs, fs->fs_pendingblocks); + sbp->f_pendingfiles = fs->fs_pendinginodes; UFS_LOCK(ump); + sbp->f_trim_total = ump->um_trim_total; + sbp->f_trim_total_blks = ump->um_trim_total_blks; + sbp->f_trim_inflight = ump->um_trim_inflight; + sbp->f_trim_inflight_blks = ump->um_trim_inflight_blks; sbp->f_bfree = fs->fs_cstotal.cs_nbfree * fs->fs_frag + fs->fs_cstotal.cs_nffree + dbtofsb(fs, fs->fs_pendingblocks); sbp->f_bavail = freespace(fs, fs->fs_minfree) + From owner-freebsd-current@freebsd.org Mon Aug 20 21:27:27 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 2B122107DA00 for ; Mon, 20 Aug 2018 21:27:27 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from mail.codexterous.com (mail.codexterous.com [104.156.251.179]) (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 D09AA82A74; Mon, 20 Aug 2018 21:27:26 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from [10.0.0.100] (pool-108-54-155-10.nycmny.fios.verizon.net [108.54.155.10]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bgmoser@codexterous.com) by mail.codexterous.com (Postfix) with ESMTPSA id E81356884E7; Mon, 20 Aug 2018 17:27:19 -0400 (EDT) To: freebsd-current@freebsd.org, imp@freebsd.org From: Brett Gmoser Subject: Newly upgraded -CURRENT box does not boot Message-ID: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> Date: Mon, 20 Aug 2018 17:27:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 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.27 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, 20 Aug 2018 21:27:27 -0000 Hi there, I was told to e-mail these addresses with this. I did an `svn update` on /usr/src last night, build world and kernel as usual. This morning I installed the kernel, booted into single user, installed world and did mergemaster -Ui as usual. The new kernel had booted fine. Upon reboot, the machine will no longer boot:     Startup error in /boot/lua/loader.lua:     LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory     can't load 'kernel' Many things in the bootloader do not work, including "boot kernel.old", "ls /boot", and various other things (most if not all just result in "Command failed"). Interestingly, "ls /mnt" works, other directories do not. That's the only clue I have. I'm able to reboot in an installer image and mount the drive just fine. Everything is there and is as expected, including /boot/lua/loader.lua. I re-installed everything in /usr/src/stand (chroot'd on the installer image, and "cd /usr/src/stand && make clean all install"). This did not fix the problem. Does anybody happen to have any ideas? Thanks, -Brett From owner-freebsd-current@freebsd.org Mon Aug 20 20:01: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 84817107B122 for ; Mon, 20 Aug 2018 20:01:13 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F37077F6AB for ; Mon, 20 Aug 2018 20:01:12 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([2.245.37.209]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LaaVn-1gGTXz2VHb-00mIpS for ; Mon, 20 Aug 2018 22:01:04 +0200 Date: Mon, 20 Aug 2018 22:00:36 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools Message-ID: <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:duOmZY72mzj3OeCEIkBZrv8MeocFWI+RRKvL9cuhRozsuIIiMwc X0RbhbRV6r8lU+isMBiCvfwwmWxjbO7GZWzswaH/2XTBoaIIxq8r2/WiURtoRg6uElxiR69 Gk9RfXbB2fw4DcABToH63hSV3ES10XyfQvH+uU737cPNt+gSmtEVVoF/na81/73cyR7GWtl WjmhhXZqLIrhnJdJEsdVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZMYCinqVx/w=:14G8x3OueciZNgJshN9Mtc LHn36JfIzQrEFvqZzklos/RQhkNCwcVPRX3gfs8PBudBbLc3MtnDhXoFdW4thqi9JgRVi+I8q Q5lgFWCL5cei4xvH3oIACC5xnWW3majfUK6MFMmHc1JEYOWg6sByWBeDCR+QyytodIu0pjze7 QpNqtIV6M556a1Q60vbmm9SzAwVKzpRU4wmtnX5by8WA8Cchs3o0sHHm3pdF/kECO8H2td7VL +o5QWB0zOsqTeRMI+y6zXB29L+hiQTwHQCM4uo7Eugc0gHfceWCTSsImup2nRBEuiUblvKsm0 kn/Zm6URvqF37tzdjOlW9blflunh78jT4mVK/amEPmqCUj5pkbsOWvfPmJ0oVm3ye6hEC+fQo 0UZNIBCTBM7iWA5NxoHZXe10DNf8DY7XuZ8mW3uyxQglSESzAS9exC4iUHVX9yA/CRu25PqcT oc2P8OuGlK0ZFPlBUwB04lUCZuzWARpHB4DcYIQh+cen1pqA6X5wMcsFF4Ng+HlziT16LZM69 FZb65dkVnI8sqbrT+twOIscKijMss+VQBBaqFqAPcLpdww7Ji8lYRsisbQ8/61q/8mbTsVhO/ AXma/bF3LndtjVhClJru/0RtbfDESg8MEyhfY48Ln6a/N2GNHXiJPga8fGAvQtWYY5p/uCUB9 y4wf09DKEf13B1ERSRUYiwMUuKJWBK6urNB9tY5zARqC+GWA427AHb9qyf7yCnlUbqllODBxv FRsYXPqijOQw/yofwH8Zw37YoUxzrDRcC/ntAKU1k5evh8EfiFJnMn8aeGVMxqgGOZkkbwnxQ VkG1EZw X-Mailman-Approved-At: Mon, 20 Aug 2018 21:41:23 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 20:01:13 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIE1v biwgMjAgQXVnIDIwMTggMjE6MjQ6MjEgKzAyMDANCiJPLiBIYXJ0bWFubiIgPG9oYXJ0bWFubkB3 YWxzdGF0dC5vcmc+IHNjaHJpZWI6DQoNCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0Ut LS0tLQ0KPiBIYXNoOiBTSEE1MTINCj4gDQo+IEJ1aWxkaW5nIE5hbm9CU0Qgd29ybGQgb24gQ1VS UkVOVCByMzM4MTEzIGZhaWxzIGR1ZSB0bzoNCj4gDQo+IFsuLi5dDQo+IGNkIC9wb29sL3NvdXJj ZXMvQ1VSUkVOVC9zcmMvcmVzY3VlL3Jlc2N1ZS8uLi8uLi9zYmluL2diZGUgJiYgIE1LX1RFU1RT PW5vDQo+IFVQREFURV9ERVBFTkRGSUxFPW5vICBfUkVDVVJTSU5HX0NSVU5DSD0xDQo+IE1BS0VP QkpESVJQUkVGSVg9L3Bvb2wvbmFub2JzZC9hbWQ2NC9BTEVSSUNIX2FtZDY0L3Bvb2wvc291cmNl cy9DVVJSRU5UL3NyYy9hbWQ2NC5hbWQ2NC9yZXNjdWUvcmVzY3VlDQo+IG1ha2UgIE1LX0FVVE9f T0JKPW5vICBESVJQUkZYPXJlc2N1ZS9yZXNjdWUvZ2JkZS8gLURSRVNDVUUgQ1JVTkNIX0NGTEFH Uz0tRFJFU0NVRQ0KPiBNS19BVVRPX09CSj1ubyAgIG9iaiBtYWtlWzVdOiAiL3Bvb2wvc291cmNl cy9DVVJSRU5UL3NyYy90b29scy9idWlsZC9tay9NYWtlZmlsZS5ib290Ig0KPiBsaW5lIDE4OiBE byBub3QgaW5jbHVkZSAke1NSQ1RPUH0vc3lzIHdoZW4gYnVpbGRpbmcgYm9vdHN0cmFwIHRvb2xz LiAgQ29weSB0aGUgaGVhZGVyIHRvDQo+ICR7V09STERUTVB9L2xlZ2FjeSBpbiB0b29scy9idWls ZC9NYWtlZmlsZSBpbnN0ZWFkLiAgRXJyb3Igd2FzIGNhdXNlZCBieSBNYWtlZmlsZQ0KPiBpbiAv cG9vbC9zb3VyY2VzL0NVUlJFTlQvc3JjL3NiaW4vZ2JkZSAqKiogW29ial9jcnVuY2hkaXJfZ2Jk ZV0gRXJyb3IgY29kZSAxDQo+IA0KPiBtYWtlWzRdOiBzdG9wcGVkIGluIC9wb29sL3NvdXJjZXMv Q1VSUkVOVC9zcmMvcmVzY3VlL3Jlc2N1ZQ0KPiBbLi4uXQ0KPiANCj4gDQo+IFRoaXMgcHJvYmxl bSBvY2N1cmVkIGR1cmluZyB0b2RheSdzIHNvdXJjZSB1cGRhdGVzIHNpbmNlIEkgd2FzIGFibGUg dG8gYnVpbGQgdGhlIE5hbm9CU0QNCj4gaW1hZ2UgSSBpbnRlbmQgdG8gYnVpbGQgeWVzdGVyZGF5 IH4gcjMzODA2MC4NCj4gDQo+IFdoYXQgaXMgZ29pbmcgd3Jvbmc/DQoNCkl0IHNlZW1zIHRoZSBw cm9ibGVtIGhhcyBiZWVuIGludHJvZHVjZWQgYWZ0ZXIgcjMzODA5NSwgc2luY2UgcjMzODA5NSBi dWlsZHMgb2ssIHdoaWxlDQpyMzM4MDk2IGRvZXNuJ3QuDQoNCj4gDQo+IEkndmUgc2V0IHRoZSBm b2xsb3dpbmcgZm9yIE5hbm9CU0QncyBidWlsZCBhbmQgaW5zdGFsbDoNCj4gDQo+ICMgQlVJTERX T1JMRCBPTkxZDQo+ICMgT3B0aW9ucyB0byBwdXQgaW4gbWFrZS5jb25mIGR1cmluZyBidWlsZHdv cmxkIG9ubHkNCj4gQ09ORl9CVUlMRD0nDQo+IENGTEFHUz0tTzMgLXBpcGUNCj4gTUFMTE9DX1BS T0RVQ1RJT049WUVTDQo+IElOU1RBTExfTk9ERUJVRz1ZRVMNCj4gJw0KPiAjIE9wdGlvbnMgdG8g cHV0IGluIG1ha2UuY29uZiBkdXJpbmcgaW5zdGFsbHdvcmxkIG9ubHkNCj4gQ09ORl9JTlNUQUxM PScNCj4gV0lUSE9VVF9UT09MQ0hBSU49WUVTDQo+IFdJVEhPVVRfQ1JPU1NfQ09NUElMRVI9WUVT DQo+IFdJVEhPVVRfRE9DQ09NUFJFU1M9WUVTDQo+IFdJVEhPVVRfSU5TVEFMTExJQj1ZRVMNCj4g V0lUSE9VVF9CSU5VVElMUz1ZRVMNCj4gIw0KPiAjV0lUSE9VVF9BQ0NUPVlFUw0KPiBXSVRIT1VU X0FNRD1ZRVMNCj4gV0lUSE9VVF9BUE09WUVTDQo+IFdJVEhPVVRfQVNTRVJUX0RFQlVHPVlFUw0K PiBXSVRIT1VUX0FUPVlFUw0KPiBXSVRIT1VUX0FUTT1ZRVMNCj4gV0lUSE9VVF9CSFlWRT1ZRVMN Cj4gV0lUSE9VVF9CTFVFVE9PVEg9WUVTDQo+IFdJVEhPVVRfQk9PVFBBUkFNRD1ZRVMNCj4gV0lU SE9VVF9CT09UUEQ9WUVTDQo+IFdJVEhPVVRfQlNESU5TVEFMTD1ZRVMNCj4gI1dJVEhPVVRfQlNE X0NQSU89WUVTDQo+ICNXSVRIT1VUX0JTTk1QPVlFUw0KPiAjV0lUSE9VVF9CWklQMj1ZRVMNCj4g V0lUSE9VVF9DQUxFTkRBUj1ZRVMNCj4gI1dJVEhPVVRfQ0NEPVlFUw0KPiBXSVRIT1VUX0NEREw9 WUVTDQo+IFdJVEhPVVRfQ0xBTkdfRlVMTD1ZRVMNCj4gV0lUSE9VVF9DVE09WUVTDQo+ICNXSVRI T1VUX0NVU0U9WUVTDQo+IFdJVEhPVVRfQ1hYPVlFUw0KPiBXSVRIT1VUX0RJQ1Q9WUVTDQo+IFdJ VEhPVVRfRElBTE9HPVlFUw0KPiBXSVRIT1VUX0VYQU1QTEVTPVlFUw0KPiBXSVRIT1VUX0VFPVlF Uw0KPiBXSVRIT1VUX0ZJTkdFUj1ZRVMNCj4gV0lUSE9VVF9GTE9QUFk9WUVTDQo+IFdJVEhPVVRf RlJFRUJTRF9VUERBVEU9WUVTDQo+IFdJVEhPVVRfRkRUPVlFUw0KPiBXSVRIT1VUX0dBTUVTPVlF Uw0KPiBXSVRIT1VUX0dDT1Y9WUVTDQo+IFdJVEhPVVRfR0RCPVlFUw0KPiBXSVRIT1VUX0hBU1Q9 WUVTDQo+IFdJVEhPVVRfSFRNTD1ZRVMNCj4gV0lUSE9VVF9IWVBFUlY9WUVTDQo+ICNXSVRIT1VU X0lORVQ2PVlFUw0KPiAjV0lUSE9VVF9JTkVURD1ZRVMNCj4gV0lUSE9VVF9JUEZJTFRFUj1ZRVMN Cj4gV0lUSE9VVF9JU0NTST1ZRVMNCj4gV0lUSE9VVF9LRFVNUD1ZRVMNCj4gV0lUSE9VVF9LRVJO RUxfU1lNQk9MUz1ZRVMNCj4gI1dJVEhPVVRfTEROUz1ZRVMNCj4gV0lUSE9VVF9MT0NBVEU9WUVT DQo+IFdJVEhPVVRfTFBSPVlFUw0KPiAjV0lUSE9VVF9NQUlMPVlFUw0KPiAjV0lUSE9VVF9NQUlM V1JBUFBFUj1ZRVMNCj4gI1dJVEhPVVRfTUFLRT1ZRVMNCj4gV0lUSE9VVF9NQU49WUVTDQo+IFdJ VEhPVVRfTUFOX1VUSUxTPVlFUw0KPiBXSVRIT1VUX05ESVM9WUVTDQo+ICNXSVRIT1VUX05FVENB VD1ZRVMNCj4gI1dJVEhPVVRfTklTPVlFUw0KPiAjV0lUSE9VVF9OTFNfQ0FUQUxPR1M9WUVTDQo+ ICNXSVRIT1VUX05TX0NBQ0hJTkc9WUVTDQo+IFdJVEhPVVRfTkFORD1ZRVMNCj4gV0lUSE9VVF9P RkVEPVlFUw0KPiBXSVRIT1VUX1BDX1NZU0lOU1RBTEw9WUVTDQo+IFdJVEhPVVRfUEY9WUVTDQo+ IFdJVEhPVVRfUEtHQk9PVFNUUkFQPVlFUw0KPiBXSVRIT1VUX1BNQz1ZRVMNCj4gV0lUSE9VVF9Q T1JUU05BUD1ZRVMNCj4gI1dJVEhPVVRfUFBQPVlFUw0KPiBXSVRIT1VUX1FVT1RBUz1ZRVMNCj4g V0lUSE9VVF9SQk9PVEQ9WUVTDQo+IFdJVEhPVVRfUkNNRFM9WUVTDQo+ICNXSVRIT1VUX1JFU0NV RT1ZRVMNCj4gI1dJVEhPVVRfUk9VVEVEPVlFUw0KPiAjV0lUSE9VVF9TRU5ETUFJTD1ZRVMNCj4g V0lUSE9VVF9TSEFSRURPQ1M9WUVTDQo+IFdJVEhPVVRfU1ZOTElURT1ZRVMNCj4gV0lUSE9VVF9U QUxLPVlFUw0KPiAjV0lUSE9VVF9UQ1NIPVlFUw0KPiBXSVRIT1VUX1RFTE5FVD1ZRVMNCj4gV0lU SE9VVF9URVhUUFJPQz1ZRVMNCj4gV0lUSE9VVF9URlRQPVlFUw0KPiAjV0lUSE9VVF9XSVJFTEVT Uz1ZRVMNCj4gV0lUSE9VVF9aRlM9WUVTDQo+ICcNCj4gDQo+ICMgQlVJTEQgYW5kIElOU1RBTEwh DQo+ICMgT3B0aW9ucyB0byBwdXQgaW4gbWFrZS5jb25mIGR1cmluZyBib3RoIGJ1aWxkLSAmIGlu c3RhbGx3b3JsZC4NCj4gIyBTZWUgbWFuIHNyYy5jb25mKDUpIGZvciBtb3JlIGRldGFpbHMgb24g V0lUSE9VVF8gdGFncy4NCj4gQ09ORl9XT1JMRD0nDQo+IFdJVEhfS0VSTkVMX1JFVFBPTElORT1Z RVMNCj4gV0lUSF9MTFZNX1RBUkdFVF9CUEY9WUVTDQo+IFdJVEhPVVRfVEVTVFM9WUVTDQo+IFdJ VEhPVVRfVEVTVFNfU1VQUE9SVD1ZRVMNCj4gV0lUSE9VVF9BU1NFUlRfREVCVUc9WUVTDQo+IFdJ VEhPVVRfQ0NEPVlFUw0KPiAjV0lUSE9VVF9CSU5VVElMU19CT09UU1RSQVA9WUVTDQo+IFdJVEhP VVRfREVCVUdfRklMRVM9WUVTDQo+ICNXSVRIT1VUX0lDT05WPVlFUw0KPiBXSVRIT1VUX0lTQ1NJ PVlFUw0KPiBXSVRIT1VUX0xJQjMyPVlFUw0KPiAjV0lUSE9VVF9MTFZNX1RBUkdFVF9BTEw9WUVT DQo+IFdJVEhfWk9ORUlORk9fTEVBUFNFQ09ORFNfU1VQUE9SVD1ZRVMNCj4gV0lUSE9VVF9TVk49 WUVTDQo+IFdJVEhfU09SVF9USFJFQURTPVlFUw0KPiBXSVRIX0VYVFJBX1RDUF9TVEFDS1M9WUVT DQo+ICMNCj4gSU5TVEFMTF9OT0RFQlVHPVlFUw0KPiAnDQo+IA0KPiANCj4gDQo+IC0gLS0gDQo+ IE8uIEhhcnRtYW5uDQo+IA0KPiBJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9kZXIgw5xi ZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8cg0KPiBXZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGll IE1hcmt0LSBvZGVyIE1laW51bmdzZm9yc2NodW5nICjCpyAyOCBBYnMuIDQgQkRTRykuDQo+IC0t LS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IA0KPiBpTFVFQVJNS0FCMFdJUVFaVlpNekF0 d0MyVC84NlRyUzUyOGZ5RmhZbEFVQ1czc1ZnQUFLQ1JEUzUyOGZ5RmhZDQo+IGxMNE1BZ0NhUzhV ZUU2RndKSWVVYTVRKzloZjgwREprZGUrb29wdHRJTDJKejlMY2JOMUNSVTVKVGMyako5VmINCj4g dk8zODBSVlROTzRNMEdlME0wbTJ3REN4NHh6dUFmOVlZZGpXL3hUWGJoMDlZY1RsdDNsMjJwbjFh YUhZcmRNaw0KPiBwT1lBM0ZVdzh4aTA5Y25peVFIQk9yNG12aktJMDdHdGdMS1RFSU5VM1N1UzlD bUZqQ3pnDQo+ID12RlArDQo+IC0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLWN1cnJl bnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQNCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg0K DQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9k ZXIgw5xiZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8cg0KV2VyYmV6d2Vja2Ugb2RlciBmw7xy IGRpZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAowqcgMjggQWJzLiA0IEJEU0cpLg0K LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KaUxVRUFSTUtBQjBXSVFRWlZaTXpBdHdD MlQvODZUclM1MjhmeUZoWWxBVUNXM3NkL3dBS0NSRFM1MjhmeUZoWQ0KbE03UEFmNG9aMDVWQ2JN OERaWHFVejIzZi9lWWxVNTdET1RKUm1IckM3UFVpc0Q4R1I0WWFuYW5seXZ0bUN6Lw0KSDQwS1hV eHNnMjgyMGNWdjVuNnlLVTZBaW5vOUFmOTdWc1NpanZCd2RCRjgwVTB3WCsxSTk5bGlhOGhZUWRX OA0KajF2cDcwSXlnOWtSb3c5MWFBVHFkOTZmOHhuZk05SlJvM3pNZlFQbzc0b1dpcndwditTTw0K PVpseVENCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Mon Aug 20 21:51: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 E444E107E30F for ; Mon, 20 Aug 2018 21:51:54 +0000 (UTC) (envelope-from mail@dbalan.in) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 925AA83965 for ; Mon, 20 Aug 2018 21:51:54 +0000 (UTC) (envelope-from mail@dbalan.in) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D10A521E1C; Mon, 20 Aug 2018 17:51:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 20 Aug 2018 17:51:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dbalan.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=GD7Bfc9Tlu6yAABbjqGPcDsl8xNdFLRSTJDMxtn9+Xo=; b=EF7miww5 3usV51lzvwg16uSPqTbEpi/7v/JC6Xq4Wd6B9xqugC1R5+8hSX7nCADO3AYepSZc Z7aWfYtV/oxiw+izxKYv3boGg1ouy1Qw+4y0sJATUzsYbJXaVDLYJS3YNuZEA2w4 0xUZXERXMqupAoOlLIcNnU2psKbyIgnm+arl3K1EN142s0CpR6B30v5e3CJCxOs5 aCYEaSdV2kmx47IEdwlxaK+Yc3OcXJblWrCUo7beFW70c5MxK/XntdSjGPQ5a6PF qy1oD1GCM/iTjx43xJN0mDBKdmQzxWy4ilGxrsl5XmC+5XTq9gazAdXIQgtdw0iE auHrKgUmw+6pQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=GD7Bfc9Tlu6yAABbjqGPcDsl8xNdF LRSTJDMxtn9+Xo=; b=n79nvSrQIbyOQo20mGxWej2egRbNs2SMjyxGojhGTegRB B291Tf5a91nCnwhp2+rdrNwOtHm/Gv92ClEo3YPjttMTwqoMM2rjQy+W8M1qPkfT NLrGDjvW/zjlnllxDkuCkpTJRLYOTeCPgNQ5KBVdiJhRR2ym0dn3LfklS3NHfnZZ TOK8g5yr2U+DqAQOCfD1F6OvaCAUzX5RnzvyYdRZUwDHWERMQ/4vAEQBzvySON1O 2hkvIDAspVfBhU5MzkZhipWkzyzr6ZIitV7G5w7G6RasiXv1ZZB3/mJfr7/lm7i2 K1hI/Yx+ZOzeSLHwSqCfmOHX4a/eHrwOiWBN1Q0MA== X-ME-Proxy: X-ME-Sender: Received: from localhost (p5090fb25.dip0.t-ipconnect.de [80.144.251.37]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EC3EE471F; Mon, 20 Aug 2018 17:51:52 -0400 (EDT) Date: Mon, 20 Aug 2018 23:51:51 +0200 From: Dhananjay Balan To: Cy Schubert Cc: freebsd-current@freebsd.org Subject: Re: Sharing compiled builds between multiple 12-CURRENT boxes. Message-ID: <20180820215151.iy72af4flnztsuac@kazhap> References: <20180820062511.yaa2rimgmwpv3hxx@kazhap> <201808201248.w7KCm46k002914@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808201248.w7KCm46k002914@slippy.cwsent.com> User-Agent: NeoMutt/20180512 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 21:51:55 -0000 On Mon, Aug 20, 2018 at 05:48:04AM -0700, Cy Schubert wrote: > Make sure the archs are the same. Make sure the src and obj pathnames > on both servers are exactly the same. Make sure /usr/src (or wherever > you put it) is the same, it too needs to be rsynced. > > The tiniest differences will lead to this error. Starting from a make clean and rsyncing fixed the problems, I can install and boot my laptop from the build on my server. Thanks! Dhananjay Balan From owner-freebsd-current@freebsd.org Mon Aug 20 22:14:46 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 A23E5107E8A6 for ; Mon, 20 Aug 2018 22:14:46 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id A495884646 for ; Mon, 20 Aug 2018 22:14:45 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 3251 invoked by uid 89); 20 Aug 2018 22:14:37 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 20 Aug 2018 22:14:37 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180820150904.GS2340@kib.kiev.ua> Date: Tue, 21 Aug 2018 00:14:35 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> References: <20180815130447.GZ2340@kib.kiev.ua> <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 22:14:46 -0000 > On 20. Aug 2018, at 17:09, Konstantin Belousov wrote= : >=20 >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: >>=20 >> See here for a screenshot (also including the output of "show pte >> 0xfffff80001000000"): >>=20 >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1= -png > It is too early for ddb routines to register. > Ok can you try the following debugging patch, to verify my guess ? >=20 > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 18777d23f09..cd05fdb763f 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) > pd_p =3D (pd_entry_t *)DMPDkernphys; > for (i =3D 0; i < (NPDEPG * nkdmpde); i++) > pd_p[i] =3D (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | > - X86_PG_M | X86_PG_A | pg_nx | > - bootaddr_rwx(i << PDRSHIFT); > + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; > for (i =3D 0; i < nkdmpde; i++) > pdp_p[i] =3D (DMPDkernphys + ptoa(i)) | X86_PG_RW | > X86_PG_V; With this change it boots okay (mptramp_pagetables is 0x1000000, as expected= ). Best, Michael From owner-freebsd-current@freebsd.org Mon Aug 20 22:50: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 14E92107F6AE for ; Mon, 20 Aug 2018 22:50:32 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from mail.codexterous.com (mail.codexterous.com [104.156.251.179]) (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 BDAC786029 for ; Mon, 20 Aug 2018 22:50:31 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from [10.0.0.100] (pool-108-54-155-10.nycmny.fios.verizon.net [108.54.155.10]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bgmoser@codexterous.com) by mail.codexterous.com (Postfix) with ESMTPSA id 88FDE6884E7; Mon, 20 Aug 2018 18:50:30 -0400 (EDT) Subject: Re: Newly upgraded -CURRENT box does not boot To: Kevin Oberman , freebsd-current@freebsd.org References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> From: Brett Message-ID: Date: Mon, 20 Aug 2018 18:50:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 22:50:32 -0000 Hi Kevin, Thanks for your help. Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make LOADER_DEFAULT_INTERP=4th installkernel"? I had also previously tried " make clean all install WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help. Thanks! -Brett On 8/20/2018 6:31 PM, Kevin Oberman wrote: > Check the archive of this list for the past 24 hours. The default bot > was just converted to the lua boot today and there have been some > issues. The "one liner" to switch back to the FORTH boot was posted to > use to work around this and I believe that the change will be rolled > back until the "corner cases" can be fixed. > http://lists.freebsd.org/pipermail/freebsd-current/ > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > On Mon, Aug 20, 2018 at 2:28 PM Brett Gmoser > > wrote: > > Hi there, > > I was told to e-mail these addresses with this. > > I did an `svn update` on /usr/src last night, build world and > kernel as > usual. This morning I installed the kernel, booted into single user, > installed world and did mergemaster -Ui as usual. The new kernel had > booted fine. Upon reboot, the machine will no longer boot: > >      Startup error in /boot/lua/loader.lua: >      LUA ERROR: cannot open /boot/lua/loader.lua: no such file or > directory > >      can't load 'kernel' > > Many things in the bootloader do not work, including "boot > kernel.old", > "ls /boot", and various other things (most if not all just result in > "Command failed"). Interestingly, "ls /mnt" works, other > directories do > not. That's the only clue I have. > > I'm able to reboot in an installer image and mount the drive just > fine. > Everything is there and is as expected, including > /boot/lua/loader.lua. > > I re-installed everything in /usr/src/stand (chroot'd on the > installer > image, and "cd /usr/src/stand && make clean all install"). This > did not > fix the problem. > > Does anybody happen to have any ideas? > > Thanks, > > -Brett > > _______________________________________________ > 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 Aug 20 23:09:31 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 C59CC1080022 for ; Mon, 20 Aug 2018 23:09:30 +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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58C0F86AF8 for ; Mon, 20 Aug 2018 23:09:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id d10-v6so1709454itj.5 for ; Mon, 20 Aug 2018 16:09:30 -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=h4SDeT0b4lazKlmlrcUJpc4X9CTcxKJ4FzjpV29o82Q=; b=B02aJp2UpXlYuFWXKfNLBBO6RURTux+PZprjmbz/pY0Yzyq0n5YSFMjjNr0lcmVu4A 7wz03leLTT2s4H3YcHlvuMtNzU8IM/AdADf5s1neRxc4u1CcS+z6DSXdsLU5pNk4eUfI QoMlSHyzYObTLvqo60vToVg5OaDgciAeAqVjZs0TLBHn19ff4/fxMLc1rDoFzH4R5gWD Sn8PxuZMctFO7CNrZG7yf4T0ZO07QBPYfXfJE8H8JbkY9j3QpI8iWHOXI4qxgRFugVy5 ew78apr2knDqNhCxswclMWoA5FNBaeTXiY8MzIcYUFJewxs38qtQSWVxpGSZwlWlZ5s/ m0yQ== 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=h4SDeT0b4lazKlmlrcUJpc4X9CTcxKJ4FzjpV29o82Q=; b=BjDUszBCaUohirchXdj7NI5NxcfF/8/nUz3BM+3FkTTrM9aph4HBf3SCc6p+fnTHOX 6WPpkSVsUJo/cB4wD9NkaTjGARweVfYJ3yxUc6tHkkdE2FYT2Tj8x04lCEozaFOgF1a1 zGRDjkO8CBETIybKA4ZyApOtoxDsLt5fGixEh4sSY+2G13WN9hm1wgI8iSrw035IMBdl zKiuzKv/28+eHawGcLO66NQNluqP6bxnk1F/2shnpO/P80tAhkJ8wy3MZuhG9+/kukxv LnqdjL0Z7A7DwE/Xp1gPuvtYzsnA890wmp7Hj27nbkZlM0+CCcoi+12E74E+fUGOwyvK SUuA== X-Gm-Message-State: AOUpUlFfOol+JI7DUHth1YmvzvpMhGVX0R5e+cUmRx+XoCaVVz552xkC 7tkk0h87OVJ3t1IWI1uYniY5Mcse1JC91+fBHnEgsg== X-Google-Smtp-Source: AA+uWPyF4BZUz70mFnpCAczE1Rx/pDutTFMkOrBluoiNZN5Ry7oQfsDP++wCaDt1A189LgV+LdNP98s3oH2kHfTEmKQ= X-Received: by 2002:a24:d2:: with SMTP id 201-v6mr14914128ita.60.1534806569540; Mon, 20 Aug 2018 16:09:29 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 16:09:28 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> From: Warner Losh Date: Mon, 20 Aug 2018 17:09:28 -0600 X-Google-Sender-Auth: 9keLh48ibNTn24tSBYJJIbQVAzM Message-ID: Subject: Re: Newly upgraded -CURRENT box does not boot To: Brett Cc: Kevin Oberman , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 23:09:31 -0000 On Mon, Aug 20, 2018 at 4:50 PM, Brett wrote: > Hi Kevin, > > Thanks for your help. > > Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make > LOADER_DEFAULT_INTERP=4th installkernel"? > Nope. Kernel has nothing to do with it. That won't work. I had also previously tried " make clean all install > WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help. > You could just do "ln -sf /boot/loader_4th /boot/loader" and reboot if that's the issue. Or at the boot2 prompt, you could type in /boot/loader_4th if you haven't booted yet. You could also do a simple 'make install LOADER_DEFAULT_INTERP=4th" which does approximately the same thing. Though why you'd get loader.lua not found is kinda crazy Warner > Thanks! > > -Brett > > On 8/20/2018 6:31 PM, Kevin Oberman wrote: > >> Check the archive of this list for the past 24 hours. The default bot was >> just converted to the lua boot today and there have been some issues. The >> "one liner" to switch back to the FORTH boot was posted to use to work >> around this and I believe that the change will be rolled back until the >> "corner cases" can be fixed. >> http://lists.freebsd.org/pipermail/freebsd-current/ >> -- >> Kevin Oberman, Part time kid herder and retired Network Engineer >> E-mail: rkoberman@gmail.com >> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >> >> >> >> On Mon, Aug 20, 2018 at 2:28 PM Brett Gmoser < >> freebsdcurrent@codexterous.com > >> wrote: >> >> Hi there, >> >> I was told to e-mail these addresses with this. >> >> I did an `svn update` on /usr/src last night, build world and >> kernel as >> usual. This morning I installed the kernel, booted into single user, >> installed world and did mergemaster -Ui as usual. The new kernel had >> booted fine. Upon reboot, the machine will no longer boot: >> >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or >> directory >> >> can't load 'kernel' >> >> Many things in the bootloader do not work, including "boot >> kernel.old", >> "ls /boot", and various other things (most if not all just result in >> "Command failed"). Interestingly, "ls /mnt" works, other >> directories do >> not. That's the only clue I have. >> >> I'm able to reboot in an installer image and mount the drive just >> fine. >> Everything is there and is as expected, including >> /boot/lua/loader.lua. >> >> I re-installed everything in /usr/src/stand (chroot'd on the >> installer >> image, and "cd /usr/src/stand && make clean all install"). This >> did not >> fix the problem. >> >> Does anybody happen to have any ideas? >> >> Thanks, >> >> -Brett >> >> _______________________________________________ >> 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 >> " >> >> > _______________________________________________ > 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 Aug 20 23:24:36 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 B3C4D1080655 for ; Mon, 20 Aug 2018 23:24:36 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from mail.codexterous.com (mail.codexterous.com [104.156.251.179]) (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 69F1C8743D for ; Mon, 20 Aug 2018 23:24:36 +0000 (UTC) (envelope-from freebsdcurrent@codexterous.com) Received: from [10.0.0.100] (pool-108-54-155-10.nycmny.fios.verizon.net [108.54.155.10]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bgmoser@codexterous.com) by mail.codexterous.com (Postfix) with ESMTPSA id 4DC816884E7; Mon, 20 Aug 2018 19:24:35 -0400 (EDT) Subject: Re: Newly upgraded -CURRENT box does not boot To: Warner Losh Cc: Kevin Oberman , FreeBSD Current References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> From: Brett Message-ID: Date: Mon, 20 Aug 2018 19:24:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.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.27 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, 20 Aug 2018 23:24:36 -0000 On 8/20/2018 7:09 PM, Warner Losh wrote: > On Mon, Aug 20, 2018 at 4:50 PM, Brett > wrote: > >> Hi Kevin, >> >> Thanks for your help. >> >> Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make >> LOADER_DEFAULT_INTERP=4th installkernel"? >> > Nope. Kernel has nothing to do with it. That won't work. > > I had also previously tried " make clean all install >> WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help. >> > You could just do "ln -sf /boot/loader_4th /boot/loader" and reboot if > that's the issue. Or at the boot2 prompt, you could type in > /boot/loader_4th if you haven't booted yet. > > You could also do a simple 'make install LOADER_DEFAULT_INTERP=4th" which > does approximately the same thing. > > Though why you'd get loader.lua not found is kinda crazy > > Warner Hi Warner, I've tried those things, unfortunately none of them worked. With forth, things are slightly different (no more lua error), but ultimately the same result: - the kernel doesn't load ("can't load 'kernel'"). I lastly tried "ln -sf /boot/loader_4th /boot/loader", now I get "No /boot/loader" and a boot: prompt. I can do "boot/loader_4th" which will use the forth loader with the results the same as the above. Any help is appreciated - this is a very important box unfortunately. :( Thanks, -Brett From owner-freebsd-current@freebsd.org Mon Aug 20 23:33: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 CFC021080983 for ; Mon, 20 Aug 2018 23:33:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 465BA8820E for ; Mon, 20 Aug 2018 23:33:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id 72-v6so1794590itw.3 for ; Mon, 20 Aug 2018 16:33:50 -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=sobBtJO8eeuiSpMJ9jq8VtNCXB6ZVm1WtDSjoWOkTxM=; b=hmK2Hf2FB8Z/lpZO27BrqBeFyB06yx7jZCNQGZDzW3kM5/xy1Aa7BJp6usBfcOOKAz IVPiAw4yot6v9evuzgUNKoKaTcJFmZdEGV61MPQgfFEJRh/fMpig9IVSfl717WTZqf3a ziEWFgA/8AoUQpmaF+TGKN5k6YnzuaYRImcDU0qoP6LrM4h1oVYJTPR+iImWIziarmxc dDfflRqBqikhCvlbAMRLJVmO+jzvJLbBKetQQoxdDCf0vDWKMG720b3puNlcawzNXDpb BH5z+7/GQAn6oL+jb1TjoWtmZ/ASAj6MAWrPxVvAYOzSJ/NGkCZpwXvd/lc/ilGJlzF1 /p+Q== 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=sobBtJO8eeuiSpMJ9jq8VtNCXB6ZVm1WtDSjoWOkTxM=; b=MrwKpZQR+JyBoeD816RVzNLhEmCbPvjIruk/JAl1Q54O3o7MYqcU8u/yf9y7/gEhYB u1TPpXAifu6dnQ/qjtosa5QhSzbkA+H/bGQRZ/ECihlXJerWdcLu7y/f2WxPC4cwnHsz PF+KuJISPVLrATkCjFlYIb7tWlg1f6gfhXmiumJpbfrlsqXDJgaBiTv/TsV6a4Edd1et jops9mvRAK3KYz+YyXHIPODp9hQZ0wn4urGgcfcW/lmbCjuZ3kTOTUA4GInIZCfuF+UW FFqnQvPWzYrWQuQSuJMFnAy737GrZgup7bTmS1r7m/2DRyksv/5MS6cM40og/ZQwE8Cr /QVQ== X-Gm-Message-State: AOUpUlHJctzPMF1VUJjy0ehfB1FDN+6rsZBr+1xHwmYHG6AHWiPJM4Dr JEsul1J99WyiYhIIP+BgBZNK9HDatOQGtHsZoBeDLpR3zS4= X-Google-Smtp-Source: AA+uWPypOXqCaArUOW7CB/eI3rusePjvr2JTyCZgAV9i0y01y26YWoc3foLvFw5zg0qaj/kRS8M3lpn/68egt4nBAx8= X-Received: by 2002:a24:83c6:: with SMTP id d189-v6mr14890859ite.75.1534808029547; Mon, 20 Aug 2018 16:33:49 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 16:33:48 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> From: Warner Losh Date: Mon, 20 Aug 2018 17:33:48 -0600 X-Google-Sender-Auth: B0g9-37sshOUsnJxQ-Q3bl29r3I Message-ID: Subject: Re: Newly upgraded -CURRENT box does not boot To: Brett Cc: Kevin Oberman , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 23:33:51 -0000 On Mon, Aug 20, 2018 at 5:24 PM, Brett wrote: > On 8/20/2018 7:09 PM, Warner Losh wrote: > >> On Mon, Aug 20, 2018 at 4:50 PM, Brett >> wrote: >> >> Hi Kevin, >>> >>> Thanks for your help. >>> >>> Should I be doing "make LOADER_DEFAULT_INTERP=4th buildkernel && make >>> LOADER_DEFAULT_INTERP=4th installkernel"? >>> >>> Nope. Kernel has nothing to do with it. That won't work. >> >> I had also previously tried " make clean all install >> >>> WITHOUT_LUA_LOADER=yes" in /usr/src/stand which did not help. >>> >>> You could just do "ln -sf /boot/loader_4th /boot/loader" and reboot if >> that's the issue. Or at the boot2 prompt, you could type in >> /boot/loader_4th if you haven't booted yet. >> >> You could also do a simple 'make install LOADER_DEFAULT_INTERP=4th" which >> does approximately the same thing. >> >> Though why you'd get loader.lua not found is kinda crazy >> >> Warner >> > Hi Warner, > > I've tried those things, unfortunately none of them worked. With forth, > things are slightly different (no more lua error), but ultimately the same > result: - the kernel doesn't load ("can't load 'kernel'"). > > I lastly tried "ln -sf /boot/loader_4th /boot/loader", now I get "No > /boot/loader" and a boot: prompt. I can do "boot/loader_4th" which will use > the forth loader with the results the same as the above. > > Any help is appreciated - this is a very important box unfortunately. :( > If both /boot/loader_lua and /boot/loader_4th fail in the same way, you may be in trouble. There's a sliver of a chance that /boot/loader_simp might work, but if the other two both fail, it's something common between them that's likely shared by /boot/loader_simp. I'd install old /boot/loader and then try to bisect where things went wrong from your last update. Thankfully, it looks like the last known good one for you was in March, and all versions since then you can rebuild just src/stand w/o doing a full world so it should be quick to trace down. There are maybe 20,000 svn changes or so, which should zero in on the right one in about 17 tries... It takes me about a minute to build, so with luck you'll know in about an hour... Warner From owner-freebsd-current@freebsd.org Mon Aug 20 23:44: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 703621080FEE; Mon, 20 Aug 2018 23:44:06 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E967888B7E; Mon, 20 Aug 2018 23:44:05 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x234.google.com with SMTP id c22-v6so7894135iob.1; Mon, 20 Aug 2018 16:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=t4xZc3bt3VKpHSrYSlh9m+Vs+aKryMOGDMcPTeUrkA8=; b=ZTGr9LHgtx5TpN0Gu74bqyzhzmOEKkp8vMuC+HK7KVYH6ZU3HKvgnjL37jT5o2co88 gzGz/WWCUW/5m6kKmlRMiac3m2BFe1ypNYWyDw4Ten9vON7PTiS/57adQgUMHzf7S+37 /h65ihEkXQ9yQS4lt+SLJO9yagQL/vebyqIeqd4KCFLSa9cl3pgZjNIoXBuCbfHtfBFk R3I1ixeDe36Mtl1eNg43H0JNoqVsOVQUdRuadsBOVrI7UziNcocSwxAPjSLjkTVz8BAL cscs4lVZybfQnq4U6Bz2unkSyLfutHuKKZEr56QVehMK980lYJ1ZwA6I8vTj51KYue7L kVTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t4xZc3bt3VKpHSrYSlh9m+Vs+aKryMOGDMcPTeUrkA8=; b=eDs9XFop+VMWn2bQIOsJh79zu9vdlkNEIPQTi5nAsEOE3kaRZhKSfhK0jEfGsOYCQ2 +iuXQG/77X9cWJ3x7bRNgkGTwrvrjrXGQ1L6Jh5f1sqF/YFHMw4v8iX+R3eYgRapMHt0 H4R32u76pPMYc6WsTfuVfFbx6XnQF2BWYBsaxnDY1LM10mixaWSqSATTKqY36SBw5r+a 5FvDkfbZCiLY5WzGLiDlp0T3DJOMaJKcpakBS3NBunqbjAxzvnWvI6+mlGdvp3kHH+qt YihELFnOXQS7KtCELDNKBGbQUsyT8TCHxr5o2ng3oIkMEcwB71Vl9Y7qQOj1pUpKg3XR xWHw== X-Gm-Message-State: AOUpUlHzQytzobYC+F+xVwHarTGvNRHXtfzPXu2m82zIcPTtiXcr4kXO gNVEla3VSQP/vLQnFwvsuRCVKdsorvzp+rIOcmPm7k8A X-Google-Smtp-Source: AA+uWPzvSOTGR/HleT0vjELv274EnMAjJ1odTNm2gEGsqnHSxtDnIVfSGmJN56IAefoHGoAFk+Chbh2D4w1Zlut6Kzc= X-Received: by 2002:a6b:b546:: with SMTP id e67-v6mr18134933iof.179.1534808645238; Mon, 20 Aug 2018 16:44:05 -0700 (PDT) MIME-Version: 1.0 From: blubee blubeeme Date: Tue, 21 Aug 2018 07:43:53 +0800 Message-ID: Subject: soundcard.h expose device block size To: freebsd-multimedia@freebsd.org, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 23:44:06 -0000 I'm looking at FreeBSD's soundcard.h and it doesn't seem to expose the hardware block size, this seems like a limitation stemming from FreeBSD's soundcard.h being an extension of OSS. Since we've already implemented a lot of additional features on top of the OSS API, is it possible to also expose the hardware block size for applications that might need access to that information? Best, Owen From owner-freebsd-current@freebsd.org Mon Aug 20 23:50: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 B6C0210812F9 for ; Mon, 20 Aug 2018 23:50:40 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B81888E6F for ; Mon, 20 Aug 2018 23:50:40 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id n18-v6so14026922ioa.9 for ; Mon, 20 Aug 2018 16:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r6ygeiijyjvTEoJX/4w+r/Ce7DO9Y2Sfl4GFsO5DRT0=; b=IRhWv5L9Kh2uIvw39kM0Zzw+NFtb8YR+GQQLP5cFOJP8HlBEa8yH93CC62b8IXHnKx eLbDsEEqbg9xXZcf4XLGB1ZBtb+aeqNo5bW54ixdRrCeTHq/QX4pUrBam69IQnID5b7g IsofyAVNgJgEFNVVTvKjdvbVJTtnl5mBKGL1JV6HJMeeNj88UQ3uFddKDzG3jzO7qSUs WZvkMN8rnFORSd/4RM0yWbC5n3Dx+11RryekKgjaxYTEmGDZTs+QbwKO6Opjloojfs2+ UwKZAxNc9GT6eH4y1xWcVjItjwevesFZkStTdpb8LTkwRqnPqp7HG+jkLD4sKOcevlhk UN+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r6ygeiijyjvTEoJX/4w+r/Ce7DO9Y2Sfl4GFsO5DRT0=; b=j19zr0ow4H5iBCzBOriqVeOBUphyqk5PXFI5ypP/XcKfYKtM8vXIbz9ter7c1goSeB XjOJVc3jP/EkIJTZmc2Fqnrpv/LjjMz642iGCxUbGefhCFNBhKPzob6VEyoA+0bYiLHH dLSpAH5svxtJsF7LxDaRQeLe6UITXL+lwyz0rRWKTUwJRbCmEcGS++wRZSrihOBi1gZV jtRMvnWSBHg1NRot/wJIiJ7PmYBx7ARWcbZvoqpOCgBYCE49vRgRRDY1PF1CiEttiZ3/ mVOVvw1upgfhw77w7Kylhz0LVE5eXl84aFaYdRNCK3aOuU+03p8hW6a1VTXKdFKQ6i6u PTRA== X-Gm-Message-State: AOUpUlFCGryquiobVM4hGautHrN+Q7huf94fI58FTReV6z/gTqFi0s6V yhI7iEVuDMcq04T/28xQD2JfSfDOZdXHsMbA8Cw= X-Google-Smtp-Source: AA+uWPzA5F3GmlUy6hqhDv2GdZ+N3cRvKWBySeFKLJ2opaaOonWUmZ25HBKhDWzh6aWOoNPPBYHQBwsGOJxK/GtY/fM= X-Received: by 2002:a6b:b546:: with SMTP id e67-v6mr18148915iof.179.1534809039670; Mon, 20 Aug 2018 16:50:39 -0700 (PDT) MIME-Version: 1.0 References: <61A99917-931B-45C0-8F6E-6BC0BE5DEAFB@yahoo.com> In-Reply-To: <61A99917-931B-45C0-8F6E-6BC0BE5DEAFB@yahoo.com> From: blubee blubeeme Date: Tue, 21 Aug 2018 07:50:28 +0800 Message-ID: Subject: Re: building LLVM threads gets killed To: marklmi@yahoo.com Cc: freebsd-rwg@pdx.rh.cn85.dnsmgr.net, FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 23:50:41 -0000 On Mon, Aug 20, 2018 at 11:04 PM Mark Millard wrote: > Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on > Mon Aug 20 14:26:55 UTC 2018 : > > > > On 20 Aug 2018, at 05:01, blubee blubeeme > wrote: > > > > > > > > I am running current compiling LLVM60 and when it comes to linking > > > > basically all the processes on my computer gets killed; Chrome, > Firefox and > > > > some of the LLVM threads as well > > > ... > > > > llvm/build % ninja -j8 > > > > [2408/2473] Building CXX object > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes > -I../lib/Passes > > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > > -fvisibility-inlines-hidden -Werror=date-time > > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > > > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions > -fno-rtti -MD > > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > > ../lib/Passes/PassBuilder.cpp > > > > c++: error: unable to execute command: Killed > > > > > > It is running out of RAM while running multiple parallel link jobs. If > > > you are building using WITH_DEBUG, turn that off, it consumes large > > > amounts of memory. If you must have debug info, try adding the > > > following flag to the CMake command line: > > > > > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > > > > > That will limit the amount of parallel link jobs to 1, even if you > > > specify -j 8 to gmake or ninja. > > > > > > Brooks, it would not be a bad idea to always use this CMake flag in the > > > llvm ports. :) > > > > And this may also fix the issues that all the small > > memory (aka, RPI*) buliders are facing when trying > > to do -j4? > > It may help, but: > > Even just compiles with no links running can get the kills > in such small system contexts. > > And going for a simpler context that can demonstrate > the behavior . . . > > Taking a Pine64+ 2GB as an example (4 cores with 1 > HW-thread per core, 2 GiBytes of RAM, USB device for > root file system and swap partition): > > In another login: > # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 > > That "4" and "536870912" total to the 2 GiBytes so > swapping is induced for the context in question. > (Scale --vm-bytes appropriately to context.) > [Note: I had 3 GiBytes of swap space in a partition > for the below.] > > [stress is from the port sysutils/stress .] > > I had left the default vm.pageout_oom_seq=12 in place for this, > making the kills easier to get than the 120 figure would. It > does not take very long generally for some sort of message to > show up. Sometimes kills happen: > > My test environment has Mark Johnston patches to report > things not normally reported: > > waited 9s for async swap write > waited 9s for swap buffer > waited 9s for async swap write > waited 9s for async swap write > waited 9s for async swap write > v_free_count: 1357, v_inactive_count: 1 > Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out > of swap space > waited 5s for async swap write > waited 5s for swap buffer > waited 5s for async swap write > waited 5s for async swap write > waited 5s for async swap write > waited 13s for async swap write > waited 12s for swap buffer > waited 13s for async swap write > waited 12s for async swap write > waited 12s for async swap write > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > . . . > > (I made multiple runs, most manually stopped. None run for > all that long.) > > (Warning: the swap space part of "killed: out of swap space" > can be a misnomer. Killing is driven by having low free RAM > for sufficiently long. vm.pageout_oom_seq controls how > long. Swap space may be unused, little used, or actually be > low. With 3 GiBytes of swap space in the partition, these > runs were not low on swap space.) > > Even with fairly stable ms/w figures the queue depths can > get to be large, implying long times before the last queued > write completes. For example (for a USB storage device for > the root file system and swap partition): > > dT: 1.006s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| mmcsd0 > 56 312 0 0 0.0 312 19985 142.6 0 0 > 0.0 99.6| da0 > > Large quantities of bytes are being queued in a short time > relative to the around 20 MiByte/sec figure that can be > sustained. The quantity is spread over the queue entries. > > > Note: The Pine46+ 2GB builds devel/llvm60 in 14.5hr just fine > with vm.pageout_oom_seq=120 when using all 4 cores. But it > has twice the RAM as a rpi3/rpi2 while having the same number > of cores. It simply does not have as much to write out as > often. (The same sort of point goes for buildworld buildkernel > sorts of activities.) > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I'd just like to clarify that I am not on what should be considered a limited system like the RPI. I have: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz 32GB of ram and a 256GB m.2 ssd. Best, Owen From owner-freebsd-current@freebsd.org Mon Aug 20 23:55:37 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 3FB4E1081591 for ; Mon, 20 Aug 2018 23:55:37 +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 7FFA789256 for ; Mon, 20 Aug 2018 23:55:36 +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 w7KNtXtR077067; Mon, 20 Aug 2018 16:55:33 -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 w7KNtXYR077066; Mon, 20 Aug 2018 16:55:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808202355.w7KNtXYR077066@pdx.rh.CN85.dnsmgr.net> Subject: Re: building LLVM threads gets killed In-Reply-To: To: blubee blubeeme Date: Mon, 20 Aug 2018 16:55:33 -0700 (PDT) CC: marklmi@yahoo.com, FreeBSD current 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.27 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, 20 Aug 2018 23:55:37 -0000 > On Mon, Aug 20, 2018 at 11:04 PM Mark Millard wrote: > > > Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on > > Mon Aug 20 14:26:55 UTC 2018 : > > > > > > On 20 Aug 2018, at 05:01, blubee blubeeme > > wrote: > > > > > > > > > > I am running current compiling LLVM60 and when it comes to linking > > > > > basically all the processes on my computer gets killed; Chrome, > > Firefox and > > > > > some of the LLVM threads as well > > > > ... > > > > > llvm/build % ninja -j8 > > > > > [2408/2473] Building CXX object > > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes > > -I../lib/Passes > > > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > > > -fvisibility-inlines-hidden -Werror=date-time > > > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > > > > -Wstring-conversion -fdiagnostics-color -g -fno-exceptions > > -fno-rtti -MD > > > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > > > ../lib/Passes/PassBuilder.cpp > > > > > c++: error: unable to execute command: Killed > > > > > > > > It is running out of RAM while running multiple parallel link jobs. If > > > > you are building using WITH_DEBUG, turn that off, it consumes large > > > > amounts of memory. If you must have debug info, try adding the > > > > following flag to the CMake command line: > > > > > > > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > > > > > > > That will limit the amount of parallel link jobs to 1, even if you > > > > specify -j 8 to gmake or ninja. > > > > > > > > Brooks, it would not be a bad idea to always use this CMake flag in the > > > > llvm ports. :) > > > > > > And this may also fix the issues that all the small > > > memory (aka, RPI*) buliders are facing when trying > > > to do -j4? > > > > It may help, but: > > > > Even just compiles with no links running can get the kills > > in such small system contexts. > > > > And going for a simpler context that can demonstrate > > the behavior . . . > > > > Taking a Pine64+ 2GB as an example (4 cores with 1 > > HW-thread per core, 2 GiBytes of RAM, USB device for > > root file system and swap partition): > > > > In another login: > > # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 > > > > That "4" and "536870912" total to the 2 GiBytes so > > swapping is induced for the context in question. > > (Scale --vm-bytes appropriately to context.) > > [Note: I had 3 GiBytes of swap space in a partition > > for the below.] > > > > [stress is from the port sysutils/stress .] > > > > I had left the default vm.pageout_oom_seq=12 in place for this, > > making the kills easier to get than the 120 figure would. It > > does not take very long generally for some sort of message to > > show up. Sometimes kills happen: > > > > My test environment has Mark Johnston patches to report > > things not normally reported: > > > > waited 9s for async swap write > > waited 9s for swap buffer > > waited 9s for async swap write > > waited 9s for async swap write > > waited 9s for async swap write > > v_free_count: 1357, v_inactive_count: 1 > > Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out > > of swap space > > waited 5s for async swap write > > waited 5s for swap buffer > > waited 5s for async swap write > > waited 5s for async swap write > > waited 5s for async swap write > > waited 13s for async swap write > > waited 12s for swap buffer > > waited 13s for async swap write > > waited 12s for async swap write > > waited 12s for async swap write > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > > . . . > > > > (I made multiple runs, most manually stopped. None run for > > all that long.) > > > > (Warning: the swap space part of "killed: out of swap space" > > can be a misnomer. Killing is driven by having low free RAM > > for sufficiently long. vm.pageout_oom_seq controls how > > long. Swap space may be unused, little used, or actually be > > low. With 3 GiBytes of swap space in the partition, these > > runs were not low on swap space.) > > > > Even with fairly stable ms/w figures the queue depths can > > get to be large, implying long times before the last queued > > write completes. For example (for a USB storage device for > > the root file system and swap partition): > > > > dT: 1.006s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > > ms/d %busy Name > > 0 0 0 0 0.0 0 0 0.0 0 0 > > 0.0 0.0| mmcsd0 > > 56 312 0 0 0.0 312 19985 142.6 0 0 > > 0.0 99.6| da0 > > > > Large quantities of bytes are being queued in a short time > > relative to the around 20 MiByte/sec figure that can be > > sustained. The quantity is spread over the queue entries. > > > > > > Note: The Pine46+ 2GB builds devel/llvm60 in 14.5hr just fine > > with vm.pageout_oom_seq=120 when using all 4 cores. But it > > has twice the RAM as a rpi3/rpi2 while having the same number > > of cores. It simply does not have as much to write out as > > often. (The same sort of point goes for buildworld buildkernel > > sorts of activities.) > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > ( dsl-only.net went > > away in early 2018-Mar) > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > I'd just like to clarify that I am not on what should be considered a > limited system like the RPI. > > I have: > hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz > 32GB of ram and a 256GB m.2 ssd. And probably running ZFS, which ate all your memory and put you in a memory contrained environment. You can have 384GB of ram and be memory contrained if you let something eat that memory up in a way that the pager can not get to it. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Tue Aug 21 03:19:41 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 744AB108721E for ; Tue, 21 Aug 2018 03:19:41 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEC58FDC8; Tue, 21 Aug 2018 03:19:41 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id AF9F227769; Tue, 21 Aug 2018 03:19:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f180.google.com with SMTP id f1-v6so13161784ljc.9; Mon, 20 Aug 2018 20:19:40 -0700 (PDT) X-Gm-Message-State: AOUpUlFwTovgjLtE6qA1xGkL9MfUpzG9OaXXcpL+DAvSh2Oq0bCJsrw3 OSmFK3rNqXuN6TZXTSaRghIx0dMrc+DB+ugMxF8= X-Google-Smtp-Source: AA+uWPxC1wLBCqgOigicDKP0xRf5DDVGzOQFdCDnxITvLKUSWRVjMJ1hnkCZFK+0nFWRhRRnDDX2TvvmGf2MtcPJPxE= X-Received: by 2002:a2e:4055:: with SMTP id n82-v6mr29533053lja.99.1534821579165; Mon, 20 Aug 2018 20:19:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:91d2:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 20:19:18 -0700 (PDT) In-Reply-To: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> From: Kyle Evans Date: Mon, 20 Aug 2018 22:19:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Newly upgraded -CURRENT box does not boot To: Brett Gmoser Cc: FreeBSD Current , Toomas Soome , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 03:19:41 -0000 On Mon, Aug 20, 2018 at 4:27 PM, Brett Gmoser wrote: > Hi there, > > I was told to e-mail these addresses with this. > > I did an `svn update` on /usr/src last night, build world and kernel as > usual. This morning I installed the kernel, booted into single user, > installed world and did mergemaster -Ui as usual. The new kernel had booted > fine. Upon reboot, the machine will no longer boot: > > Startup error in /boot/lua/loader.lua: > LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory > > can't load 'kernel' > > Many things in the bootloader do not work, including "boot kernel.old", "ls > /boot", and various other things (most if not all just result in "Command > failed"). Interestingly, "ls /mnt" works, other directories do not. That's > the only clue I have. > > I'm able to reboot in an installer image and mount the drive just fine. > Everything is there and is as expected, including /boot/lua/loader.lua. > > I re-installed everything in /usr/src/stand (chroot'd on the installer > image, and "cd /usr/src/stand && make clean all install"). This did not fix > the problem. > > Does anybody happen to have any ideas? > To briefly follow up and summarize the current standing here following some more discussion/attempts to fix on IRC: 1.) x86 BIOS boot 2.) Problem appears for both forthloader and lualoader 3.) Early March loader works, recent loader does not [Only tried loader from the past ~day] 4.) ls / works, ls /mnt works, ls /boot and other directories fails 5.) However, /boot is confirmed intact and populated by booting via 11.2 install media and inspecting local disk We'll hopefully be having a bisect session tomorrow to figure out where exactly this broke so that maybe Brett has a chance to upgrade to 12.0, unless this sounds familiar to someone and the cause is obvious. =) Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Tue Aug 21 06:03: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 5D277108A321 for ; Tue, 21 Aug 2018 06:03:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (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 D7864748E7 for ; Tue, 21 Aug 2018 06:03:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: JC6pI7AVM1lGaj7z61zS48TL5TBdqsh1MWx7Kp56KTwvY4KdmoMeM9Bh2bV1Vpt tHT8.CDRFOGlMH4K9P_0wHsc.skvrgHAEOwX21r5tn.iP_8_puo6zsWJEiS7j9pD6ScgwfLjF4i5 5zo3Mjrv95IoWxOJG1No6hc3ZlquIMt.Up5upW_4vaVcZ86HIS9Bh3ua4AMNm26th9SxfZ2TFoge TrVA2vANdSggxtv4DCRHICY4FqMduENVyXQIBXPdVWHAPJFJlAIEofPRMWnyA.WHD9c0H10emup4 QjvrvPnVl3EJUcMbC1SP4i4uMvlaSHbD9p8gpy6H8vSpgWscWEwX5KkSb7YtVRU2ICOUuA2TIZIE ZdVmHuIvO9_pAlNqowmv9rIGj6VA02sRvdA3Jl_NVZcukeljMSPnTxkzCujeaGe2tWdAI_MspK1a 1ohWxqyAbq4KUc6.7ufZnqPZXDHFHfpEqPSavP583leOn5mz7kcWi6WT1Kc2V0kS4jlTEQyp8fDs j0OHhkFtrV9GQeKi1.odAo0EKxEPVOoaPsj7YTZLe0kUFucXTftr2TyFcT.9SMs6JP9DUdDkK2XQ Kqt.DgMiOYU7l7cBIqoqCV0u70SmiNpynqrdET6PyvdHa2u3IKVDZ6F59qCP_nSODHiSLkHJV3Fh 4E88WX2ggbmWGKyhBowYjGAh2Oi91g6JfOb7W1eYuX7KOuCavDczAITlAi47qRwlVIKbmsm9U.tf Ot7F5HrFkvHrGPpri3mMbgADw9PTCxx.wXp.KrkFsTRICw3EuO9RrCx.fUtnA0drbtt4uC.eM_Kh AzBxIMcjynxx0kRRXj26F7YX9e5D86RMCfk94x._oyQJ8tQ5x4wE6EzqEKj16JgGcoJmJPqmTprh kjpOWOn4mlCfhJcoJZVXkMKPAZ80Yhy6qYdCsQf5dhkU4zp2yDvi.KTG.AOd5pMWYD4bpu0Lhyqg 1GGpjm6Nw_oeThyWpD8AqqxitsiXok0svwXEOn0Os9No91hFooCTf3rLW4WiU4WEjDEMWWxJBsxS 4D7RyrlA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Tue, 21 Aug 2018 06:03:27 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e9dd84fa656d3a8d0f51a260363547b7; Tue, 21 Aug 2018 06:03:25 +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.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Message-Id: Date: Mon, 20 Aug 2018 23:03:24 -0700 To: gurenchan@gmail.com, FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 06:03:34 -0000 When I discovered that you were building debug versions of devel/llvm60 that also meant that my Pine64+ 2GB specifics do not make a useful comparison (do not show how small an environment can be for a build). Last I tried such a debug build was on a powerpc64 with 16 MiBytes RAM and it took having a swap space of 10 MiBytes (9 insufficient) but it was devel/llvm40 and the machine was not in use for anything else significant and was using UFS, unlike your more involved context (ZFS, large applications running). For your usage, it is not clear to me that 32 GiBytes is all that much RAM, nor that 32GiByte RAM + 2 GiByte swap is all that big of a total. To me it seemed odd that your swap was so small for what you described as running in your environment vs. the amount of RAM. If it turns out handy, the stress test (scaled to 32 GiBytes) should show how your context handles low free RAM over extended periods. (Without the complications or delays of a build being involved.) (The Mark Johnston patches expose more than just any "was killed" notice.) My expectation is that the stress test would over time show OOM kills even if you expanded the swap space so that it clearly had notable space not in use at the time. It may be that setting vm.pageout_oom_seq large enough would help your builds complete by tolerating low free RAM for a longer time. Something I only just learned was that by default lld is multi-threaded. I've been told that this mode of operation uses more RAM but I've no knowledge of my own about the tradeoffs. They might be bigger for debug builds than for non-debug builds. Doing a quick experiment showed lld using 5 threads or so unless I used -Wl,--no-threads . (I was using the cc/c++ command interface.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Tue Aug 21 06:38: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 C3790108B0E6 for ; Tue, 21 Aug 2018 06:38:55 +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 56B1E75AB4; Tue, 21 Aug 2018 06:38:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [51.52.172.98]) by mail.baldwin.cx (Postfix) with ESMTPSA id 94E3D10A87D; Tue, 21 Aug 2018 02:38:48 -0400 (EDT) Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: "O. Hartmann" , FreeBSD CURRENT References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> Cc: arichardson@FreeBSD.org From: John Baldwin Message-ID: <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> Date: Tue, 21 Aug 2018 07:38:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 21 Aug 2018 02:38:48 -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.27 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, 21 Aug 2018 06:38:55 -0000 On 8/20/18 9:00 PM, O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Mon, 20 Aug 2018 21:24:21 +0200 > "O. Hartmann" schrieb: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Building NanoBSD world on CURRENT r338113 fails due to: >> >> [...] >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot" >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. Copy the header to >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by Makefile >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1 >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >> [...] >> >> >> This problem occured during today's source updates since I was able to build the NanoBSD >> image I intend to build yesterday ~ r338060. >> >> What is going wrong? > > It seems the problem has been introduced after r338095, since r338095 builds ok, while > r338096 doesn't. 338096 added this check to catch a kind of error in our Makefiles. Alex (cc'd) can help with figuring out what the error is. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Aug 21 08:30: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 C0671108D7F8 for ; Tue, 21 Aug 2018 08:30:19 +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 6C4CB791B1; Tue, 21 Aug 2018 08:30:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from dhcp-10-248-112-19.eduroam.wireless.private.cam.ac.uk (global-5-143.nat-2.net.cam.ac.uk [131.111.5.143]) by mail.baldwin.cx (Postfix) with ESMTPSA id 027F510AFCD; Tue, 21 Aug 2018 04:30:17 -0400 (EDT) Subject: Re: Newly upgraded -CURRENT box does not boot To: Kyle Evans , Brett Gmoser References: <80002f50-c2a7-ff39-dbef-e39576c3da51@codexterous.com> Cc: FreeBSD Current , Toomas Soome , Warner Losh From: John Baldwin Message-ID: Date: Tue, 21 Aug 2018 09:30:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 21 Aug 2018 04:30:18 -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.27 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, 21 Aug 2018 08:30:19 -0000 On 8/21/18 4:19 AM, Kyle Evans wrote: > On Mon, Aug 20, 2018 at 4:27 PM, Brett Gmoser > wrote: >> Hi there, >> >> I was told to e-mail these addresses with this. >> >> I did an `svn update` on /usr/src last night, build world and kernel as >> usual. This morning I installed the kernel, booted into single user, >> installed world and did mergemaster -Ui as usual. The new kernel had booted >> fine. Upon reboot, the machine will no longer boot: >> >> Startup error in /boot/lua/loader.lua: >> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory >> >> can't load 'kernel' >> >> Many things in the bootloader do not work, including "boot kernel.old", "ls >> /boot", and various other things (most if not all just result in "Command >> failed"). Interestingly, "ls /mnt" works, other directories do not. That's >> the only clue I have. >> >> I'm able to reboot in an installer image and mount the drive just fine. >> Everything is there and is as expected, including /boot/lua/loader.lua. >> >> I re-installed everything in /usr/src/stand (chroot'd on the installer >> image, and "cd /usr/src/stand && make clean all install"). This did not fix >> the problem. >> >> Does anybody happen to have any ideas? >> > > To briefly follow up and summarize the current standing here following > some more discussion/attempts to fix on IRC: > > 1.) x86 BIOS boot > 2.) Problem appears for both forthloader and lualoader > 3.) Early March loader works, recent loader does not [Only tried > loader from the past ~day] > 4.) ls / works, ls /mnt works, ls /boot and other directories fails > 5.) However, /boot is confirmed intact and populated by booting via > 11.2 install media and inspecting local disk > > We'll hopefully be having a bisect session tomorrow to figure out > where exactly this broke so that maybe Brett has a chance to upgrade > to 12.0, unless this sounds familiar to someone and the cause is > obvious. =) I would start with bisecting the changes to libi386/biosdisk.c. Also, comparing 'lsdev -v' output between old and new loaders might be a useful step before starting on the bisecting. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Aug 21 09:29: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 E9467106626A for ; Tue, 21 Aug 2018 09:29:38 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68EDA7B0A2; Tue, 21 Aug 2018 09:29:38 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.19.247) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 21 Aug 2018 11:29:25 +0200 Date: Tue, 21 Aug 2018 11:30:51 +0200 From: Marko Zec To: Olivier =?ISO-8859-1?Q?Cochard-Labb=E9?= CC: freebsd-current Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related Message-ID: <20180821113051.7d35bc39@x23> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [31.147.19.247] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 09:29:39 -0000 On Mon, 20 Aug 2018 16:26:29 +0200 Olivier Cochard-Labb=C3=A9 wrote: > Just loading carp kernel module is enough to panic it: >=20 > [root@router]~# uname -a > FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M > i386 [root@router]~# kldload carp > Fatal trap 12: page fault while in kernel mode How many vnets were already instantiated at the time of kldloading carp? Does the panic ocur with no (non-default) vnets instantiated? > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x14de0f4c > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0x1201657c > stack pointer =3D 0x28:0x11f3e804 > frame pointer =3D 0x28:0x11f3e80c > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 55291 (kldload) > [ thread pid 55291 tid 100070 ] > Stopped at vnet_carpstats_init+0x2c: movl > %eax,__stop_set_vnet(%ecx,%esi,1) >=20 > A backtrace on kgdb gives this output: >=20 > (kgdb) bt > #0 __curthread () at ./machine/pcpu.h:226 > #1 doadump (textdump=3D) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_shutdown.c:366 > #2 0x009f69ee in db_dump (dummy=3D302081404, dummy2=3Dfalse, dummy3=3D-1, > dummy4=3D0x11f3e4fc "") at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:574 > #3 0x009f67c7 in db_command (last_cmdp=3D, > cmd_table=3D, dopager=3D) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:481 > #4 0x009f6520 in db_command_loop () at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_command.c:534 > #5 0x009f978d in db_trap (type=3D12, code=3D0) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/ddb/db_main.c:252 > #6 0x0113e29e in kdb_trap (type=3D12, code=3D0, tf=3D0x11f3e7c4) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/subr_kdb.c:693 > #7 0x016d593c in trap_fatal (frame=3D0x11f3e7c4, eva=3D) > at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:989 > #8 0x016d5a43 in trap_pfault (frame=3D, usermode=3D0, > eva=3D350097228) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:827 > #9 0x016d508f in trap (frame=3D0x11f3e7c4) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:519 > #10 0xffc0315d in ?? () > #11 0x11f3e7c4 in ?? () > #12 0x0121c7ef in vnet_register_sysinit (arg=3D0x120182cc > ) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/net/vnet.c:500 > #13 0x010c18f0 in linker_file_sysinit (lf=3D) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:236 > #14 linker_load_file (filename=3D, result=3D out>) > out>at /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:462 > #15 linker_load_module (kldname=3D, modname=3D0x11449c00 > "carp", parent=3D0x0, verinfo=3D0x0, lfpp=3D0x11f3ea6c) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:2092 > #16 0x010c30d1 in kern_kldload (td=3D0x1157c380, file=3D0x11449c00 "carp", > fileid=3D0x11f3ea98) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:1071 > #17 0x010c31ee in sys_kldload (td=3D0x1157c380, uap=3D0x1157c604) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/kern/kern_linker.c:1097 > #18 0x016d6217 in syscallenter (td=3D) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/../../kern/subr_syscal= l.c:135 > #19 syscall (frame=3D0x11f3eba8) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/i386/i386/trap.c:1152 > #20 0xffc033a7 in ?? () > #21 0x11f3eba8 in ?? () > Backtrace stopped: Cannot access memory at address 0xffbfecec > (kgdb) frame 12 > #12 0x0121c7ef in vnet_register_sysinit (arg=3D0x120182cc > ) at > /usr/local/BSDRP/TESTING/FreeBSD/src/sys/net/vnet.c:500 > 500 vs->func(vs->arg); >=20 >=20 > Regards, >=20 > Olivier > _______________________________________________ > 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 Tue Aug 21 12:31: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 0A6D4107070B for ; Tue, 21 Aug 2018 12:31:58 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD9AD81619 for ; Tue, 21 Aug 2018 12:31:57 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5DF29B0BD for ; Tue, 21 Aug 2018 12:31:57 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-pg1-f170.google.com with SMTP id z25-v6so3697923pgu.7 for ; Tue, 21 Aug 2018 05:31:57 -0700 (PDT) X-Gm-Message-State: AOUpUlGsxCPenfJrJLpDwLw0SDiY4Ry9n3/W47yVGWryLuiLQsSdZzu5 VDerwUxtsriYAlMq9WA4r4WGEtsPkUQvdqgD3Ps= X-Google-Smtp-Source: AA+uWPwYgHHo9MMSNjgSCLeObhMzEHbaVBbt/hGAjTgBYAsDMcuKgr4GwLY5/A6QDzpPqw06xUdN7/J/I0Zf3ftrO4A= X-Received: by 2002:a65:60cf:: with SMTP id r15-v6mr47045404pgv.41.1534854716249; Tue, 21 Aug 2018 05:31:56 -0700 (PDT) MIME-Version: 1.0 References: <20180821113051.7d35bc39@x23> In-Reply-To: <20180821113051.7d35bc39@x23> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 21 Aug 2018 14:31:42 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related To: Marko Zec Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 12:31:58 -0000 On Tue, Aug 21, 2018 at 11:29 AM Marko Zec wrote: > On Mon, 20 Aug 2018 16:26:29 +0200 > Olivier Cochard-Labb=C3=A9 wrote: > > > Just loading carp kernel module is enough to panic it: > > > > [root@router]~# uname -a > > FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M > > i386 [root@router]~# kldload carp > > Fatal trap 12: page fault while in kernel mode > > How many vnets were already instantiated at the time of kldloading > carp? Does the panic ocur with no (non-default) vnets instantiated? > > Hi, None VNET were instantiated: Just start the latest 12-i386 image ( https://download.freebsd.org/ftp/snapshots/VM-IMAGES/12.0-CURRENT/i386/Late= st/) on a VM, and once logged as root enter 'kldload carp' to trigger a panic. Regards, Olivier From owner-freebsd-current@freebsd.org Tue Aug 21 13:15:17 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 8FC581071A40 for ; Tue, 21 Aug 2018 13:15:17 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 186A982C11; Tue, 21 Aug 2018 13:15:16 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3497A25D3888; Tue, 21 Aug 2018 13:15:09 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4BDE9D1F95E; Tue, 21 Aug 2018 13:15:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id grBs0SlPtEzc; Tue, 21 Aug 2018 13:15:06 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4DD89D1F95D; Tue, 21 Aug 2018 13:15:05 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Olivier =?utf-8?q?Cochard-Labb=C3=A9?=" Cc: "Marko Zec" , freebsd-current Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related Date: Tue, 21 Aug 2018 13:15:04 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: In-Reply-To: References: <20180821113051.7d35bc39@x23> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 13:15:17 -0000 On 21 Aug 2018, at 12:31, Olivier Cochard-Labb=C3=A9 wrote: > On Tue, Aug 21, 2018 at 11:29 AM Marko Zec wrote: > >> On Mon, 20 Aug 2018 16:26:29 +0200 >> Olivier Cochard-Labb=C3=A9 wrote: >> >>> Just loading carp kernel module is enough to panic it: >>> >>> [root@router]~# uname -a >>> FreeBSD router.bsdrp.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 r338100M >>> i386 [root@router]~# kldload carp >>> Fatal trap 12: page fault while in kernel mode >> >> How many vnets were already instantiated at the time of kldloading >> carp? Does the panic ocur with no (non-default) vnets instantiated? >> >> > Hi, > > None VNET were instantiated: Just start the latest 12-i386 image ( > https://download.freebsd.org/ftp/snapshots/VM-IMAGES/12.0-CURRENT/i386/= Latest/) > on a VM, and once logged as root enter 'kldload carp' to trigger a = > panic. From the backtrace it seems like VNET_PCPUSTAT_SYSINIT() or the kernel = linker, or possible pcpu things. People have recently been touching = almost all of this :( Do you have a last-good revision? /bz From owner-freebsd-current@freebsd.org Tue Aug 21 13:49:26 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 94E891072DC0 for ; Tue, 21 Aug 2018 13:49:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C93E841C9 for ; Tue, 21 Aug 2018 13:49:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id s7-v6so4173754itb.4 for ; Tue, 21 Aug 2018 06:49:26 -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=5di4oiH5ODU1ZY7p99LgKOMhuQ8L8f/2uYlbjVOcQLE=; b=siEWtMCQYmk95A+nGAO09qEfXfGLVVnrOXG4Kei27hC6+CN+Ynp1rZbuVRW085hwPR ZzrOQIzVw81MPy8hfII4uy6qRjRZT742KMuIEUCCZsmAD2wkEplEzWDnsKDsUCYU2vOD moB4AWNfdr11/puTMHzv145ckAHcjr3IQvEMtJwVRrFVzCbhVvv/xTmkZdk1pthojDxX LmdQ4Aak+l4y/HQ3w4vHOlMegmMdsK2SNMDj5bu7XMOOKhiD7/nKgYFKl5k05KmcYHL3 t2wcpwb+xxggM9fBwARlA8maU/eme1UHAteC/9ISMOMVDtsBlDo9fE9BhCCoe5iKy1wS +EYA== 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=5di4oiH5ODU1ZY7p99LgKOMhuQ8L8f/2uYlbjVOcQLE=; b=GnXVAbn/M08hwnL8VZFvTkozLocAoMIoWsEsH/Tm3LQlqJxgmaGRuyyWPgaWXHp3lU FMppW7xKNsgOI/7zKZbw5YH3zYBoIvm8R5HgPMhvzXMYVJejMDckdSJgGHTefltIyF8F EIO4V5j8uAnBzn5mTOD17vCvXvM5fNb3TBJfW7qaEmgsKrVsQdap0QZ5CHWUkfNXlMQy maWgfNmjIGihTnDMF9qSwJNfm710K0YdqoQdGRLldiH3CIgfuD7w5fAUEqG0hnD5FdwA 011d1kzd19V0A/ZVvpwQXYgnkQ1beGLMrAjxBk97LkIDXu3Bb3L1+pT6cLMPU+sR6pKG QPtA== X-Gm-Message-State: AOUpUlHV5z7bzGsFKYl1EZefLYXqJ2LDJA9UQ5C2VDWWvXDBMgiaubC/ /pTslkDps64j9L/EdRAF06gLnRDFya35cPtWktSTYg== X-Google-Smtp-Source: AA+uWPyaplANM+AxXSiEtynyPCIJNs4XBl8uumrRoDGieWQc1NckNzCtE9qXhaDIpyuQ/jJ2QM/rF/55dVCTVyc0L+8= X-Received: by 2002:a24:83c6:: with SMTP id d189-v6mr16829753ite.75.1534859365351; Tue, 21 Aug 2018 06:49:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 06:49:24 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> From: Warner Losh Date: Tue, 21 Aug 2018 07:49:24 -0600 X-Google-Sender-Auth: 8gl1XRRc9yC2IEX2306qTe8LT2g Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: John Baldwin Cc: "O. Hartmann" , FreeBSD CURRENT , Alex Richardson Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 13:49:26 -0000 On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote: > On 8/20/18 9:00 PM, O. Hartmann wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Am Mon, 20 Aug 2018 21:24:21 +0200 > > "O. Hartmann" schrieb: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA512 > >> > >> Building NanoBSD world on CURRENT r338113 fails due to: > >> > >> [...] > >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && > MK_TESTS=no > >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 > >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/ > pool/sources/CURRENT/src/amd64.amd64/rescue/rescue > >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE > CRUNCH_CFLAGS=-DRESCUE > >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/ > tools/build/mk/Makefile.boot" > >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. > Copy the header to > >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused > by Makefile > >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error > code 1 > >> > >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue > >> [...] > >> > >> > >> This problem occured during today's source updates since I was able to > build the NanoBSD > >> image I intend to build yesterday ~ r338060. > >> > >> What is going wrong? > > > > It seems the problem has been introduced after r338095, since r338095 > builds ok, while > > r338096 doesn't. > > 338096 added this check to catch a kind of error in our Makefiles. Alex > (cc'd) can > help with figuring out what the error is. > Except we're not building anything, we're making obj in rescue... It looks like a false positive... Warner From owner-freebsd-current@freebsd.org Tue Aug 21 14:12:03 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 2E63E1073C32 for ; Tue, 21 Aug 2018 14:12:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B57C7854C1 for ; Tue, 21 Aug 2018 14:12:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id d16-v6so11112696itj.0 for ; Tue, 21 Aug 2018 07:12:02 -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=NTAnc2urt+6hcaxE/lmMU6wS8xkCRaT7gyVrZuhilR0=; b=pJKu22ABwED/8a40AYO0rCv07UEyQXB/m3P4527VZgtliDhIcfpRVKFOFbnHndO9Dj 4AixlAdJi95cpD/vHaNt3m7SJpX70X5dbmNDFQr55hwN8Wt/QdcWA9CvgZs1+KsL+U46 c1tj2/2JRLDztftZIRQJ7X4L/NlerI2fLudQrJvi/KErNPvLDtPbUFvOg8/gJPfopzn9 ahSzdY3ITV55o99NTqTdDrwX6glYtY312c+9YHUi6B2HJAHQb9aa2hHGtkLlkohDYpRJ fOYeTGvqDKBfqvn2U1gYvzJ498VJjWk8r8ymeSrzx/2mvkN/futYZ4kKGWCPQVuT48xz 4R2w== 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=NTAnc2urt+6hcaxE/lmMU6wS8xkCRaT7gyVrZuhilR0=; b=KK+9KuX33dzJMWi0QHX67Id/r4pFEoHSH6Nlq/FyC4oiyA+2t9kJKNP9G/27W0boLR pSIkWVUWyJWgCJBS11zWeMcBnuSJPkNrkNqlASbmeHoDwMQvKjNCd9TudvK66p/lKW8O y7Dq4gbNh6hgQkt+f2e5mIdz+GN+fFxY6tLUzf1PTWK0gn0v+WXXnMwNZPb14kpMkmya CThcNhSyvUj0xaopYqrhSRYDKqgirABk4ghmRJQIiMpuOopcZukT3fFFIEZcrXzcyNZO mReosWcmkJDjBNSuc1BMvpeZCcv2VWM/7kqNIVxSw/tL3ynE77I8vjztj5cIpw693Kep 9ePg== X-Gm-Message-State: AOUpUlGNwXuiq2JwmhXCNnk7a7Ki7EQ39crJW+jLxlVz6gLghO4nHC3a kZwclcrxCCu+C3cH2F7nTpO9HKaq5atas7ECC9lhzg== X-Google-Smtp-Source: AA+uWPwUUWw3dVxpxTLdt0pM1EElPnLrUSoSczENq/yqySenwT8pgyB91T9cNaAxPWUhY/5SxPDb88Zp1/eddqB5hUE= X-Received: by 2002:a24:d2:: with SMTP id 201-v6mr17019835ita.60.1534860721931; Tue, 21 Aug 2018 07:12:01 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 07:12:01 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> From: Warner Losh Date: Tue, 21 Aug 2018 08:12:01 -0600 X-Google-Sender-Auth: yLhSXoUW1ApYWZfxsifxN4Sf1Ao Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: John Baldwin Cc: "O. Hartmann" , FreeBSD CURRENT , Alex Richardson Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 14:12:03 -0000 On Tue, Aug 21, 2018 at 7:49 AM, Warner Losh wrote: > > > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote: > >> On 8/20/18 9:00 PM, O. Hartmann wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA512 >> > >> > Am Mon, 20 Aug 2018 21:24:21 +0200 >> > "O. Hartmann" schrieb: >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA512 >> >> >> >> Building NanoBSD world on CURRENT r338113 fails due to: >> >> >> >> [...] >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && >> MK_TESTS=no >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/ >> sources/CURRENT/src/amd64.amd64/rescue/rescue >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE >> CRUNCH_CFLAGS=-DRESCUE >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/too >> ls/build/mk/Makefile.boot" >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. >> Copy the header to >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused >> by Makefile >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error >> code 1 >> >> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >> >> [...] >> >> >> >> >> >> This problem occured during today's source updates since I was able to >> build the NanoBSD >> >> image I intend to build yesterday ~ r338060. >> >> >> >> What is going wrong? >> > >> > It seems the problem has been introduced after r338095, since r338095 >> builds ok, while >> > r338096 doesn't. >> >> 338096 added this check to catch a kind of error in our Makefiles. Alex >> (cc'd) can >> help with figuring out what the error is. >> > > Except we're not building anything, we're making obj in rescue... It > looks like a false positive... > weird, I'm dying elsewhere. You can recreate this with cd tools/tools/nanobsd/embedded sh -c ../nanobsd.sh -c qemu-amd64-uefi.cfg it dies in mkimg. We have LOCAL_XTOOL_DIRS=usr.bin/mkimg so it's building in stage 3. It's likely because of CFLAGS+=-I${SRCTOP}/sys/sys/disk which is 100% legit always by design, so the test in this case is a false positive and must be relaxed. I'm guessing that the rescue case above is similar: we're building an different tool early. Warner From owner-freebsd-current@freebsd.org Tue Aug 21 14:16: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 54D9F1073EAC for ; Tue, 21 Aug 2018 14:16:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAD2085A0F for ; Tue, 21 Aug 2018 14:16:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id g141-v6so4243270ita.4 for ; Tue, 21 Aug 2018 07:16: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=q/gPgnNaEBvSt/wcYHV0vDcc+81MouwEAPPvFMTJoGw=; b=A4Myi/3YYKK/tQJPAsANH6Gqp4SJbgZycKwVSJqCQoJtIbM8HJjg7vAXXhowPExXlw LW0gZXOfyRDUwQKXDEYVU9DX/+c+9h5gQJDP7M/z7h0yXNCzdH20wPLVt1WZpK0UHs4I Upy1Hie2dzXOxnws5f0m4+EkoBTeih04k3576iEqdboLlWN5Y+HwkYlKnimfoHMWH62a yIx1Om7ZOa4QUwy5iD2mS6xkDf7yfK5XkhM1LF0fDG6uFrs9DWmwon1nrv74i6FWmOQr xn64UZm9KYL2qqA8+eQFfC+GBm64t/PRYRxtEDq+c3HZi4BGHK3vMjt/B0/is5Iced+Q XgiA== 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=q/gPgnNaEBvSt/wcYHV0vDcc+81MouwEAPPvFMTJoGw=; b=J6zILzr2e/uQlsjjiK6STLmEx1kDha48DRkfDDR2VyOHQ+Hlwsjezyk1PeeOuN+nT1 045x+ZPOLfh2G+gygulF8h2ASd8ZTuQFrBvOzszTbQTLrZV4IwNrHjueMLXtTzXrICg0 hKgLsx2xFguu5PmBsi19pvH8u4YLUBgL5fohe+ijHoCpBiyqMQ78nrbXf7JV/NxAB6Ua TJhDr7cRD3yW/qG5KJdv1vO3WqVvCiri+EN2jhnopcU4j2FvlAs0kfIZZF/RCgLZho9v B5z/21EVn567KFSE0VuGNupj3+xc1ZLUwPHOSF7Cpij8hvnPx4dJXGJCnx0EzE+6ydMA NzOQ== X-Gm-Message-State: AOUpUlErMIzoEB8T4zPKuRoLTLm9reCUK4rMXQd3V2i/Y6cT9ST812DG 5Rlj6JdI+wA16kdN0o8hS+rv+dzf4stYPeEld9p0LQ== X-Google-Smtp-Source: AA+uWPwohbWG54IPdteM73TGd2uHmUa6OhNsFqd3L5SG+Z6d53zoXI6NK3Gfpyd0+2KNHRpNtOPw69rV0O73KTlktyQ= X-Received: by 2002:a24:83c6:: with SMTP id d189-v6mr16934071ite.75.1534860978181; Tue, 21 Aug 2018 07:16:18 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 07:16:17 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> From: Warner Losh Date: Tue, 21 Aug 2018 08:16:17 -0600 X-Google-Sender-Auth: ObxMXvTmPi4TDUqR_RohOCE2R0I Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: Alexander Richardson Cc: John Baldwin , "O. Hartmann" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 14:16:19 -0000 There's a half a dozen special targets, however. clean comes to mind... However, this test is needlessly restrictive: .if !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*) since it matches CFLAGS+=-I${SRCTOP}/sys/sys/disk which is totally legit. It's designed to be legit everywhere for building on Linux... .if !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto) would be a better test, imho. Warner On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson < arichardson@freebsd.org> wrote: > In my testing 338129 fixed the issue. Seems like the problem is that > bsd.crunchgen.mk iterates over all directories to do a make obj when > it does the bootstrap-tools phase. > On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote: > > > > > > > > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote: > >> > >> On 8/20/18 9:00 PM, O. Hartmann wrote: > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA512 > >> > > >> > Am Mon, 20 Aug 2018 21:24:21 +0200 > >> > "O. Hartmann" schrieb: > >> > > >> >> -----BEGIN PGP SIGNED MESSAGE----- > >> >> Hash: SHA512 > >> >> > >> >> Building NanoBSD world on CURRENT r338113 fails due to: > >> >> > >> >> [...] > >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && > MK_TESTS=no > >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 > >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/ > pool/sources/CURRENT/src/amd64.amd64/rescue/rescue > >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE > CRUNCH_CFLAGS=-DRESCUE > >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/ > tools/build/mk/Makefile.boot" > >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap > tools. Copy the header to > >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was > caused by Makefile > >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] > Error code 1 > >> >> > >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue > >> >> [...] > >> >> > >> >> > >> >> This problem occured during today's source updates since I was able > to build the NanoBSD > >> >> image I intend to build yesterday ~ r338060. > >> >> > >> >> What is going wrong? > >> > > >> > It seems the problem has been introduced after r338095, since r338095 > builds ok, while > >> > r338096 doesn't. > >> > >> 338096 added this check to catch a kind of error in our Makefiles. > Alex (cc'd) can > >> help with figuring out what the error is. > > > > > > Except we're not building anything, we're making obj in rescue... It > looks like a false positive... > > > > Warner > From owner-freebsd-current@freebsd.org Tue Aug 21 14:18: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 1DDFD1074069 for ; Tue, 21 Aug 2018 14:18:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A245A85BB3 for ; Tue, 21 Aug 2018 14:18:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id w11-v6so15538510iob.2 for ; Tue, 21 Aug 2018 07:18:57 -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=njtrCFOVWs9FLAxRm2lSsJ58AK9ALY5Sz3fXfvMy6cI=; b=vlH542LPRd747g+RQLTzfAp4xgnaCWV2TyxJfVE6GZbuyVto9mOzAOJPGMIgeoGNMy 2tPsXWWFDXFj10QzyR2HWdn2C5zOddGTMRu3BXwjaxZxACXe9JxICbjegbNmQ90KmEfN fq/lcCWMwGFm28fjsxoWI7Rg+vnJ+X5vN5lKvB1yuKuinhat7XeRTWrKTk1UWuGLX62o tGYF++bbD19cIHm/oYnnenlQcrJWr4ILP9cQ6+pG7PiE3N18VFs4UxOHjZ9B9wZsZOcO lVYF0k4i0iKuHMbgY3pcmRKInCtZZJietF8yP3pjx4x4z+JmxxWzaPJAZO3tqEEpPA48 rSqA== 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=njtrCFOVWs9FLAxRm2lSsJ58AK9ALY5Sz3fXfvMy6cI=; b=c4sY9SVMLICUsl1J+9z/qTYt8NF26U2ouDKomW3BPsRWREk5QNRd/9cCth+LWLPT6R WB/2qtrzhG9d87Z51oVQk/6oiykNb+zdZPlcpeFX6p1FxmTCRBdLEYXWFEgqY3cIYo+V 7lDc80g4Xi2Jf8BpvKebVPKuFeE+1WcOvlYlfk91W8EM+MdgoFJxNUl5GNqo9gXYfvx+ n7NmfMGlNMyCp0FX19zfrGzpKvW3mVC7/eX1j2D+y81wdsdN/dCi1hICBrPITANgvkeT EBxheEiAeQ4/mXS+hFE2SeaE+a1godQVYtO1uPLgh2pDrqQsLg3faOERRmCl17m34lap liFA== X-Gm-Message-State: AOUpUlGei6YLQ+6V3e7L0AWL5x9aolHNglWMfogSz9XW6PIMeEAhY+qb DfOp9VVmGywo4/+bZ45u0EC9KKENzIGtkeiUl49biw== X-Google-Smtp-Source: AA+uWPzuDjWbKN50ooemC56BzsQDapi6mW1Q/JFiNwbq2KTyQeLE7AS26APGJuJk+1Wv2lkYSbQmfXBODpQhTlcRZjM= X-Received: by 2002:a6b:7117:: with SMTP id q23-v6mr26262199iog.37.1534861136940; Tue, 21 Aug 2018 07:18:56 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 07:18:56 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> From: Warner Losh Date: Tue, 21 Aug 2018 08:18:56 -0600 X-Google-Sender-Auth: I8xKhDjDuYNur5A3FNBhIG88XgI Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: Alexander Richardson Cc: John Baldwin , "O. Hartmann" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 14:18:58 -0000 On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote: > There's a half a dozen special targets, however. clean comes to mind... > > > However, this test is needlessly restrictive: > > .if !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*: > N*${SRCTOP}/sys/crypto*) > > since it matches > > CFLAGS+=-I${SRCTOP}/sys/sys/disk > > which is totally legit. It's designed to be legit everywhere for building > on Linux... > > .if !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N* > ${SRCTOP}/sys/crypto) > > would be a better test, imho. > Although, I could passively agressively work around it with CFLAGS+=-I${.CURDIR}/../../sys/sys/disk which also kinda defeats its purpose... Warner > Warner > > On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson < > arichardson@freebsd.org> wrote: > >> In my testing 338129 fixed the issue. Seems like the problem is that >> bsd.crunchgen.mk iterates over all directories to do a make obj when >> it does the bootstrap-tools phase. >> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote: >> > >> > >> > >> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote: >> >> >> >> On 8/20/18 9:00 PM, O. Hartmann wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> >> > Hash: SHA512 >> >> > >> >> > Am Mon, 20 Aug 2018 21:24:21 +0200 >> >> > "O. Hartmann" schrieb: >> >> > >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> >> Hash: SHA512 >> >> >> >> >> >> Building NanoBSD world on CURRENT r338113 fails due to: >> >> >> >> >> >> [...] >> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && >> MK_TESTS=no >> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/ >> sources/CURRENT/src/amd64.amd64/rescue/rescue >> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE >> CRUNCH_CFLAGS=-DRESCUE >> >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/too >> ls/build/mk/Makefile.boot" >> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap >> tools. Copy the header to >> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was >> caused by Makefile >> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] >> Error code 1 >> >> >> >> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >> >> >> [...] >> >> >> >> >> >> >> >> >> This problem occured during today's source updates since I was able >> to build the NanoBSD >> >> >> image I intend to build yesterday ~ r338060. >> >> >> >> >> >> What is going wrong? >> >> > >> >> > It seems the problem has been introduced after r338095, since >> r338095 builds ok, while >> >> > r338096 doesn't. >> >> >> >> 338096 added this check to catch a kind of error in our Makefiles. >> Alex (cc'd) can >> >> help with figuring out what the error is. >> > >> > >> > Except we're not building anything, we're making obj in rescue... It >> looks like a false positive... >> > >> > Warner >> > > From owner-freebsd-current@freebsd.org Tue Aug 21 14:19:31 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 898B510740B5 for ; Tue, 21 Aug 2018 14:19:31 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F130585C3A; Tue, 21 Aug 2018 14:19:30 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.25.88) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 21 Aug 2018 16:19:25 +0200 Date: Tue, 21 Aug 2018 16:20:51 +0200 From: Marko Zec To: Olivier =?ISO-8859-1?Q?Cochard-Labb=E9?= CC: "Bjoern A. Zeeb" , freebsd-current Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related Message-ID: <20180821162051.4fd0f1eb@x23> In-Reply-To: References: <20180821113051.7d35bc39@x23> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.1) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/4Myh3kMKzIkherxz0vVdmsw" X-Originating-IP: [31.147.25.88] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 14:19:31 -0000 --MP_/4Myh3kMKzIkherxz0vVdmsw Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, 21 Aug 2018 13:15:04 +0000 "Bjoern A. Zeeb" wrote: ... > From the backtrace it seems like VNET_PCPUSTAT_SYSINIT() or the > kernel linker, or possible pcpu things. People have recently been > touching almost all of this :( > > Do you have a last-good revision? Perhaps the PCPU area is overflowing? Maybe increasing the UMA_PCPU_ALLOC_SIZE could make the panic go away (this by no means should be considered a proper fix)? Marko --MP_/4Myh3kMKzIkherxz0vVdmsw Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pcpu_overflow_hunch.diff" Index: sys/sys/pcpu.h =================================================================== --- sys/sys/pcpu.h (revision 338128) +++ sys/sys/pcpu.h (working copy) @@ -219,7 +219,7 @@ #endif #define curvidata PCPU_GET(vidata) -#define UMA_PCPU_ALLOC_SIZE PAGE_SIZE +#define UMA_PCPU_ALLOC_SIZE (PAGE_SIZE * 16) #ifdef CTASSERT #if defined(__i386__) || defined(__amd64__) --MP_/4Myh3kMKzIkherxz0vVdmsw-- From owner-freebsd-current@freebsd.org Tue Aug 21 14:23:08 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 7057E10743B7 for ; Tue, 21 Aug 2018 14:23:08 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-yw1-f50.google.com (mail-yw1-f50.google.com [209.85.161.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 106D38607B; Tue, 21 Aug 2018 14:23:08 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-yw1-f50.google.com with SMTP id q129-v6so8163568ywg.8; Tue, 21 Aug 2018 07:23:07 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R77pVYE/uP4S83dnG/zgelIEbWKgJw7EGliyuYZ/QDA=; b=N/vbZcBq9GmCqLhsyTB1r2zSxNiXIFiXgzH6jJFbt/KbG34JnBsskOrK0fSeicVWcv DgwMBslf9eYNU9q82vhyerVWLCAxt5FtivRgyvyQr1AeLG3PysHOY6I6UkESF8/p3Ihb M39ThMTZNuG7ORXzYR1gTESlREeT7kKLbrAPFvQzmrbvkruUdUm114/JjBYRgudRE2pp GKJMJ/QMG+obUw2oGNzh34/r0OUvyvQf4TedfG0l0faf+GcPtqBloYfVe2+CNtKkA9dQ LI+z06HrxeZqPq8eAXHBNmawrozPqz4gf6H5IkAIRdNb+RPFBW9W0HtpyuwAr5Mc39n/ aEwA== X-Gm-Message-State: APzg51B/aappL4zAIdSuQJvq821ox1t77tO9hPI9P22H90fkVqpSD/uq +D+3G9+YmF93n47NGJcabThZLFG+YcbbSg== X-Google-Smtp-Source: ANB0VdaI8wztr4KnexI2zwgBnWI0SbuwjAnGt4YvOFD+Ws4sn1/3ecu1ZyOQvIXB4pfNF8lY7XzJOQ== X-Received: by 2002:a81:7184:: with SMTP id m126-v6mr1811627ywc.319.1534861387125; Tue, 21 Aug 2018 07:23:07 -0700 (PDT) Received: from mail-yb0-f173.google.com (mail-yb0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id b135-v6sm11435070ywh.24.2018.08.21.07.23.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 07:23:06 -0700 (PDT) Received: by mail-yb0-f173.google.com with SMTP id f145-v6so3834010ybg.4; Tue, 21 Aug 2018 07:23:06 -0700 (PDT) X-Received: by 2002:a25:d985:: with SMTP id q127-v6mr27110721ybg.260.1534861386649; Tue, 21 Aug 2018 07:23:06 -0700 (PDT) MIME-Version: 1.0 References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> In-Reply-To: From: Alexander Richardson Date: Tue, 21 Aug 2018 15:22:54 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: Warner Losh Cc: John Baldwin , "O. Hartmann" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 14:23:08 -0000 I think relaxing the check to just avoid includes of "${SRCTOP}/sys" is probably the best solution. It would be nice to also handle the ${.CURDIR}/../../sys case but since it's just there to prevent ABI issues that's probably fine. Alex On Tue, 21 Aug 2018 at 15:19 Warner Losh wrote: > On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote: > >> There's a half a dozen special targets, however. clean comes to mind... >> >> >> However, this test is needlessly restrictive: >> >> .if >> !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*) >> >> since it matches >> >> CFLAGS+=-I${SRCTOP}/sys/sys/disk >> >> which is totally legit. It's designed to be legit everywhere for building >> on Linux... >> >> .if >> !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto) >> >> would be a better test, imho. >> > > Although, I could passively agressively work around it with > > CFLAGS+=-I${.CURDIR}/../../sys/sys/disk > > which also kinda defeats its purpose... > > Warner > > >> Warner >> >> On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson < >> arichardson@freebsd.org> wrote: >> >>> In my testing 338129 fixed the issue. Seems like the problem is that >>> bsd.crunchgen.mk iterates over all directories to do a make obj when >>> it does the bootstrap-tools phase. >>> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote: >>> > >>> > >>> > >>> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin >>> wrote: >>> >> >>> >> On 8/20/18 9:00 PM, O. Hartmann wrote: >>> >> > -----BEGIN PGP SIGNED MESSAGE----- >>> >> > Hash: SHA512 >>> >> > >>> >> > Am Mon, 20 Aug 2018 21:24:21 +0200 >>> >> > "O. Hartmann" schrieb: >>> >> > >>> >> >> -----BEGIN PGP SIGNED MESSAGE----- >>> >> >> Hash: SHA512 >>> >> >> >>> >> >> Building NanoBSD world on CURRENT r338113 fails due to: >>> >> >> >>> >> >> [...] >>> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && >>> MK_TESTS=no >>> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >>> >> >> >>> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue >>> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE >>> CRUNCH_CFLAGS=-DRESCUE >>> >> >> MK_AUTO_OBJ=no obj make[5]: >>> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot" >>> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap >>> tools. Copy the header to >>> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was >>> caused by Makefile >>> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] >>> Error code 1 >>> >> >> >>> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >>> >> >> [...] >>> >> >> >>> >> >> >>> >> >> This problem occured during today's source updates since I was >>> able to build the NanoBSD >>> >> >> image I intend to build yesterday ~ r338060. >>> >> >> >>> >> >> What is going wrong? >>> >> > >>> >> > It seems the problem has been introduced after r338095, since >>> r338095 builds ok, while >>> >> > r338096 doesn't. >>> >> >>> >> 338096 added this check to catch a kind of error in our Makefiles. >>> Alex (cc'd) can >>> >> help with figuring out what the error is. >>> > >>> > >>> > Except we're not building anything, we're making obj in rescue... It >>> looks like a false positive... >>> > >>> > Warner >>> >> >> From owner-freebsd-current@freebsd.org Tue Aug 21 16:23: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 4865E1077837 for ; Tue, 21 Aug 2018 16:23:02 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 950C28AC01; Tue, 21 Aug 2018 16:23:01 +0000 (UTC) (envelope-from alexvpetrov@gmail.com) Received: by mail-lj1-x22e.google.com with SMTP id p10-v6so14791824ljg.2; Tue, 21 Aug 2018 09:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:cc:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rYHodIpVZU9PB06EJZw/inTnon+mxHly48coFVxmywY=; b=TncYX86SWZ4b42RT5ZCprAvqu3cJRKN+nMzhBSFf9xXPCRFYa3CZ6gMTfqi8mk2tM8 GuruUCsy4tL3VnfZf897D3Fi1ajy7AbWEAADQovC4ocl1BCQHWO3m8d9WOn64cjubxsz uVu6p8Ac/QLPvqwI8iM6+tE+nfBVW+taG64l3Pot6jkJ4f+rl7CGUfw438Rvv8XGM04k T3lcPsi4518bTWGFUnSvTwmhnrLQFMGtjzcDllH29yZnqaaqFyd/T38sC4cB0fygJzHo qnPBXsu9und2RAl8rMMsT6wG36otqCT7NfGwoscG7bJxWmMSBTLuq9k7FqLU5/aJd0Ri scvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:cc:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=rYHodIpVZU9PB06EJZw/inTnon+mxHly48coFVxmywY=; b=PiUAVzF15H93hScFDaqMXhd2dSsNtrzzSP3oFQcHbbeu/oZ3vt/qK7VPJLeu51yC48 qCdTTEO9yXY+1zyOrZu/0tbiKHffFD3pAw6Zwqot3aWa2F6thNaWzmAbOgvOIYC8dL0Y i667Iz/mO27O04Jb3edBWHPmBFyU3ULyfpOyZQQsT3H5HCq+uJ1Ib5VDVEO6md6XcZZG lWPX0sg9MmkNRDGbVu+vqjPP4t7bsKvGKksd2IL1qsc60y9o1d0zwz54BrQL5yBZDmGo 3VGh0an2lSqwXENHVRacGqV0n0NOEIxo5oudNcOZSajTcYIdLAYqrLttfMhimhb0pDuS QgKA== X-Gm-Message-State: AOUpUlGKql3WbQ0UTX4lhu1Bevn0RuMfe8PKWrZPb5/5VyrZLWw45tI3 ousWbcLTC64vUELNCTr0ddhWa6kc X-Google-Smtp-Source: AA+uWPxzpW7itfM6eKMPuntdrfjPpukcTydDIy82g3dvcYKoMHuGiJJuzDEthqOwGqNIXvQF+SpN9w== X-Received: by 2002:a2e:259:: with SMTP id 86-v6mr36500932ljc.107.1534868579248; Tue, 21 Aug 2018 09:22:59 -0700 (PDT) Received: from alex.super (stone.g-service.ru. [84.22.141.217]) by smtp.googlemail.com with ESMTPSA id f74-v6sm2386713lfg.61.2018.08.21.09.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 09:22:58 -0700 (PDT) Subject: Fwd: nvidia-driver build error (last ports, FreeBSD-HEAD) References: To: freebsd-current Cc: Alexey Dokuchaev From: "Alex V. Petrov" Openpgp: preference=signencrypt Autocrypt: addr=alexvpetrov@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFr3oA0BEADMSXiVd/IwYhJPMQ6LXbZ7jTA/RXuzrGYaR++UENx5QJ6/HJ/3myTeMnZE nNa0Zme+oKw/9s5x7rBTP6mL5ta7VSYpnPX932mAjT9J4nS7iW/wWNBqcXn7wDCog2TV8Ww3 13SUP2YaKoJKJLxddiZD6AJrkafB9EE/AycMQ8XxMao1lVS+/KAo0yciOsnSlIJCWhF00b3j xDlHLvehrDa4S3EB13bF6uE0XU5nFfMNHtBav2mwD9t01hNioCNTV1hXwmsS/L1n5PR5FyJJ yYtjeohrAUiGKGJU9lJJ6tROBhzV/k3OsOGPyajFOVsW0vUueYfgw+IAPYdOZIAONgNdxkvs tRLQxYPCBMN1FvQ7GlIhq7ob+mxuA1imXx3xzlYy5tu4QzB383qZtLqQnZpysjYooAbHl+eN vB2ldvH9TZxm3fxxNL6zgYAXE/pNgFoqg/ILmhDwvvHzApHqVCKU3g6yii0KPxD7susaUWcL JYgrmt2BIE0RuiQRGWyS0L277D/YGmVnPNHxPi58DBs2iexDm7jw7PhlmfOw44N9w+O09D2S gqmBHySAtsq9Z5LoM81F+LrOoVmpYczZWErS917Gua1X7K3wrXoqQC8qcSiHZpEcBl/Uohii QWzjQJot5LT7rvfFHpnSOXAKgN7enVM7KxTJAYK1U343GGdepQARAQABzTZBbGV4VlBldHJv diAoZmlyc3QgZ2xvYmFsIGtleSkgPGFsZXh2cGV0cm92QGdtYWlsLmNvbT7CwY4EEwEIADgW IQRvKPTT2TJuh37ANx313p8aVpVkcAUCWvegDQIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIX gAAKCRD13p8aVpVkcLLeEADClYAElEInGGjtLfH4jdjvTDaQTsrwT5/1E5/h8yxI4yn7hCt1 Dh+iCSUNLdPO88nZV2jP8bMQXFBKSbC0nAJXd8O+8t9AfSWoUC6IMzncxKTK/jZuJTCToCUR XZ+47+uJaBp51rpw3pFX8UrFlYSF6Dz97dI2cGHfx3xAOnowKxyHfthxS8waKWgbMOceds78 BP2+Q0iLCpoC9rO4KDc+w+h8z21eHIE9VHadTHpnKVF82voPH8XWvznTOCpYrdBwUtIyD/DV XRb0xcFsOSkvmReYX7u4QuOPLSc86sEWh4hXTFLAOdfeTjrDTDmBcmFpltmW1j+5t4mI1dK8 gptREM8gMJVJw3jjcO6jADeXX9q5C8/lX0sEGz9uC4oU5nkOMyfzd9Anb+9bCs7pMxhqAKjA 8tqJPPkmJU8WzMCs+uudIiQ8W9qIETwUJWxizQ3kvlzLfWRz5n93Y9kzSmjw81aiIJK/HFY8 wsW5zNo6JBn57cMPx8nBC4E2zM09ffmqSpjDwXfvZF2IIR8L4VTiKi3ovwLglJP+Qbs5HXNn 6K40cPNqfnHzPLwXwd/co04B/VVr+cKZuE58kYGty9Xs9q/SEpObDnxnLxMNHUNJJuRgOiti TKDkteHuKm6NA8v05o3TDQ5HU9szEoE5uoi/3pQ1ktfA/K3LkDwbotXL+87BTQRa96ANARAA w5+/xcaCP6iwsi2CFQ4pAWksdmPBEHA2VPn1ym3C6opjbyWUp6sn25eTWppdhA9rUqbM/zV/ hAFRT67oZJKBYNRaMoDdO8BsVZsg/u76QF/GuhbUjIk0tFFdpddMXl0zKAJJMCfDRxURRWv7 NW6sY/EZ4Dal5s4xOT+UrWGag3qoaIRdzw5bJRP+o75L90cE8pd7+Pd9cVJOOtTAwx0E4bPq dPSa6CPDSvzd9D3mw37dPzXysyQkQTy0OM7255E2wjYz3RbJxB3utybPVN3XJBD5EyA8IYeS ic1/03UrkRNv4XrLnlg7xLv96ZeCrf/BDNQW23iVwbISUAk4TXL7xs2TGYOmowZ89mMEcbfW ChX3YLAuAeWzgpMcrDC00izOxG0spkkrHL7/i1iSu2MKhv5qMTVgchlSktdd+KTba5keleHv ULQ3feGUKf9eTkKgES6q4rKrae0tIwByTLhhDVbkXqR6v8zrpJSscrvJ3tMNgquJKy5ATIUB nvUE2hMkSwtnJ2vQ/Z0zGt6c5KxI57/hsb148tXp1v3gAq9d6i8c8ChxSR/kUlqAvzl2QGcn CFVN6nfOzyNfBPZ61abNzkzjzyhOK4Gq4gQvx4QXhDp3jEME7rPM0Tqf0venb1Dp7SIHwggV yJglGApwoUvD4kKNIC7KDr+s/UjbBp4ExFMAEQEAAcLBdgQYAQgAIBYhBG8o9NPZMm6HfsA3 HfXenxpWlWRwBQJa96ANAhsMAAoJEPXenxpWlWRwAaEQAKm0imG5Fm37JZi+5faXJv/ZLZGl r4TVg4u1kMktdTQRrTXa3Qs0i3wTtOZe1p3xCCzPx+97iYETHragDTdAFUO+v+Llin26L1Zl z4huyIqgGSuTuekQfn6eoMZbcF+wzah4j/mvXQVpJBF2qQi1YdHSapWDlweuiuk01y8C3eHv 3qfFB/OJwXhwj0HKhkGkB2dLXuLtIk4GCXh4/g22tWz/SB0gsSXU7WhJFb0CyxETGR9YKxM8 CNl5tVRLqsBC6yQLvcAJgJci73PfMiHKnjxrz//+0xQO1TPeruWsd8nLYvziT38CyX42Mbaj 01WpvB0qOeTGtwGFmyyrnE8fYpd3CE0uAl9BnHqafAabl9+09x3wf+lEkkO2bK59akZz3BPU 8Lz2BAgskyS81WZCthQYUrUozFEx/31x8JJ95EQFNW9t8HBa51r4QhedSNKxLbT3Sx8hH0iq Z8wYkGw0og9U1DqgFzxE2HSGZSDG3I1DrPDqhcM/6Y0V98wS+XreuS88DYYck37+L7bTGiyZ WYFNZk1ChcIBk8hgKn5nFOCWO2rX06RI9zorzSpEg6lB2STae1Up5oEj8QqfYmfO3cp2Qhvj F3c2/i8KpWkJQkAgNrv428FIlx9SiPu9gvNTTYuLIOdZLQvInTmKs2uCoB6JDAW75axDhBbR FvM3Vpv/ X-Forwarded-Message-Id: Message-ID: Date: Tue, 21 Aug 2018 23:22:56 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 16:23:02 -0000 -------- Перенаправленное сообщение -------- Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) Дата: Tue, 21 Aug 2018 16:41:42 +0700 От: Alex V. Petrov Кому: FreeBSD Ports cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-co mpare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno- common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.nvidia_subr.o -MTnvidia_subr.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 -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-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_subr.c -o nvidia_subr.o nvidia_subr.c:1131:41: error: too many arguments to function call, expected 7, have 8 sc->dma_mask, PAGE_SIZE, 0, attr); ^~~~ /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, ^ nvidia_subr.c:1269:45: error: too many arguments to function call, expected 7, have 8 sc->dma_mask, PAGE_SIZE, 0, attr); ^~~~ /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, ^ 2 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia *** Error code 1 Stop. make[3]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src *** Error code 1 Stop. make[2]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 *** Error code 1 Stop. make[1]: stopped in /usr/ports/x11/nvidia-driver *** Error code 1 Stop. make: stopped in /usr/ports/x11/nvidia-driver -- ----- Alex. From owner-freebsd-current@freebsd.org Tue Aug 21 17:00: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 050AA10789B2 for ; Tue, 21 Aug 2018 17:00:01 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: from mail-yb0-f175.google.com (mail-yb0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B4928C38E; Tue, 21 Aug 2018 17:00:00 +0000 (UTC) (envelope-from arichardson.kde@gmail.com) Received: by mail-yb0-f175.google.com with SMTP id v13-v6so4759493ybq.12; Tue, 21 Aug 2018 10:00:00 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zpa3j8g8izUToc5DlMe0Gh60LJRnT/qsjDqhQBB79Xc=; b=m3uJZQg4xFOGordRgktyz4fxsHuxF3FqJCTmD3+fJU7Tr99x3wpFVl9sWquHpLsS4o sIA7ZGlLxoTB/ZaaTGORT2ZNpXblvt6VaETWAT2QMXMzVVQsPyVeDt4tCpSkJILGyHK7 kpnBuosasEak+wK9iKogrW0us+OjhKCImXrgNhej6WDnCFjrJq013JT1CcKGiDLQWm8g jonCn/OL1RtT/WRCs+1altRyJN5dLrUZ8jo4nxhtazjZAbZYyF5XJbGtf7rAca0wkrxq 86Dy2AVltpqhypAcgw4C5YZ8NQynnPsqabJmlreQTsyGiX0iuxQUnd0YxSxPaGOv0AKp Bvug== X-Gm-Message-State: AOUpUlEVR0CxLi2MUjJZGFjn3bih1Ov2cgpVsthfcm3Os4yCv2bE5L09 6DM52ZnMCte15hLnI0wW9J5PvHBeNtqdgg== X-Google-Smtp-Source: AA+uWPxHxscCV/9QNypY/jqkb9MTNx1lpAFnR1XmHUcEpoxfhJhnMDvje9MGZVHRlKCZ5W5TdrE4JA== X-Received: by 2002:a25:c382:: with SMTP id t124-v6mr21832597ybf.130.1534860703953; Tue, 21 Aug 2018 07:11:43 -0700 (PDT) Received: from mail-yw1-f52.google.com (mail-yw1-f52.google.com. [209.85.161.52]) by smtp.gmail.com with ESMTPSA id l127-v6sm5734188ywc.5.2018.08.21.07.11.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 07:11:43 -0700 (PDT) Received: by mail-yw1-f52.google.com with SMTP id 14-v6so737108ywe.2; Tue, 21 Aug 2018 07:11:43 -0700 (PDT) X-Received: by 2002:a0d:e9c1:: with SMTP id s184-v6mr28316590ywe.506.1534860703372; Tue, 21 Aug 2018 07:11:43 -0700 (PDT) MIME-Version: 1.0 References: <20180820212448.571e1060@thor.intern.walstatt.dynvpn.de> <20180820220103.3ac8a3ac@thor.intern.walstatt.dynvpn.de> <6040ed15-143f-9a6d-8f37-b25a7e2d2036@FreeBSD.org> In-Reply-To: From: Alexander Richardson Date: Tue, 21 Aug 2018 15:11:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools To: Warner Losh Cc: jhb@freebsd.org, "O. Hartmann" , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 17:00:01 -0000 In my testing 338129 fixed the issue. Seems like the problem is that bsd.crunchgen.mk iterates over all directories to do a make obj when it does the bootstrap-tools phase. On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote: > > > > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote: >> >> On 8/20/18 9:00 PM, O. Hartmann wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA512 >> > >> > Am Mon, 20 Aug 2018 21:24:21 +0200 >> > "O. Hartmann" schrieb: >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA512 >> >> >> >> Building NanoBSD world on CURRENT r338113 fails due to: >> >> >> >> [...] >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1 >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE CRUNCH_CFLAGS=-DRESCUE >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot" >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. Copy the header to >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by Makefile >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1 >> >> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue >> >> [...] >> >> >> >> >> >> This problem occured during today's source updates since I was able to build the NanoBSD >> >> image I intend to build yesterday ~ r338060. >> >> >> >> What is going wrong? >> > >> > It seems the problem has been introduced after r338095, since r338095 builds ok, while >> > r338096 doesn't. >> >> 338096 added this check to catch a kind of error in our Makefiles. Alex (cc'd) can >> help with figuring out what the error is. > > > Except we're not building anything, we're making obj in rescue... It looks like a false positive... > > Warner From owner-freebsd-current@freebsd.org Tue Aug 21 20:29: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 86D8D107E7FF for ; Tue, 21 Aug 2018 20:29:45 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 31AC595339; Tue, 21 Aug 2018 20:29:45 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 333015A9F13; Tue, 21 Aug 2018 20:29:44 +0000 (UTC) Date: Tue, 21 Aug 2018 20:29:44 +0000 From: Brooks Davis To: Dimitry Andric Cc: "Rodney W. Grimes" , blubee blubeeme , FreeBSD Current , Brooks Davis Subject: Re: building LLVM threads gets killed Message-ID: <20180821202944.GB83826@spindle.one-eyed-alien.net> References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 20:29:45 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote: > On 20 Aug 2018, at 16:26, Rodney W. Grimes wrote: > >=20 > >> On 20 Aug 2018, at 05:01, blubee blubeeme wrote: > >>>=20 > >>> I am running current compiling LLVM60 and when it comes to linking > >>> basically all the processes on my computer gets killed; Chrome, Firef= ox and > >>> some of the LLVM threads as well > ... > >=20 > >> It is running out of RAM while running multiple parallel link jobs. If > >> you are building using WITH_DEBUG, turn that off, it consumes large > >> amounts of memory. If you must have debug info, try adding the > >> following flag to the CMake command line: > >>=20 > >> -D LLVM_PARALLEL_LINK_JOBS:STRING=3D"1" > >>=20 > >> That will limit the amount of parallel link jobs to 1, even if you > >> specify -j 8 to gmake or ninja. > >>=20 > >> Brooks, it would not be a bad idea to always use this CMake flag in the > >> llvm ports. :) > >=20 > > And this may also fix the issues that all the small > > memory (aka, RPI*) buliders are facing when trying > > to do -j4? >=20 > Possibly, as linking is usually the most memory-consuming part of the > build process (and more so, if debugging is enabled). Are there build > logs available somewhere for those RPI builders? >=20 > I have attached a patch for most of the llvm ports, which sets the > LLVM_PARALLEL_LINK_JOBS CMake flag during the configure phase. Committed in r477756. -- Brooks --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbfHY3AAoJEKzQXbSebgfA0+8H/2/Q593VOg1Z5wCWTFd2cKtv joOCb1KbhGLQ+BZjsecFAtCtmPXZOrsHZLPq/7+moC1iGFNMLZkLK5S0HvZgvw0Q qnFj07YS4hdYazBUejuykG0WXphLh8p3kl0fwTANixGxGRNwAtaboIhy1NeuR36Y oog61CGsAr+1WOLewpL7EvdaTi3k5ndrkZZIrnvTf66SIxQoCUflQJoFYpdhFvu/ TKcmraerENj+xqu73saEJ5pOBOB+EllV1q60V7QCVlvKpFKokcbRkpJqbVWdh3JT p3iq98U15/IHvyVpFQlpescYTby/RxN5mzt+5kF3mEGUGwbs3VMgXCeE9ExA/gk= =dmt8 -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From owner-freebsd-current@freebsd.org Tue Aug 21 23:32:05 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 A095A1082CC2 for ; Tue, 21 Aug 2018 23:32:05 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21BC273983; Tue, 21 Aug 2018 23:32:05 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pf1-x42d.google.com with SMTP id e13-v6so50327pff.7; Tue, 21 Aug 2018 16:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zc974/cN/A4SBwKFFhZM0euP3hWD8X7ohss3QpIQQFM=; b=VM1arOuGn/EQ7vat5PerzBv3V1WyhBRP/lIbFd60bqmD/5qUc3GubtrBRe1l4wWddP XH0VuohaibYGCS5M7oWQi0mwB/MfXa6RWXOiBCVnzsyeAw3fFfNNCcG2aEkn9c561qzu Cot7xHEd2qyouN/V+/7PcM23yk6l5KSM1jPVcai6glLRQr6wWO0Qq5XN5vKWvJBUwxiR 7LiElQQHhev2tdtbOyVD2G6yIvBM/qsOzjgnP0IMoRhwDO9MDbBlEjJxjvxhDl/Jha1Q vL+DezNXQ6qSRJxFfvdFcSx2t3lKMol0ClyH/+c4K1fzgh3/CaDY7/33GhIKJnfQ65hz yXQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zc974/cN/A4SBwKFFhZM0euP3hWD8X7ohss3QpIQQFM=; b=WB3NX6Dvtdj/NsDknBY8LCIsii4wyK04h/yZE7JxYNRCmmZ08mcbzlgTAvOIH0uewu TeXBnj6OYtMRe/FynpEYNAqFJZAqj0/g1511TJX1dr7/fq6Sts+MxqZsu7zSJUDs5V3p Dd6Mo7hZA1H8X9kCC4P5+OiIkoBK1sEnjpdmnDNuU3M7TvzauDZd/nqdG6Ci7VgdjdXG OTJZbiSNp5ggbyhH/G309sjzhGffVCCsTM7XDB/8l5EHQw5ewogooId/s9jgH5JE03Ho ewoqGatFnVcFEIp8NP+jK+w4Zx0tH0a/zufDVdUTdKn2rSu+/RsJU9l+i65TXYzu8wjg 6r3w== X-Gm-Message-State: AOUpUlFfJ77jGWoMETNGDpZImwzPu7SqlRuVLDSqOzUSgPTGd/rllf96 mmCFa59l48v6CSc1Pda8L6q5qHfsesKpzGF3RrKZmI8y X-Google-Smtp-Source: AA+uWPwbalNiVs1/gke0Cn4MJcQRs5el0DzjlbM+0EEMAMwvIhCll7xk+fE1x60kKkBoeMzGeY8YpucjZN0ixRYpw14= X-Received: by 2002:a62:8913:: with SMTP id v19-v6mr55405085pfd.127.1534894323784; Tue, 21 Aug 2018 16:32:03 -0700 (PDT) MIME-Version: 1.0 References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> <20180821202944.GB83826@spindle.one-eyed-alien.net> In-Reply-To: <20180821202944.GB83826@spindle.one-eyed-alien.net> From: Samy Mahmoudi Date: Wed, 22 Aug 2018 01:31:52 +0200 Message-ID: Subject: Re: building LLVM threads gets killed To: brooks@freebsd.org Cc: dim@freebsd.org, freebsd-rwg@pdx.rh.cn85.dnsmgr.net, gurenchan@gmail.com, freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 23:32:05 -0000 > And probably running ZFS, which ate all your memory and > put you in a memory contrained environment. That's exactly why I keep the following in my /boot/loader.rc: # vfs.zfs.arc_max=1073741824 vfs.zfs.arc_max=2147483648 # vfs.zfs.arc_max=4294967296 From owner-freebsd-current@freebsd.org Wed Aug 22 00:01: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 752F91083E9B for ; Wed, 22 Aug 2018 00:01:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670080.outbound.protection.outlook.com [40.107.67.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1764674F36; Wed, 22 Aug 2018 00:01:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM (52.132.44.160) by YTOPR0101MB1900.CANPRD01.PROD.OUTLOOK.COM (52.132.49.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.23; Wed, 22 Aug 2018 00:01:57 +0000 Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127]) by YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127%3]) with mapi id 15.20.1080.010; Wed, 22 Aug 2018 00:01:57 +0000 From: Rick Macklem To: Matthew Macy CC: freebsd-current Subject: Re: panic excl->shared for an AF_LOCAL socket Thread-Topic: panic excl->shared for an AF_LOCAL socket Thread-Index: AQHUOBRM4+qxEJX+P0ebgxfNDW4pUKTHvz0AgAMlndk= Date: Wed, 22 Aug 2018 00:01:57 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1900; 6:JquWGld4q/TnV3KNqVkz6LzFnb8C+aa7834dQ+8v5IYhzz77Tj7sIk4degvW+RcxkH/sxHW0SuBPPUwygbwStiITyrTXKwqFhcHw8z4iX1w84QkXj+bUksJH/6pmDEAWDAKqO6efaPVP1WD+873Nd2GS1JS8gXXapiVG3wHCa9jATCS4OrW8LGIezC+84dS3OkJssMSFYzpGQ5o7pmpGQKXTjvO2xi/OMT/q7rVieVg+5/tP/DrOWF1ExjmOOuEp3eud35E4U+0XAfnKiRUSAHC8o1zeqFpBBd0HS1pY1yigM9bgRHhClkv834PA6wtdBc18hbDJVJ1+C2hXjVV8GVa7SiLdzZVs3HSQv1w03XZFm/22zhgiCOoMMLzyRLWWSI8JRxnzvsX1k4fwM9ac3NQDXm13yH/kvkcv5oX0pYL32bvunO/3OXSt2NExLpUVP6R7TvT0IqXP0cftfu5srg==; 5:NnguWa+eWByEg1ESVnPG4rktk0FWr3dzVFPIh/3InvxqExr+YP97XICh2Zx2cxYEFnbFGRCFBYeWVXhZu6VCmQtQQLYP5PLTm+Qx/XDFev2YMmMlVeS88TQLpyOKrEGAZPKiUz6BHJIWSCGNXqzT10eHj9glqbUcMwfrhuwLHL8=; 7:2tjxVbuaDBZm8+GbwzI76sZETxYvA36rKYj9iMXJRX/GbUdrtb/Yf6NPzoq1c56PoeK0BnBEnxgB/P2AmmD8muXM6fQoS1iRMWWpb+Ur1bvHnyXC9CruOnxM/a6tmQFR4079BxN45gm5Q3C7KVPDar1f7sUarbv9o0DLtk1xsqzVjMYguBw46ngWfLE4VP0FCvMfES19GDsJGN5CBATTB5GBcVu2oahpn3S6JJJTvu3sn+x9qO7i6NGNYZQnX4x6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 158586a3-8609-4260-a90d-08d607c27a42 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1900; x-ms-traffictypediagnostic: YTOPR0101MB1900: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201708071742011)(7699016); SRVR:YTOPR0101MB1900; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1900; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(366004)(396003)(376002)(199004)(189003)(7696005)(6506007)(316002)(786003)(74482002)(99286004)(11346002)(446003)(76176011)(478600001)(450100002)(476003)(486006)(2900100001)(4326008)(6246003)(102836004)(229853002)(14454004)(5250100002)(5660300001)(2906002)(9686003)(25786009)(97736004)(53936002)(14444005)(26005)(6436002)(106356001)(105586002)(256004)(81166006)(74316002)(68736007)(305945005)(6916009)(8676002)(33656002)(86362001)(55016002)(186003)(8936002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1900; H:YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6YTICv8IxY+AgnbFk/XRXI4OpK/GXQNEoKiPpHrKGor71KzKK6A9V/2DiS3xYBMMAcfjp3e2YyDwpXWkB17dIRO6xuIDz0dSZXDNCBmXMLXG7eQHB6J+MhKf1iiNYWjBz8njIkmW7h4OJiGNn+gj6g+x9mqdowYR4v52GSsA1J74l+5OkUl4Sm6nOTTmII7b/SK0uI37p6w0D/HIrPJ+3vPRYqrc8SkQx6zCPEU7exfT6Yb9XhRvqS97X7gZnyveJQEc/XgQiJuAx6iL6pX7Xd/IZeXc4hUAe4Iw+8XAlrQudzZ59tM+id0IcfwIv2Rx/H0oPEQcif4/tB+JCneGca6ZzPBiLZLWMlCU7g3Np7s= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 158586a3-8609-4260-a90d-08d607c27a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2018 00:01:57.5192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1900 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 00:01:59 -0000 Matthew Macy wrote: [stuff snipped] >I don't know what's special in this case, but I did revamp the locking the= re several >months back so I'll take a look next weekend. Thanks but don't worry about it for now. I think I figured out how the pani= c() occurred. If the nfsd was accessing /var/run/nfsuserd.sock for a client and= then tried to soconnect() to it to do the upcall, the nfsd thread would already = have /var/run/nfsuserd.sock vnode locked. The old way (and what FreeBSD-11 still does) was to use a UDP socket, which isn't in the file system namespace. (I switched the default to AF_LOCAL so = that nfsuserd could be used in jails where 127.0.0.1 doesn't work, but I now thi= nk it isn't safe to use an AF_LOCAL socket, since it is in the file system's n= amespace and, therefore, can be accessed directly by the NFS code. I think I'll revert the "switch to AF_LOCAL socket" patch. Hopefully the reporter can help confirm this "theory", rick From owner-freebsd-current@freebsd.org Wed Aug 22 00:48: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 78D7210851CC; Wed, 22 Aug 2018 00:48:33 +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 ED6EC77159; Wed, 22 Aug 2018 00:48:32 +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 w7M0mh1P084744 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Aug 2018 17:48:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7M0mhmj084743; Tue, 21 Aug 2018 17:48:43 -0700 (PDT) (envelope-from fbsd) Date: Tue, 21 Aug 2018 17:48:43 -0700 From: bob prohaska To: Kirk McKusick Cc: FreeBSD Current , FreeBSD Filesystems , bob prohaska Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <20180822004843.GA84687@www.zefox.net> References: <201808201940.w7KJeu29072094@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808201940.w7KJeu29072094@chez.mckusick.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 00:48:33 -0000 On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote: > I have recently added TRIM consolodation support for the UFS/FFS > filesystem. This feature consolodates large numbers of TRIM commands > into a much smaller number of commands covering larger blocks of > disk space. Best described by the commit message: > > Author: mckusick > Date: Sun Aug 19 16:56:42 2018 > New Revision: 338056 > URL: https://svnweb.freebsd.org/changeset/base/338056 > > Log: > Add consolodation of TRIM / BIO_DELETE commands to the UFS/FFS filesystem. > > When deleting files on filesystems that are stored on flash-memory > (solid-state) disk drives, the filesystem notifies the underlying > disk of the blocks that it is no longer using. The notification > allows the drive to avoid saving these blocks when it needs to > flash (zero out) one of its flash pages. These notifications of > no-longer-being-used blocks are referred to as TRIM notifications. > In FreeBSD these TRIM notifications are sent from the filesystem > to the drive using the BIO_DELETE command. > > Until now, the filesystem would send a separate message to the drive > for each block of the file that was deleted. Each Gigabyte of file > size resulted in over 3000 TRIM messages being sent to the drive. > This burst of messages can overwhelm the drive's task queue causing > multiple second delays for read and write requests. > > This implementation collects runs of contiguous blocks in the file > and then consolodates them into a single BIO_DELETE command to the > drive. The BIO_DELETE command describes the run of blocks as a > single large block being deleted. Each Gigabyte of file size can > result in as few as two BIO_DELETE commands and is typically less > than ten. Though these larger BIO_DELETE commands take longer to > run, they do not clog the drive task queue, so read and write > commands can intersperse effectively with them. > > Though this new feature has been throughly reviewed and tested, it > is being added disabled by default so as to minimize the possibility > of disrupting the upcoming 12.0 release. It can be enabled by running > ``sysctl vfs.ffs.dotrimcons=1''. Users are encouraged to test it. > If no problems arise, we will consider requesting that it be enabled > by default for 12.0. > > Reviewed by: kib > Tested by: Peter Holm > Sponsored by: Netflix > > This support is off by default, but I am hoping that I can get enough > testing to ensure that it (a) works, and (b) is helpful that it will > be reasonable to have it turned on by default in 12.0. The cutoff for > turning it on by default in 12.0 is September 19th. So I am requesting > your testing feedback in the near-term. Please let me know if you have > managed to use it successfully (or not) and also if it provided any > performance difference (good or bad). > > To enable TRIM consolodation either use `sysctl vfs.ffs.dotrimcons=1' > or just set the `dotrimcons' variable in sys/ufs/ffs/ffs_alloc.c to 1. > Will the new feature be active on a Raspberry Pi 3 using flash on microSD and USB for file systems and swap? Can the feature be turned on using one of the conf files in /etc? According to Sandisk, "All microSD or USB drives are flash memory and does support the TRIM command, however, you will not notice any difference after running TRIM command on memory cards or USB drives. TRIM command is basically used for SSD and Hard drives." The "you will not notice any difference...." qualification makes me slightly uncertain the reply was well-informed, but if there's any hope of success I'd like to try it. >From time to time there seem to be traffic jams among flash devices on the RPI3, it would a pleasant surprise if this feature helps. Thanks for reading! bob prohaska From owner-freebsd-current@freebsd.org Wed Aug 22 01:09: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 1841E1085AB0 for ; Wed, 22 Aug 2018 01:09:40 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (tunnel294749-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:107f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Tharned" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DF6077E0F for ; Wed, 22 Aug 2018 01:09:39 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from flake.tharned.org ([IPv6:2001:470:1f11:107f:54c6:f64c:9d8f:10af]) (authenticated bits=0) by roadkill.tharned.org (8.15.2/8.15.2) with ESMTPSA id w7M190IF093642 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2018 20:09:37 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tharned.org; s=2017; t=1534900177; bh=PFzJhtTw4cdZQ3ria+I/LZPrFsOcQeG0ozrE+BGz+zc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=n8lNF5WoL7ypgzMozEbSjJTCgVbSiOH0DZs13KntojYZfTS3xcCOt84lQ0atXv2hy XGCEBeJcJkzMm9dtsvbbtftGKqHljLF0SInjWHlKNa+7mhMtikeS1icdwbZ3amlZA6 FsqgEtFvh5o//cXNx4slBXULuaA5/dR++KoRkS8TXus3a2guOqSCJBpHzWpf+rye/L YNtjbD/Cz6SLJhOLdLPEajcwJ3BaR8EoQdW4c00z7Q3XefIg+j7StChx+9PGZU+23g kR6jlsjNsAb0y/z5jDIFlRsBJcrELIOIgbtvmZeNtfQbpPWHUCI/B6f9T21A9khKPa h6cklNVBCMsLg== X-Authentication-Warning: roadkill.tharned.org: Host [IPv6:2001:470:1f11:107f:54c6:f64c:9d8f:10af] claimed to be flake.tharned.org From: Greg Rivers To: Bob Prohaska Cc: FreeBSD Current Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Date: Tue, 21 Aug 2018 20:09 -0500 Message-ID: <1659279.80fYreCAfO@no.place.like.home> User-Agent: KMail/4.14.10 (FreeBSD/11.1-RELEASE-p13; KDE/4.14.38; amd64; ; ) In-Reply-To: <20180822004843.GA84687@www.zefox.net> References: <201808201940.w7KJeu29072094@chez.mckusick.com> <20180822004843.GA84687@www.zefox.net> 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.6.2 (roadkill.tharned.org [IPv6:2001:470:1f10:107f:0:0:0:2]); Tue, 21 Aug 2018 20:09:37 -0500 (CDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 01:09:40 -0000 On Tuesday, August 21, 2018 17:48:43 Bob Prohaska wrote: > Will the new feature be active on a Raspberry Pi 3 using flash > on microSD and USB for file systems and swap? > It will work on any UFS file system, as long as the underlying medium supports TRIM. It will not work for swap because swap is not UFS. > Can the feature be turned on using one of the conf files in /etc? > No, TRIM and other UFS features are controlled by parameters in the UFS superblock. See tunefs(8). -- Greg From owner-freebsd-current@freebsd.org Wed Aug 22 01:47: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 3A7EE10869AD for ; Wed, 22 Aug 2018 01:47:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-12.consmr.mail.ne1.yahoo.com (sonic307-12.consmr.mail.ne1.yahoo.com [66.163.190.35]) (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 A782279701 for ; Wed, 22 Aug 2018 01:47:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PzlNgWcVM1nfv54fVFlGkdOZtXpZO12TrhvOINihD0USMY.RKQSy6zisoaUsnyf zTtaTjVtdzZOF0sTGzdI2LzeCcOEj53kFkXz1BtzwZ2PRgeLN4Z8U3_23jlJkutBHMAdBL.L24Ty NnBD3uu4fwYQm_klVQCk__3uM7sPcgfCMXTFAAw5Dolerov_HEdHxmR8GSxV09wbwKrIwvcOwreU xPCDXN2ihn70A0JdL5XnJwnMjFDPHHYNOOdN16rgdy3GXUphio2tCXOj6JG66D0LUWaWbFa6N7rP VLGSnMIsYmQL7PO5WyLpxoPhk7AMkkBAdsJp8vPkbN.WRkKJB6093K5t4hmZTLggC359CMHZcKVf H0hNn0pCwRj6hM_PIW3H.QRZ_AVpj8muaQKMlY23B6Eyc.X0YhJENHLhqhQ54bM309rTaph0yDaX PvphoicstmDKt6EUL4pVZWV0HGJQsWX4bShwdmkxW1wL5MMYQOitoBjRV5bFxv0lucaFMkbXqRHX jCHljFUiBh6KKEJscgoHZeYtp62EeWF62UpPcuqK8e6YmLpd6FctQ8kC6.hMv8Wf8s3iIcZ3XPOT GjZnWwmTjcdm0kXmSbDDXtnSYiqA96k3A4dfHUyPH29awrZ_hR1y4Wx_p4O20Bbncc7DdynzzrkH FsaVzgXBtcWczydpyXp_xy1HvUBTUjyqwEMfdMUOUeJDveX4npysZa_8..nR2FapFxWT17MJTDmf XFrQyeTtqCesFCWWLENV8TK85sZF56veLyhIopiPSHBAOFBKYJoWEs.tCZQT4a0dxnb1h9nggqnW mHRMEPHFOo2gQUUtVoWfygxltCUzN4kwQrWxJnULTQcX8Zroh6Txb.zZIQQIj6uobg2XzCEBUq5x BqA0zMRyxohVOqqutP7T0JS1RRBAcddVm_wzjvwJ4fi3NHC8qYd_Ys3.3.tnYVt99YRwFciEUB1v doWZGgLnvSazlZU5RMO7H883T9CXsc5xQV9RDt3KoBuCFVR5xU5CGiRjHmPKNZEfyoBfJ6mvJCwk fyNLltgzCr204AmGfW.xAwafjy7Z9CdYI_ruBHg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Wed, 22 Aug 2018 01:47:22 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 85037b62be960f7fc7e74c550f4f30b7; Wed, 22 Aug 2018 01:47: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.5 \(3445.9.1\)) Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-Id: <170C703D-AA75-4EC9-93BA-D2CF3A7D6D5E@yahoo.com> Date: Tue, 21 Aug 2018 18:47:19 -0700 To: bob prohaska , FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 01:47:30 -0000 bob prohaska fbsd at www.zefox.net wrote on Wed Aug 22 00:48:33 UTC 2018 : > On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote: > > . . . > >=20 > > To enable TRIM consolodation either use `sysctl = vfs.ffs.dotrimcons=3D1' > > or just set the `dotrimcons' variable in sys/ufs/ffs/ffs_alloc.c to = 1. > >=20 >=20 > Will the new feature be active on a Raspberry Pi 3 using flash=20 > on microSD and USB for file systems and swap?=20 Even if a USB device contains appropriate storage in it, that does not mean that the USB protocol in use has a way to request the operation. (Similarly for other multiple stages of translation than USB protocol being involved.) For FreeBSD, UFS and ZFS have support if the requests can be sent through all the stages. Swap partitions do not have support even if the device does through all the stages. (See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 for why I do not otherwise mention swap files.) RPI3's use (some subset of?) USB 2.0 as I remember. I'm not aware of the protocol supporting such. (I'm no expert, however.) Thus, UFS and ZFS end up unable to do TRIM for such contexts as I understand things. > Can the feature be turned on using one of the conf files in /etc?=20 At least for UFS there are commands for configuration, such as tunefs and newfs that include control of such points. I do not remember for ZFS. As I remember if you enable it on UFS but it actually can not do it for how the device is connected, FreeBSD reports the issue at mount or some such. I've used a SSD both directly via SATA and via a USB enclosure, the same partitions/file systems across the uses. Only when it was SATA-style-use did TRIM work. > According to Sandisk,=20 > "All microSD or USB drives are flash memory and does support the TRIM = command, however,=20 > you will not notice any difference after running TRIM command on = memory cards or USB=20 > drives. TRIM command is basically used for SSD and Hard drives." This gets back into what the protocols in use allow to be requested when direct communication with the flash is not in use. (More may be involved.) > The "you will not notice any difference...." qualification makes me = slightly uncertain > the reply was well-informed, but if there's any hope of success I'd = like to try it. > >=46rom time to time there seem to be traffic jams among flash devices = on the RPI3, it > would a pleasant surprise if this feature helps. I'll note that gstat with -d allows watching the "BIO_DELETE" operations (in FreeBSD terms). One can see if they are what time is being spent on. Quoting g_bio(9) : BIO_DELETE Indicates that a certain range of data = is no longer used and that it can be erased = or freed as the underlying technology = supports. Technologies like flash adaptation = layers can arrange to erase the relevant blocks = before they will become reassigned and = cryptographic devices may want to fill random bits = into the range to reduce the amount of data = available for attack. In your rpi3/2 experiments if you watch the column sequence: d/s kBps ms/d I expect that you will find that they stay at: 0 0 0.0 indicating lack of use. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Aug 22 01:55: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 387D31086F0F; Wed, 22 Aug 2018 01:55:07 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D33D479E3B; Wed, 22 Aug 2018 01:55:06 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 931CD101AB; Wed, 22 Aug 2018 01:55:06 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f170.google.com with SMTP id c22-v6so303149iob.1; Tue, 21 Aug 2018 18:55:06 -0700 (PDT) X-Gm-Message-State: APzg51AVJNCBjuxyJJ39FLhBJHPg6NHe1oA4HjEyH6imYePZAZ1Tu8cY u5T2FHQv/hA2HBhwlo7B+Ai3OJvnYmRpLhgAbIM= X-Google-Smtp-Source: ANB0Vda3RyZzbAzQS1sufVblGKXMa9ugYSSpxCulob4Abnu1a5l0vs8BPrNh7N8VjlAybaQlFHD1pEYQXJUpvy3/SDI= X-Received: by 2002:a5e:dd4b:: with SMTP id u11-v6mr3621713iop.237.1534902905949; Tue, 21 Aug 2018 18:55:05 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Tue, 21 Aug 2018 18:54:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: drm / drm2 removal in 12 To: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 01:55:07 -0000 Just in case anyone misses the change to UPDATING: 20180821: drm and drm2 have been removed. Users on powerpc, 32-bit hardware, or with GPUs predating Radeon and i915 will need to install the graphics/drm-legacy-kmod. All other users should be able to use one of the LinuxKPI-based ports: graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod. Note that this applies only to 12. -M From owner-freebsd-current@freebsd.org Wed Aug 22 01:55: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 72D9A1086F4C; Wed, 22 Aug 2018 01:55:47 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29C2879EAD; Wed, 22 Aug 2018 01:55:47 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E67BD101AC; Wed, 22 Aug 2018 01:55:46 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f171.google.com with SMTP id w11-v6so298885iob.2; Tue, 21 Aug 2018 18:55:46 -0700 (PDT) X-Gm-Message-State: APzg51AAEOgFIoQ/HHT24fdlrQfg0YjARlOr8p1tzwpTyM+p6ykRFNGh mB1VuRvpFISgQdC5ZRlEuNZMaK4aItVI80Q+lQ4= X-Google-Smtp-Source: ANB0VdZ8RylZhYqhLJvBkA2tH6YFMhXuPRGSDE/629i7eP/hEbKYdA85KMa+XoDKlHl/WAEYLzkzt9JN5ZKBT8RHeY0= X-Received: by 2002:a6b:500e:: with SMTP id e14-v6mr10725789iob.5.1534902946477; Tue, 21 Aug 2018 18:55:46 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy Date: Tue, 21 Aug 2018 18:55:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Native Encryption for ZFS on FreeBSD CFT To: freebsd-current , freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 01:55:47 -0000 To anyone with an interest in native encryption in ZFS please test the projects/zfs-crypto-merge-0820 branch in my freebsd repo: https://github.com/mattmacy/networking.git ( git clone https://github.com/mattmacy/networking.git -b projects/zfs-crypto-merge-0820 ) The UI is quite close to the Oracle Solaris ZFS crypto with minor differences for specifying key location. Please note that once a feature is enabled on a pool it can't be disabled. This means that if you enable encryption support on a pool you will never be able to import it in to a ZFS without encryption support. For this reason I would strongly advise against using this on any pool that can't be easily replaced until this change has made its way in to HEAD after the freeze has been lifted. By way of background the original ZoL commit can be found at: https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 Thanks in advance. -M From owner-freebsd-current@freebsd.org Wed Aug 22 02:01: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 F3C0D10873A0 for ; Wed, 22 Aug 2018 02:01:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) (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 939067A2B8 for ; Wed, 22 Aug 2018 02:01:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: fshMIdgVM1nlm.E1cN6Cq_Nxk776hPP1CYVBhZ067i1V6F7uDzrkj70iZMjjqB8 E15cOmRMwof0SQm7U3PotCq8HU0KqSpxufjrNxLTcP9.srKUxm429B6poNCgQ2KQYsxmIrprCWIp 8pOK2HrcG9aXodioMGBtckjE1dfBSchMnaR.xEi80wb53seVmtsjSdb_RKs2kPbtOcR9vyCRUJ.j WW6nSyqrCOLwJ.WI.SsvlW6eaEAOcZOC.5MUXrPLnaXAthWqejfMeC5bwHeDgRMwumkNjXhK9eg7 d5Fjvd5zThitRg4MZLTkNEV4dswEfe6LcDN9qAd6yG9L1YYe26JOZcquBK5UlkUdM0Vj_86GxhEG _8KPq7sDLdpYJMFALfnZ1zz.lzd.ZOU0aNEU0afR0Efgb1nAvea07WBg8PzaCp1gTnh4zQePFtvd LFeriExOO9olQXhMgOBOnGpT_eyeP1.0JS6E6KO5Ru4JUNfOixKBTN.sj_dJjk.YrFFEEdGZ0lrO QZ6aFUg9TVWswiiZg9JN8xC6nTHqQSMv24nDVdnqTKAG5Oh4qqMUDs1fXGlby0qcoM4fJiXDrU8K Dx96.GJ3mjbVtktuuUFKdHYHeFuasIFBWStuYNsDLw9ZIWoaCqaVua1A4pr.GJB_NMvO3DfUe2Xi Tl1mUeWi5s98slbGNFXj5mI1_3zDPdejQ7h1OVZR4jCinpNaeyVnBc6vtHGEQym8XENgE6BhFLLJ qyHqKrl9HzqqoV5xKCLXsJOMPMvkRQU4dvABMZ7lXZLe.OrSOjSWUDqwl78cub0yIhESbFRW4x2G 6KMUEcfKNhL_Y89QMfGTRZOWKRDUsty3JOLdo8gVQEW_TvjrvrafF9aRbJbGNC6vxRpl_CYiGrsg mXu99CbzZZKcJPvJUCt1_PvETOR0DZbpwkPGD12.4t7pEzc3AYn.dusjBgetUH7H43jvRwau51Ue 4Z3LFL32zmuCBb9TAGoXyU78FJO3K998d130ed6EWKt4iMB6S5yjMm7Dp0lV0vzgSkAaOgMX0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 22 Aug 2018 02:01:12 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 212d1c638e199170fa365e46eb532419 for ; Wed, 22 Aug 2018 02:01:07 +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.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Message-Id: <0846E103-2DCC-421F-B82B-1BE287002468@yahoo.com> Date: Tue, 21 Aug 2018 19:01:05 -0700 To: FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 02:01:19 -0000 Brooks Davis brooks at freebsd.org wrote on Tue Aug 21 20:29:45 UTC 2018 : > On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote: > > . . . > > > > I have attached a patch for most of the llvm ports, which sets the > > LLVM_PARALLEL_LINK_JOBS CMake flag during the configure phase. > > Committed in r477756. > lld itself has --threads (default) and --no-threads (non-default, single threaded link). (Mark Johnston recently made me aware of this.) In my quick experiment in just one context, --threads used 5 or so threads in the lld process. (Likely helps with speed when the hardware threads are simply available without conflicts.) Does LLVM_PARALLEL_LINK_JOBS contribute to which of these is in use? I've started experimenting with /etc/make.conf like files having: LDFLAGS.lld+= -Wl,--no-threads in contexts with few cores and/or that do not have lots of RAM. (But I'm unsure of the difference in RAM usage across various contexts for the two styles of lld use.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Aug 22 02:23: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 BC6FE10883C3 for ; Wed, 22 Aug 2018 02:23:43 +0000 (UTC) (envelope-from danfe@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 76D137B805; Wed, 22 Aug 2018 02:23:43 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 6EED31C126; Wed, 22 Aug 2018 02:23:43 +0000 (UTC) Date: Wed, 22 Aug 2018 02:23:43 +0000 From: Alexey Dokuchaev To: "Alex V. Petrov" Cc: freebsd-current Subject: Re: Fwd: nvidia-driver build error (last ports, FreeBSD-HEAD) Message-ID: <20180822022343.GA60855@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 02:23:43 -0000 On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: > > -------- Перенаправленное сообщение -------- > Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) > Дата: Tue, 21 Aug 2018 16:41:42 +0700 > От: Alex V. Petrov > Кому: FreeBSD Ports Should be fixed as of r477761. ./danfe From owner-freebsd-current@freebsd.org Wed Aug 22 02:27: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 66B7B1088540; Wed, 22 Aug 2018 02:27:14 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 111AC7B9BA; Wed, 22 Aug 2018 02:27:14 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id CC0D1104B8; Wed, 22 Aug 2018 02:27:13 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f48.google.com with SMTP id h23-v6so1082125ita.5; Tue, 21 Aug 2018 19:27:13 -0700 (PDT) X-Gm-Message-State: APzg51CDBOX29EwVxUKLHQxDik6kYli84VNqeTZ2sLaJu1sMSvxW9J2x ax20wE0agBZ98shspm09/AJDPaBY2t6LPVdHDFg= X-Google-Smtp-Source: ANB0VdYmAzdU1G8Optqx6uQ9rRQ5sQWo4T5PIRfzl7Sh5iBFJ2vNK2laVKRBC3lmyLuasiXh/jyixKfJy4MWF04bVqg= X-Received: by 2002:a24:704f:: with SMTP id f76-v6mr1626689itc.30.1534904833320; Tue, 21 Aug 2018 19:27:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Tue, 21 Aug 2018 19:27:02 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: freebsd-current , freebsd-fs@freebsd.org Cc: Sean Fagan Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 02:27:14 -0000 On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: > To anyone with an interest in native encryption in ZFS please test the > projects/zfs-crypto-merge-0820 branch in my freebsd repo: > https://github.com/mattmacy/networking.git > > Oh and I neglected to state that this work is being supported by iX Systems and the tree is all built on work done by Sean Fagan at iX Systems. Please keep him in the loop on any problems encountered. Thanks. > ( git clone https://github.com/mattmacy/networking.git -b > projects/zfs-crypto-merge-0820 ) > > The UI is quite close to the Oracle Solaris ZFS crypto with minor > differences for specifying key location. > > Please note that once a feature is enabled on a pool it can't be > disabled. This means that if you enable encryption support on a pool > you will never be able to import it in to a ZFS without encryption > support. For this reason I would strongly advise against using this on > any pool that can't be easily replaced until this change has made its > way in to HEAD after the freeze has been lifted. > > > By way of background the original ZoL commit can be found at: > > https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 > > Thanks in advance. > -M > From owner-freebsd-current@freebsd.org Wed Aug 22 03:11: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 D3F831089901; Wed, 22 Aug 2018 03:11:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5043B7D525; Wed, 22 Aug 2018 03:11:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f180.google.com with SMTP id 203-v6so324178ljj.13; Tue, 21 Aug 2018 20:11: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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2H77byjIsdHOagXX3E6B0cd9+5m33eRiPqKcdQc6duw=; b=ndDZAcx+HhcvU9zVPa85IMDB3edx9YJZLID8PZtK4pK63MO0G1a2ipFR1jAlDEB5CU aNErPir4NI3GuabzUXa22pP4E7BT+Jdrir2s963CeZJxNOscpZvaTPzcEUnmbHJGxm+3 E3VZAbY0ELMctQPUpEvo5wXa3LexogUAv46AKqqHh+Bsd7/Eqibrzaqn8u9Uoyz3Mxyn GChFn/C6+3yMrlpfCpvrkl1v1g8WfSirtX4ztPWrF42C1QiTkcIsRYoXE6bPZ9di29K/ D5cTDgBrpY+pfl/Y01BLtoK2LJuWuRB3Cng0vx/kSVSnvaZLy++Bavb3sPhylZHTp+I6 wogA== X-Gm-Message-State: AOUpUlHsx0lfic7T9mPQH94C7K74MW5A1omgTznXje0eJApRFQszsVR3 wtoePnSZ0q+ithSgAYwaUaomiIrVyetB0VdNT0VITQ== X-Google-Smtp-Source: AA+uWPwQXwYR0S7XM4YwMSO84aJc973FVyCEVHcJdMreNfRTJihx1IJYHV+i+cGYjX7k5+OsXjY6wDMrl0Oyw4emo8A= X-Received: by 2002:a2e:2067:: with SMTP id g100-v6mr35044269ljg.138.1534907507989; Tue, 21 Aug 2018 20:11:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Tue, 21 Aug 2018 21:11:36 -0600 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Matthew Macy Cc: FreeBSD CURRENT , freebsd-fs , Sean Fagan Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 03:11:56 -0000 The last time I looked (which was a long time ago), Oracle's ZFS encryption looked extremely vulnerable to watermarking attacks. Did anybody ever fix that? -Alan On Tue, Aug 21, 2018 at 8:28 PM Matthew Macy wrote: > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: > > > To anyone with an interest in native encryption in ZFS please test the > > projects/zfs-crypto-merge-0820 branch in my freebsd repo: > > https://github.com/mattmacy/networking.git > > > > > Oh and I neglected to state that this work is being supported by iX Systems > and the tree is all built on work done by Sean Fagan at iX Systems. Please > keep him in the loop on any problems encountered. > Thanks. > > > > > ( git clone https://github.com/mattmacy/networking.git -b > > projects/zfs-crypto-merge-0820 ) > > > > The UI is quite close to the Oracle Solaris ZFS crypto with minor > > differences for specifying key location. > > > > Please note that once a feature is enabled on a pool it can't be > > disabled. This means that if you enable encryption support on a pool > > you will never be able to import it in to a ZFS without encryption > > support. For this reason I would strongly advise against using this on > > any pool that can't be easily replaced until this change has made its > > way in to HEAD after the freeze has been lifted. > > > > > > By way of background the original ZoL commit can be found at: > > > > > https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 > > > > Thanks in advance. > > -M > > > _______________________________________________ > 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 Aug 22 03:22: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 DA66F1089E9E; Wed, 22 Aug 2018 03:22:44 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 540D37DCE5; Wed, 22 Aug 2018 03:22:44 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f53.google.com with SMTP id e23-v6so335180lfc.13; Tue, 21 Aug 2018 20:22:44 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K4sxYQFtk0zvnwlbCDWB5N32seFVM3EPQZHj3QZsVvc=; b=egcGw2pCFMOrZAgUzOAvGgiy80Qey8XVaQYmXzDhz9k6tqgNnGxG871O1bugqPJsXh E20H81fLbMpqRSPct2XD6I4mbS+HvwtESqgferFA7oYwM09ef8CUMTxKexqJE94/QmeJ vG2MAi8f1qnkuS24KPgZTUuKjOjrqvFLQkYzOAtmSNNLK2kYHgTDF+KB1msMbjgs3qBh PPrlBy+JXtboZqsP3IO4Vy8/oRfgaP+hPxcBibBT6PWXBLPRYzHQzENzUZoTdA+gsaaY iXiR2iu0lMTjgplU0fpQTDRuFhMCS+MfVLA45ItTVZam5ydIn9f0/sBg4RIUQQOl+Wia ltMw== X-Gm-Message-State: AOUpUlHIAxc4bEGqeMEmpk34xDcYUZP0E+hsQbux7xflIZPUn0CvYclP 8R68U9KB1Q4SFEuEmll10LJ4pRx9GvnmB/Rhz6Y= X-Google-Smtp-Source: AA+uWPz94t+P7yEp+c+IKPUUNpMzreD77WvNuc2a2szQz2dqWEhzHqXJ4PhDV5libp7VLnRzJUVCJ5ARSfO0Ky8308U= X-Received: by 2002:a19:c94a:: with SMTP id z71-v6mr12897641lff.34.1534907785971; Tue, 21 Aug 2018 20:16:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Tue, 21 Aug 2018 21:16:14 -0600 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Sean Fagan Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 03:22:45 -0000 On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote: > On Aug 21, 2018, at 8:11 PM, Alan Somers wrote: > > The last time I looked (which was a long time ago), Oracle's ZFS > encryption looked extremely vulnerable to watermarking attacks. Did > anybody ever fix that? > > This isn=E2=80=99t Oracle=E2=80=99s implementation, but I don=E2=80=99t k= now how compatible or not > it is with it. > > Sean. > It wasn't just an implementation problem, it was in the design. IIRC, Oracle's encryption allowed encrypted blocks to be deduplicated. There's pretty much no way to defend against watermarking attacks with such a design. Does the new encryption design have the same flaw? -Alan From owner-freebsd-current@freebsd.org Wed Aug 22 03:27: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 C8792108A0BE; Wed, 22 Aug 2018 03:27:01 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 799A37E00E; Wed, 22 Aug 2018 03:27:01 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 3FC7610AD8; Wed, 22 Aug 2018 03:27:01 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f171.google.com with SMTP id l7-v6so410844iok.6; Tue, 21 Aug 2018 20:27:01 -0700 (PDT) X-Gm-Message-State: AOUpUlERxQMew6WVd9LpaWXzQ0QbmEmKiWCQyae09ti62VzMdwQFXKDw 4THdajwndBu6zqUPSC6fNlal98APKgLuhpm0K4U= X-Google-Smtp-Source: AA+uWPwSVUNXx50T+vUJSt4grwvC4Uutr7fM4srzBnVOgh4I5teL/eXLgTjEQ98TEq8Ly/QUcz+CJ0CvJKMErAXCZCI= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr19517651iog.132.1534908420727; Tue, 21 Aug 2018 20:27:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Tue, 21 Aug 2018 20:26:50 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Alan Somers Cc: FreeBSD CURRENT , Sean Fagan , freebsd-fs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 03:27:02 -0000 On Tue, Aug 21, 2018 at 20:22 Alan Somers wrote: > On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote: > >> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote: >> > The last time I looked (which was a long time ago), Oracle's ZFS >> encryption looked extremely vulnerable to watermarking attacks. Did >> anybody ever fix that? >> >> This isn=E2=80=99t Oracle=E2=80=99s implementation, but I don=E2=80=99t = know how compatible or >> not it is with it. >> >> Sean. >> > > It wasn't just an implementation problem, it was in the design. IIRC, > Oracle's encryption allowed encrypted blocks to be deduplicated. There's > pretty much no way to defend against watermarking attacks with such a > design. Does the new encryption design have the same flaw? > I would ask the original developer that question (see the commit I linked to). The current dedup Implementation is terrible, so there are very few users of it. -M > > -Alan > From owner-freebsd-current@freebsd.org Wed Aug 22 03:56: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 47096108AB1C for ; Wed, 22 Aug 2018 03:56: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 B844B7F414 for ; Wed, 22 Aug 2018 03:56:12 +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 597CC1ED33 for ; Wed, 22 Aug 2018 03:56:06 +0000 (UTC) To: freebsd-current@freebsd.org References: From: Allan Jude Openpgp: preference=signencrypt Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Subject: Re: Native Encryption for ZFS on FreeBSD CFT Message-ID: <6852700c-b4bd-eee2-13f5-95fd184dd427@freebsd.org> Date: Tue, 21 Aug 2018 23:56:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LSCKq6g7VmZ28mRaFwCI13rRplCyeIkTS" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 03:56:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LSCKq6g7VmZ28mRaFwCI13rRplCyeIkTS Content-Type: multipart/mixed; boundary="X0bj2t8L0TEecIfPG2dILvXEEoUKlwqUP"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <6852700c-b4bd-eee2-13f5-95fd184dd427@freebsd.org> Subject: Re: Native Encryption for ZFS on FreeBSD CFT References: In-Reply-To: --X0bj2t8L0TEecIfPG2dILvXEEoUKlwqUP Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2018-08-21 23:16, Alan Somers wrote: > On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan wrote: >=20 >> On Aug 21, 2018, at 8:11 PM, Alan Somers wrote: >>> The last time I looked (which was a long time ago), Oracle's ZFS >> encryption looked extremely vulnerable to watermarking attacks. Did >> anybody ever fix that? >> >> This isn=E2=80=99t Oracle=E2=80=99s implementation, but I don=E2=80=99= t know how compatible or not >> it is with it. >> >> Sean. >> >=20 > It wasn't just an implementation problem, it was in the design. IIRC, > Oracle's encryption allowed encrypted blocks to be deduplicated. There= 's > pretty much no way to defend against watermarking attacks with such a > design. Does the new encryption design have the same flaw? >=20 > -Alan > _______________________________________________ > 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" >=20 There is a presentation from the OpenZFS developers summit that walks through the design. It is not the same as the Oracle version, although relatively similar. Video: https://youtu.be/frnLiXclAMo Slides: https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view?usp=3Ds= haring It says dedup only works within the same 'clone family', and uses a unique IV for every block, except when the data is identical (when it gets deduped) It isn't clear to me from the presentation if this issue is mitigated or not. Slide #26 suggests they have done more than Oracle did. --=20 Allan Jude --X0bj2t8L0TEecIfPG2dILvXEEoUKlwqUP-- --LSCKq6g7VmZ28mRaFwCI13rRplCyeIkTS 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) iQIcBAEBAgAGBQJbfN7VAAoJEBmVNT4SmAt+OGAQAOMuYUgAFlPuGRVktO4Ip/fi 47WfDU5afZtyzfhX+NBqDGOOjy01lwRKmUuejMYzI8uPrpxRCmfMHQddEnYjtKAD VLW0uuZUThp+445mkhIIV1ZveDP57n/FtQEHG7Hb1ST5ZbVzZ2C4FAk+g+jOc+Mw kTQjAagw1T7XyUS5O2ylcUhmPLx3kqTL1wEUZvIGuJ8Zujz95OcCfIABsH5eNeyx BMvVxBwP5oPDLmkQzwYOs+oAw8y0dcJ3tew+GtYmm0s6l0eS3l1/RLm355pcfz5o NcLYdPEnEOkyi+v1mxWIS6JJV3Scx3ad5LFYdJ4+gcWoR5DstrngYSCF/nBVbEIB 6X3Xh75ZTWnFLxU/ZGU9SJUdCPoYtLAyPu/aeBKSr02dqz92LAyffk7E1Cl4K/yh EC02f0BR/fim3r2+Lq2IJVfori+J5eVbVMkAqy62P42CRXocVfW1xTa5cqskrbAd LhoZQ58eZhJhlCvF5RclcCssGw7MUQzb9MhHuHbW2JXfn70sj42IEgWFFqQVhdmm jl/Yr5civrKakBdsArxGKDal3CA9WyoWremgHJjKyAp8TIstf1rx++DND8t7Nfcn LnXemavs0/bu+KuQP6nKpzdOwCa9sMpteMR0vJci+vBzJ3C5/18bNvwwBQE6fGfO LFKg1Ifq3Ul3zsaAku85 =wn5l -----END PGP SIGNATURE----- --LSCKq6g7VmZ28mRaFwCI13rRplCyeIkTS-- From owner-freebsd-current@freebsd.org Wed Aug 22 03:13:53 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 742EF1089A4E for ; Wed, 22 Aug 2018 03:13:53 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E31B07D7F2 for ; Wed, 22 Aug 2018 03:13:52 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: by mail-pg1-x52a.google.com with SMTP id y5-v6so283039pgv.1 for ; Tue, 21 Aug 2018 20:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QwmT573P5z+E5cNktIb+if7LdtQ6c7G8l3Qzm5j1X4=; b=PDNCtFcEIv6ZZoL/PMt4Y18CVpjQrxE1Qn6SlXXMsjzYldeomyCgcQkgMBlRs37wp0 9KNG4Hn8tmIH7znmD2fdrhpz0kPWQ5QJ02bd3HXAE7MG+8BfPA5V/vdEr+dc7byKrolX xuj7IeHX7gKFYz2KsY9RxHdr1Fcv+grawEnrMx0tdqhAc78K9HbSUL78XDm0RPXiIkC2 oUYgRac4FzYwKnzGnJM57VO5aVT1SmBlKU6eNB7UoWQxDBZ/DzYcTWBjLd0xegowjnFH bd7g3/c7cpRF5Bs5clEunVD51agJulZdI0/6xnJZzhyV/T0zEaUl89ZZwgwzf2dm8LIB R0CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QwmT573P5z+E5cNktIb+if7LdtQ6c7G8l3Qzm5j1X4=; b=tg4wEvu5tEdcL6lXz0YsBWXpa/v5S/pKY5OkLvKYgU2sthi02zLxssbHfesnTsP6Yt dU0aOmGAdbulPl0xdR3P/262ZLxgT939kx/5/VX/K501FVZ6gMIM2LURTnkYZufMykv7 FD5k5Z9JfCA2iZeGGw9jYv+6raLplfh5Ny9B6guX4OkeHUe3JYbf41opTWMKSm8i0IR0 KO1qhj/6VgPP1WFgHeLr+ErTb0KjThd4DYlXLxUXhlMfpeEg9cyr0CzVOga5KvJB+KSz wxClK5KC1YK1s+S0dTgo0Jxebc/qM2HtSGCbkPAjKXocX97b3Xq+MoxHOpgkO5O5XjL1 kFVQ== X-Gm-Message-State: AOUpUlFSAog5q6WOeAfDrv3nWuaakBbfAsXIbfmU63b4oFGHW3TFbVpJ bot9QMSdO4DR4vE//KrSFFg08A== X-Google-Smtp-Source: AA+uWPyUjjuM2lzYckIV9dJ+I2UxdVDTkq0n2tFidOeFPiBmnxopXaPTuO+dG3wUOKgoPVH6wPWctQ== X-Received: by 2002:a62:f909:: with SMTP id o9-v6mr56047791pfh.141.1534907631947; Tue, 21 Aug 2018 20:13:51 -0700 (PDT) Received: from [192.168.0.28] (173-164-180-199-SFBA.hfc.comcastbusiness.net. [173.164.180.199]) by smtp.gmail.com with ESMTPSA id x10-v6sm368355pge.23.2018.08.21.20.13.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 20:13:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Native Encryption for ZFS on FreeBSD CFT From: Sean Fagan In-Reply-To: Date: Tue, 21 Aug 2018 20:13:49 -0700 Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Somers X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 22 Aug 2018 04:20:05 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 03:13:53 -0000 On Aug 21, 2018, at 8:11 PM, Alan Somers wrote: > The last time I looked (which was a long time ago), Oracle's ZFS = encryption looked extremely vulnerable to watermarking attacks. Did = anybody ever fix that? This isn=E2=80=99t Oracle=E2=80=99s implementation, but I don=E2=80=99t = know how compatible or not it is with it. Sean. From owner-freebsd-current@freebsd.org Wed Aug 22 04:29:28 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 91AA1108BAB9 for ; Wed, 22 Aug 2018 04:29:28 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 143B2808CA; Wed, 22 Aug 2018 04:29:28 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: by mail-pf1-x433.google.com with SMTP id h69-v6so368683pfd.4; Tue, 21 Aug 2018 21:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2DVDW/o6/cbc/CObPm/SHpdiRmdBZvCCfMZ7rRjChk0=; b=jnqV5D2/sxgvUVr7irUXVPYpFFV07H7Qvn5vmkZamNf67JaNWPjowTbBBVo1uZx7LM 6ukWrylAcXpsFEJTcc7jqd1JUd0Gok6j2Jj6IQdGx8sW5UcABUy4J1tVSd1rHVNQ4HFi /CFibeI5ms4FTYRFS4WEVoWMPGjF1r5NGQUtLZgmprYqw4T1YPBwxXiwAYF1ii0fT8yH LioyLL3iHeofh74bBdcmaOpUYyuET79oSPsn93dqjQY+F/KOL2ZdNIrCk18t+aNVEDYn V80wQDQ0qjHMqGVr6RyOwwJoKZ8d0Yzokd5oAI2UM0sEnq5KYtb+etzhbQNh1gGEx04b AIJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2DVDW/o6/cbc/CObPm/SHpdiRmdBZvCCfMZ7rRjChk0=; b=nrVcsHSMfNf+U9LL8LTM04fUP45JuUnRnel6hZbBx55ZWLR0IE2SVGmRPIThmdjXwq 0PgUGUI7EzfFO//rIcdmzabSbfFOk5EeU3VGP7Zt9MDoVX7ce3uExTkoFS3Ej5tItA+1 Z8s12v7ytvxAzp+6FdoCGO+T25oYjESOSWN5eUvZ4CbW4OA5FCZMjkrHMfmPU4GzzI6z wxE6siu6stEuvYmuf0tgU8cuIK3Kp+Sv+hVVzdmM69CkzoTyBopwVYhCBSW80l/wTbty YUF8bqREX/YZ07Nqk3A85SwLl2d5JDPNHp9dbDfC3r4FcLoFYzNWwsKp/VGG+Qt6+yOW twrw== X-Gm-Message-State: AOUpUlETrhHyg+JvsL4RW7iWNdTfFhMU1QimDqbO6EEZe+KGwmAD5KNr bagBtERIhqrMPKBdYqJM8t84NU+x4HBHlg== X-Google-Smtp-Source: AA+uWPw1SDZBomEo1l1WskQ1zfMf2+5QY+wyEN0oRyMZ2ln6a6RtdIiBhHAnRYi2/LKsB7H+03lkMg== X-Received: by 2002:a63:9e0a:: with SMTP id s10-v6mr50040476pgd.326.1534912166854; Tue, 21 Aug 2018 21:29:26 -0700 (PDT) Received: from octo.pozo.com (50-197-129-138-static.hfc.comcastbusiness.net. [50.197.129.138]) by smtp.gmail.com with ESMTPSA id d12-v6sm534771pfk.69.2018.08.21.21.29.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 21:29:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) From: Manfred Antar In-Reply-To: <20180822022343.GA60855@FreeBSD.org> Date: Tue, 21 Aug 2018 21:29:25 -0700 Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> References: <20180822022343.GA60855@FreeBSD.org> To: Alexey Dokuchaev X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 04:29:28 -0000 > On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev = wrote: >=20 > On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>=20 >> -------- =D0=9F=D0=B5=D1=80=D0=B5=D0=BD=D0=B0=D0=BF=D1=80=D0=B0=D0=B2=D0= =BB=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD= =D0=B8=D0=B5 -------- >> =D0=A2=D0=B5=D0=BC=D0=B0: nvidia-driver build error (last ports, = FreeBSD-HEAD) >> =D0=94=D0=B0=D1=82=D0=B0: Tue, 21 Aug 2018 16:41:42 +0700 >> =D0=9E=D1=82: Alex V. Petrov >> =D0=9A=D0=BE=D0=BC=D1=83: FreeBSD Ports >=20 > Should be fixed as of r477761. >=20 > ./danfe emulators/open-vm-tools is also broken from the recent changes to = sys/vm: cc -O2 -pipe -isystem /usr/local/include -fno-strict-aliasing -Werror = -D_KERNEL -DKLD_MODULE -nostdinc = -I/usr/ports/emulators/open-vm-tools/work/open-vm-tools-stable-10.2.5/open= -vm-tools/lib/include = -I/usr/ports/emulators/open-vm-tools/work/open-vm-tools-stable-10.2.5/open= -vm-tools/modules/shared/vmxnet -I. -I/usr/src/sys = -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer -MD -MF.depend.if_vxn.o -MTif_vxn.o = -mcmodel=3Dkernel -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 -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__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-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 -c = if_vxn.c -o if_vxn.o --- vmmemctl --- os.c:410:68: error: too many arguments to function call, expected 2, = have 3 p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, = M_WAITOK | M_ZERO); ~~~~~~~~~~~ = ^~~~~~~~~~~~~~~~~ /usr/src/sys/sys/malloc.h:55:18: note: expanded from macro 'M_WAITOK' #define M_WAITOK 0x0002 /* ok to block */ ^ /usr/src/sys/vm/vm_extern.h:67:1: note: 'kmem_malloc' declared here vm_offset_t kmem_malloc(vm_size_t size, int flags); ^ 1 error generated. I also had to rebuild kde-workspace-kde4 and xorg-server before i could = start x without open-vm-tools. This is on a FreeBSD-12-Alpha2-current as of today.the old = open-vm-tools/modules/freebsd/vmmemctl will hang,so i needed to uninstall it to get x. if these lines are removed from = open-vm-tools/modules/freebsd/vmmemctl/os.h open-vm-tools will compile = and work: 407,411d406 < #if __FreeBSD_version < 1000000 < p->bitmap =3D (unsigned long *)kmem_alloc(kernel_map, p->size); < #else < p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, = M_WAITOK | M_ZERO); < #endif Not sure if this is the right fix but it enabled me to use the vm-tools = again and the associated modules Manfred From owner-freebsd-current@freebsd.org Wed Aug 22 05:46: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 A8D26108D6D4 for ; Wed, 22 Aug 2018 05:46:52 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mx0b-0010f301.pphosted.com (mx0b-0010f301.pphosted.com [148.163.153.244]) (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 41D8682FE0; Wed, 22 Aug 2018 05:46:52 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (m0102860.ppops.net [127.0.0.1]) by mx0b-0010f301.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7M57jdQ027338; Wed, 22 Aug 2018 00:10:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice.edu; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=ricemail; bh=YxfCArEp0sBX76dHoa7iFLNCYaUf2SeSlyUBCq8ZPcY=; b=YDu3o5rrwOONkRXuSEzjlQwMQs7muBCBGJw3ZF5WJnB3YfZGIi9uavE24NAraCrEp8NC q4uC3Fsxa3GHAbEJAmBKwHaJuRfAsVmKz/YUv4q8sqLH4vqGu5RsnQCtv/iDhQ0C49yp iotB19muP1AhaJUZwDtVgCAedv+VX9q2xcJ1UHLGEu9jW3FAM+w2oPkhso8+NyGmFE7u wIT7ALHoRHioWG3FBSQNwjtmOVuUrhrbORFuZE+7T6cQIi0SZcEwyeTi8tR1QKbaMVhy Mj+kGx5hswFOkHLbVH5dQ+oNPNXoST7X4fWDGJM8SSM3e8Z1Xw6+nxuUjxJOPPGgukbR 9w== Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx0b-0010f301.pphosted.com with ESMTP id 2kxgu24vmw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Aug 2018 00:10:13 -0500 Received-X: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id E8E0E4C0724; Wed, 22 Aug 2018 00:10:12 -0500 (CDT) Received-X: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id BFF454C059F; Wed, 22 Aug 2018 00:10:12 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received-X: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id tLAQplOhRd34; Wed, 22 Aug 2018 00:10:12 -0500 (CDT) Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 392D94C0724; Wed, 22 Aug 2018 00:10:12 -0500 (CDT) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) To: Manfred Antar , Alexey Dokuchaev Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> From: Alan Cox Openpgp: preference=signencrypt Autocrypt: addr=alc@rice.edu; prefer-encrypt=mutual; keydata= xsBNBFG8q4IBCADBE55F7sX+cKhEadxhNkXrbtVSJhw3TQDPvc3nBWxsfdMAhPWozhpLczV/ hr8mDJV5tirit0qhw4ANPwtsn7i/xlcSdC9p8Jvkcpp/AfiA5B78Y08AsC6K6tbNHZ06qPq3 eCXDNbPzsUXyvyt25A+ZnQj4HbW4FpA6C5ITG1eeJPGO8WV9vhBQ4X/BWI61RXaJw68Jxtwo c9eovzdxbWTd5po/oGHL2ganYoBMu1OGpGFWvTDwy2ARCV7i+fSkfKXUPaQm17AuVVbZu8OU Ig6caCEA5MlZVsMpwuJQp7xdEQzPaDML3drkl32l3Rb09g5vKjjLHb+LXx/7PyeEWsG1ABEB AAHNGkFsYW4gQ294IDxhbGNARnJlZUJTRC5vcmc+wsB4BBMBAgAiBQJRvK14AhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCFEwQ8M+KJO7tKB/462f5Zzygqera1acLTIrIfdDXp cfyq3+OhFzbBh91b2Jw+CVKvH+hVpCUSW86Sgfv4sSvgsqdS9nMwN82MZDchNROfkkoY1Nkl 0EgayOmOoYroRp1bM65OZAMrw7qK/iG8FeJ1s6ex4wSSfeRETmFNhK0KMfTeLiKlIjW+KhIQ h+trVIWt9ZlvHI3xw6RUuEQ1CFvzETcwj/+YxLd8aha0Mr6qW/4VDw0G9g+YnqR8jnm1dOsO x8s+vJt2QmRuWGSsj5nk9Dc+Tpzytbvrv3rOCsEwuadWZU53/wL576XnqliWwkte3njN+BwI LoDuKBoqxIvdqI7lqTzYdww5BPd3zsBNBFG8q4IBCAC0hrybH/nTPvIeQm5qa5ZzwThdjb6y otBFjl/5LnMNfa2yhhJp0tQkr/WsJ/RiaYEmp7bGKnowbKR+6X7MF6qcRHwEPpibN8fpxKFg JlvhQhQWmU7nuBWqt8I1/y8aVLci7BPLRk6IKaMQJWWk18Wetijnao5gGEFu/iF9CzbYmJ/U ijVMJj08WlhQCiPnKFkirV8XjAOER5F2ecfLtfPLL/bZ+/Wm6xM+eo1ipc30oRf1Z7Rkcg94 RjiRpVacSnBQEFMXukD33w6WaKYT18B4rwN27tJfzTmGKRKggWEc3EWeQgzi3rD7x35owBJ7 x+G6lIjdSG4o9ytB3qTVazo3ABEBAAHCwF8EGAECAAkFAlG8q4ICGwwACgkQhRMEPDPiiTuH kAgAo3MUNRzGplyvgPezfnLgnwtlDYMF1HWp+67IIvY3WwcC51FQNHWmGis+H7Bor+aeSAfo KREw9l4U0Tu2YC9uiWKZzA4zer2WMhsB4VGMQ8GPuE2R2sFob5n293FsLWDSWM4Midory9zN EAYQ+Ijpv8WaATS217YYygA+iFlfMmQSKDS1G6HBnUjzQe23sX/06JAAxAvwmOI7OjwLlOCU Q5FaHPz6s8UjdHpZ/OUTElc7URPTr/KramlLhwuTRC2p8XyBrzYqz3Kfl42jEcOuxeHy07DG dm1Euqa5/CKTNBhMWjcujz11TUeI9+f5J2xUSlbj7nGJsnL5P34+SvtsKg== Message-ID: <86b09a54-9394-675e-3722-7007fa66c9c1@rice.edu> Date: Wed, 22 Aug 2018 00:10:11 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-22_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808220052 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 05:46:52 -0000 On 08/21/2018 23:29, Manfred Antar wrote: > >> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrot= e: >> >> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>> -------- =D0=9F=D0=B5=D1=80=D0=B5=D0=BD=D0=B0=D0=BF=D1=80=D0=B0=D0=B2= =D0=BB=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5= =D0=BD=D0=B8=D0=B5 -------- >>> =D0=A2=D0=B5=D0=BC=D0=B0: nvidia-driver build error (last ports, Free= BSD-HEAD) >>> =D0=94=D0=B0=D1=82=D0=B0: Tue, 21 Aug 2018 16:41:42 +0700 >>> =D0=9E=D1=82: Alex V. Petrov >>> =D0=9A=D0=BE=D0=BC=D1=83: FreeBSD Ports >> Should be fixed as of r477761. >> >> ./danfe > emulators/open-vm-tools is also broken from the recent changes to sys/v= m: > cc -O2 -pipe -isystem /usr/local/include -fno-strict-aliasing -Werror= -D_KERNEL -DKLD_MODULE -nostdinc -I/usr/ports/emulators/open-vm-tools/w= ork/open-vm-tools-stable-10.2.5/open-vm-tools/lib/include -I/usr/ports/em= ulators/open-vm-tools/work/open-vm-tools-stable-10.2.5/open-vm-tools/modu= les/shared/vmxnet -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -f= no-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -M= F.depend.if_vxn.o -MTif_vxn.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -m= no-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwra= pv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-pr= ototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-po= inter-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdi= agnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compar= e -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused= -function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-ad= dress-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 -c if_vxn.= c -o if_vxn.o > --- vmmemctl --- > os.c:410:68: error: too many arguments to function call, expected 2, ha= ve 3 > p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, M_= WAITOK | M_ZERO); > ~~~~~~~~~~~ ^~~~= ~~~~~~~~~~~~~ > /usr/src/sys/sys/malloc.h:55:18: note: expanded from macro 'M_WAITOK' > #define M_WAITOK 0x0002 /* ok to block */ > ^ > /usr/src/sys/vm/vm_extern.h:67:1: note: 'kmem_malloc' declared here > vm_offset_t kmem_malloc(vm_size_t size, int flags); > ^ > 1 error generated. > > I also had to rebuild kde-workspace-kde4 and xorg-server before i could= start x without open-vm-tools. > This is on a FreeBSD-12-Alpha2-current as of today.the old open-vm-tool= s/modules/freebsd/vmmemctl > will hang,so i needed to uninstall it to get x. > > if these lines are removed from open-vm-tools/modules/freebsd/vmmemctl/= os.h open-vm-tools will compile and work: > > 407,411d406 > < #if __FreeBSD_version < 1000000 > < p->bitmap =3D (unsigned long *)kmem_alloc(kernel_map, p->size); > < #else > < p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, = M_WAITOK | M_ZERO); > < #endif > > Not sure if this is the right fix but it enabled me to use the vm-tools= again and the associated modules Change this to #if __FreeBSD_version < 1000000 p->bitmap =3D (unsigned long *)kmem_alloc(kernel_map, p->size); #elif __FreeBSD_version < 1200080 p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, M_WAITOK | M_ZERO); #else p->bitmap =3D (unsigned long *)kmem_malloc(p->size, M_WAITOK | M_ZERO= ); #endif That said, it's not clear to me why this allocation doesn't use malloc(9), then no #if's would be required across different versions of FreeBSD. From owner-freebsd-current@freebsd.org Wed Aug 22 07:06: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 9403D108F3A2; Wed, 22 Aug 2018 07:06:11 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11AAE8609B; Wed, 22 Aug 2018 07:06:11 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id o18-v6so1102872wmc.0; Wed, 22 Aug 2018 00:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kv9NBQ1OU4NjWKQca39SP/buz3RX95dJPCu8EWhHrK8=; b=F2hC6QsqP7daI3Xh0dw7BLkVlGlcxp4Z7OtoJAViqTOPiUYFPlRRQwX16IcXu9vbZk rwsxKKWWzzSYFRahVBpHxDHWd8KwLMYodF8lZm82ItEqnikMZIhlOzp71YmMfZkMLQj8 ITs24Jx2IPcgRFX13fn39KvdxcAZcGT+k+69tAMvymPjoOeciS/sZ1pQkhTtwPyDYtXq Wq/QnPNhwMIrMkrfUW/yFcdU1WPvYYskxmI3ZlDo1uMk6Tx3uRO1u390G6ExovoWU7JM I86fWM2PoIp/vQMBiTGX3PyE3aUNQCDWmLQmLcK2mXyxYN5s+F6mOfuUfFXRLvMuVpa8 W+tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kv9NBQ1OU4NjWKQca39SP/buz3RX95dJPCu8EWhHrK8=; b=iNUzeE5872Uz8+TpS52SyaPa6HoevaPTnygYF5K80pO95pX6ultBu00B55RxHvj8X/ YYglSSB9VaRsrRyCUndEdJcFr+Sy5BQUAcqdnBuGpao1NzFMaJ0lZiz+fdimnj/h1DS7 XCfpzqKBHqZGzbyEq+xwSkHGCX4r2WVfAjHt7hBwGBlQ5ookRoGM+EuO37K12AoZsq4m 74Mn+KBSSSIAPmuk1lLkY0j46QTdsId1A3YzqTQpkGJi4Tl9raIf4k4eFVMKX0cFg3pq O+7ebyTXfc9WpI1LCJnX9Xj8eOMSQ82BnOgq+6OQ4WFhyLBWbxKjuWF/bpXBPQ1pT/JB JMNg== X-Gm-Message-State: APzg51C0SN2TZzCXE3sqyfZHM4dErWdNOcrM/qhnDklEgYsjl7pCp97W 5ej7d5cyy6luI1tJKnPYqmLZlsu+es4MduNh8aEqPiRp X-Google-Smtp-Source: ANB0VdawG0q1D8Yq8mOTpmdMRawETmIEsROCcVOaGcO1B1yNdvGHcRUzbxA3WzzThZYYuyOtl2OuT2odSEOzbqlr9rI= X-Received: by 2002:a1c:98a:: with SMTP id 132-v6mr1537862wmj.86.1534921569731; Wed, 22 Aug 2018 00:06:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Outback Dingo Date: Wed, 22 Aug 2018 09:05:33 +0200 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: mmacy@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, sef@ixsystems.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 07:06:11 -0000 of course interesting work, but unfortunately, and as you know me, what would i say next cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/sys/cddl/compat/opensolaris -I/usr/src/cddl/compat/opensolaris/include -I/usr/src/cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/contrib/opensolaris/head -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/contrib/opensolaris/lib/libcmdutils -DWANTS_MUTEX_OWNED -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libthr/arch/amd64/include -g -DDEBUG=1 -DZFS_DEBUG=1 -DNEED_SOLARIS_BOOLEAN -g -MD -MF.depend.freebsd_crypto.o -MTfreebsd_crypto.o -std=iso9899:1999 -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c -o freebsd_crypto.o /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: warning: tentative definition of variable with internal linkage has incomplete non-array type 'struct mtx' [-Wtentative-definition-incomplete-type] static struct mtx freebsd_crypto_mutex; ^ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: note: forward declaration of 'struct mtx' static struct mtx freebsd_crypto_mutex; ^ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:35: error: expected identifier MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS Crypto mutex", MTX_DEF); ^ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS Crypto mutex", MTX_DEF); ^ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: error: tentative definition has type 'struct mtx' that is never completed static struct mtx freebsd_crypto_mutex; ^ /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: note: forward declaration of 'struct mtx' static struct mtx freebsd_crypto_mutex; ^ 2 warnings and 2 errors generated. *** Error code 1 On Wed, Aug 22, 2018 at 4:28 AM Matthew Macy wrote: > > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: > > > To anyone with an interest in native encryption in ZFS please test the > > projects/zfs-crypto-merge-0820 branch in my freebsd repo: > > https://github.com/mattmacy/networking.git > > > > > Oh and I neglected to state that this work is being supported by iX Systems > and the tree is all built on work done by Sean Fagan at iX Systems. Please > keep him in the loop on any problems encountered. > Thanks. > > > > > ( git clone https://github.com/mattmacy/networking.git -b > > projects/zfs-crypto-merge-0820 ) > > > > The UI is quite close to the Oracle Solaris ZFS crypto with minor > > differences for specifying key location. > > > > Please note that once a feature is enabled on a pool it can't be > > disabled. This means that if you enable encryption support on a pool > > you will never be able to import it in to a ZFS without encryption > > support. For this reason I would strongly advise against using this on > > any pool that can't be easily replaced until this change has made its > > way in to HEAD after the freeze has been lifted. > > > > > > By way of background the original ZoL commit can be found at: > > > > https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 > > > > Thanks in advance. > > -M > > > _______________________________________________ > 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 Aug 22 07:10: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 C8AEE108F65C; Wed, 22 Aug 2018 07:10:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ABB28649B; Wed, 22 Aug 2018 07:10:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 397E612120; Wed, 22 Aug 2018 07:10:29 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f44.google.com with SMTP id d16-v6so13095092itj.0; Wed, 22 Aug 2018 00:10:29 -0700 (PDT) X-Gm-Message-State: APzg51BNvH46zbazcb5xhnEsf+7LPRroCdIfKl6LQ2HuxOJKr+RwlZOD fT+ByiGiHHT9WGjHlSybe1xUhZfZgKGXNTN/JRM= X-Google-Smtp-Source: ANB0VdZHn6+WYWMY7qpNYAUqI43Rn/hVG2+2hyAEkKKaRrLKCzj8iFLsPNC/pJ+smqIS/9LE1SHZIv15HhW9MiqGHec= X-Received: by 2002:a24:704f:: with SMTP id f76-v6mr2161624itc.30.1534921828769; Wed, 22 Aug 2018 00:10:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Wed, 22 Aug 2018 00:10:16 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Outback Dingo Cc: freebsd-current , freebsd-fs , Sean Fagan Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 07:10:30 -0000 Yes. I _just_ rebased and broke world in the process. Fix coming up momentarily. -M On Wed, Aug 22, 2018 at 12:06 AM Outback Dingo wrote: > of course interesting work, but unfortunately, and as you know me, > what would i say next > > cc -target x86_64-unknown-freebsd12.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -I/usr/src/sys/cddl/compat/opensolaris > -I/usr/src/cddl/compat/opensolaris/include > -I/usr/src/cddl/compat/opensolaris/lib/libumem > -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common > -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs > -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua > -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs > -I/usr/src/sys/cddl/contrib/opensolaris/uts/common > -I/usr/src/cddl/contrib/opensolaris/head > -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair > -I/usr/src/cddl/contrib/opensolaris/lib/libcmdutils > -DWANTS_MUTEX_OWNED -I/usr/src/lib/libpthread/thread > -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libthr/arch/amd64/include > -g -DDEBUG=1 -DZFS_DEBUG=1 -DNEED_SOLARIS_BOOLEAN -g -MD > -MF.depend.freebsd_crypto.o -MTfreebsd_crypto.o -std=iso9899:1999 > -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pragmas > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c > -o freebsd_crypto.o > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: > warning: tentative definition of variable with internal linkage has > incomplete non-array type 'struct mtx' > [-Wtentative-definition-incomplete-type] > static struct mtx freebsd_crypto_mutex; > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: > note: forward declaration of 'struct mtx' > static struct mtx freebsd_crypto_mutex; > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:35: > error: expected identifier > MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS > Crypto mutex", MTX_DEF); > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:1: > warning: type specifier missing, defaults to 'int' [-Wimplicit-int] > MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS > Crypto mutex", MTX_DEF); > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: > error: tentative definition has type 'struct mtx' that is never > completed > static struct mtx freebsd_crypto_mutex; > ^ > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: > note: forward declaration of 'struct mtx' > static struct mtx freebsd_crypto_mutex; > ^ > 2 warnings and 2 errors generated. > *** Error code 1 > On Wed, Aug 22, 2018 at 4:28 AM Matthew Macy wrote: > > > > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: > > > > > To anyone with an interest in native encryption in ZFS please test the > > > projects/zfs-crypto-merge-0820 branch in my freebsd repo: > > > https://github.com/mattmacy/networking.git > > > > > > > > Oh and I neglected to state that this work is being supported by iX > Systems > > and the tree is all built on work done by Sean Fagan at iX Systems. > Please > > keep him in the loop on any problems encountered. > > Thanks. > > > > > > > > > ( git clone https://github.com/mattmacy/networking.git -b > > > projects/zfs-crypto-merge-0820 ) > > > > > > The UI is quite close to the Oracle Solaris ZFS crypto with minor > > > differences for specifying key location. > > > > > > Please note that once a feature is enabled on a pool it can't be > > > disabled. This means that if you enable encryption support on a pool > > > you will never be able to import it in to a ZFS without encryption > > > support. For this reason I would strongly advise against using this on > > > any pool that can't be easily replaced until this change has made its > > > way in to HEAD after the freeze has been lifted. > > > > > > > > > By way of background the original ZoL commit can be found at: > > > > > > > https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 > > > > > > Thanks in advance. > > > -M > > > > > _______________________________________________ > > 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 Aug 22 07:21: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 9FC4F108FBBA; Wed, 22 Aug 2018 07:21:12 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5124886CC0; Wed, 22 Aug 2018 07:21:12 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 0E94412236; Wed, 22 Aug 2018 07:21:12 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f46.google.com with SMTP id d9-v6so1729152itf.2; Wed, 22 Aug 2018 00:21:12 -0700 (PDT) X-Gm-Message-State: AOUpUlFFBCePUTEAatVbVAimUB2zs+n2Aywx0GddzmdzWRv8N52a7BSZ PoJ/KZYBdbnFDTpCQz7109reZpwCh75TwFaiX0Y= X-Google-Smtp-Source: AA+uWPxCMEZCb3hTVFW5oeAVsJlMWP8wsgGjaEYPnFNk7ofYqKwAKyThOYXekE0NW7DHfv9V7YRqDCyGPHrbzaEFxZU= X-Received: by 2002:a02:88ad:: with SMTP id n42-v6mr7045573jaj.38.1534922471509; Wed, 22 Aug 2018 00:21:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Wed, 22 Aug 2018 00:20:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Outback Dingo Cc: freebsd-current , freebsd-fs , Sean Fagan Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 07:21:12 -0000 Fixed. Pull. bc2b257d1082112cc27e56db793f5c569f603bec On Wed, Aug 22, 2018 at 12:10 AM Matthew Macy wrote: > Yes. I _just_ rebased and broke world in the process. Fix coming up > momentarily. > -M > > On Wed, Aug 22, 2018 at 12:06 AM Outback Dingo > wrote: > >> of course interesting work, but unfortunately, and as you know me, >> what would i say next >> >> cc -target x86_64-unknown-freebsd12.0 >> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp >> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe >> -I/usr/src/sys/cddl/compat/opensolaris >> -I/usr/src/cddl/compat/opensolaris/include >> -I/usr/src/cddl/compat/opensolaris/lib/libumem >> -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common >> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs >> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua >> -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs >> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common >> -I/usr/src/cddl/contrib/opensolaris/head >> -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair >> -I/usr/src/cddl/contrib/opensolaris/lib/libcmdutils >> -DWANTS_MUTEX_OWNED -I/usr/src/lib/libpthread/thread >> -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libthr/arch/amd64/include >> -g -DDEBUG=1 -DZFS_DEBUG=1 -DNEED_SOLARIS_BOOLEAN -g -MD >> -MF.depend.freebsd_crypto.o -MTfreebsd_crypto.o -std=iso9899:1999 >> -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pragmas >> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable >> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality >> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef >> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum >> -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c >> -o freebsd_crypto.o >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: >> warning: tentative definition of variable with internal linkage has >> incomplete non-array type 'struct mtx' >> [-Wtentative-definition-incomplete-type] >> static struct mtx freebsd_crypto_mutex; >> ^ >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: >> note: forward declaration of 'struct mtx' >> static struct mtx freebsd_crypto_mutex; >> ^ >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:35: >> error: expected identifier >> MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS >> Crypto mutex", MTX_DEF); >> ^ >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:1: >> warning: type specifier missing, defaults to 'int' [-Wimplicit-int] >> MTX_SYSINIT(freebsd_crypto_mutex, &freebsd_crypto_mutex, "FreeBSD ZFS >> Crypto mutex", MTX_DEF); >> ^ >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19: >> error: tentative definition has type 'struct mtx' that is never >> completed >> static struct mtx freebsd_crypto_mutex; >> ^ >> >> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15: >> note: forward declaration of 'struct mtx' >> static struct mtx freebsd_crypto_mutex; >> ^ >> 2 warnings and 2 errors generated. >> *** Error code 1 >> On Wed, Aug 22, 2018 at 4:28 AM Matthew Macy wrote: >> > >> > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy wrote: >> > >> > > To anyone with an interest in native encryption in ZFS please test the >> > > projects/zfs-crypto-merge-0820 branch in my freebsd repo: >> > > https://github.com/mattmacy/networking.git >> > > >> > > >> > Oh and I neglected to state that this work is being supported by iX >> Systems >> > and the tree is all built on work done by Sean Fagan at iX Systems. >> Please >> > keep him in the loop on any problems encountered. >> > Thanks. >> > >> > >> > >> > > ( git clone https://github.com/mattmacy/networking.git -b >> > > projects/zfs-crypto-merge-0820 ) >> > > >> > > The UI is quite close to the Oracle Solaris ZFS crypto with minor >> > > differences for specifying key location. >> > > >> > > Please note that once a feature is enabled on a pool it can't be >> > > disabled. This means that if you enable encryption support on a pool >> > > you will never be able to import it in to a ZFS without encryption >> > > support. For this reason I would strongly advise against using this on >> > > any pool that can't be easily replaced until this change has made its >> > > way in to HEAD after the freeze has been lifted. >> > > >> > > >> > > By way of background the original ZoL commit can be found at: >> > > >> > > >> https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49 >> > > >> > > Thanks in advance. >> > > -M >> > > >> > _______________________________________________ >> > 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 Aug 22 09:03:51 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 A68B810828F1 for ; Wed, 22 Aug 2018 09:03:51 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9588B33F; Wed, 22 Aug 2018 09:03:51 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pg1-x535.google.com with SMTP id v66-v6so632180pgb.10; Wed, 22 Aug 2018 02:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YJW5aohngAX/0VjmjmJkDXb/xpE4mhRXGn1sdpPTfG4=; b=PimHoTUYdSEiQzNdNnjPWSzPFdrZN4aRk5kq7NzfrCWvWrZMeLPXFlN5TUMpd1XfNK a0mfAw2bv3qgUvViaIOnRlPetFWfgmpB+J5pJZCBl/B+ubcGoT7/CSkXtaUVxir+Gm4A 2zJ11s9kQZFGFjRrV3bC5Co7ihd0MAxUm9a6E+OZaADOElbb5uuaIW5k3aQHKz8HMK1L +5H/ct7gJiam8HJrHJkuYRlJl5tZOahEeykCarQVfhGsF7bz8haw+izNvNizZehKvEuk 8Wlu0/YAA36K2H/3lrRfoTfiScSfv5zzbs94V9Am5JBQWNRZNAVzKY4ib34JTmYI3XRf osVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YJW5aohngAX/0VjmjmJkDXb/xpE4mhRXGn1sdpPTfG4=; b=JESlGqAT5g8reMgxKfjiwJECVft1IZoqC2amAchAA2OYOvZ12zg3c2kPJkeJakJ26C +eKZdXPTJ18wNd+v7ZDPPDmjeh+HudYWXXpY43rj0pm6DI4PnjmNQSJZr9+auZYlwSwl dqWq4ESiotxfUaIVX6IiYBHIvhqMviuPrK+mDwXvr47L9Ls+l3YSpQ7tC1VK7FEAbiuf wEB24rgV5Rj55Rwl3/FwR+b8U9cdXuhitF9ZFayZ65bjr8iE6OrTZ+dwG5r6INg3U9iS iopBUHCOiAYa0Lg0o8BnY7e1TYQ9QVVG2WMK4jFYP1ol6f5M55H+Fl/LrZpHcCtx9p1/ gZkA== X-Gm-Message-State: AOUpUlHfKm3tA24gLsIsFfK03wpZLRwVraklh7Nbyeuc6PJBTDa5KOkd JfHl1XWFb6BgFN4+fMGIkpYvgu5esDY6sqGthdy/9FrCjgc= X-Google-Smtp-Source: AA+uWPyjNjl8Ol8RA8vcuWY+6ExDSBpwZ9gs54r9FACNCzWKkGq6a/zam7kaf7i4YXu5X4ojJpOrTxqocMGqch0tHdE= X-Received: by 2002:a63:3f45:: with SMTP id m66-v6mr23850901pga.51.1534928629897; Wed, 22 Aug 2018 02:03:49 -0700 (PDT) MIME-Version: 1.0 References: <201808201426.w7KEQo9j074809@pdx.rh.CN85.dnsmgr.net> <4ECEE41C-E1FF-4B6A-A138-3BDDB6552A7D@FreeBSD.org> <20180821202944.GB83826@spindle.one-eyed-alien.net> In-Reply-To: From: Samy Mahmoudi Date: Wed, 22 Aug 2018 11:03:38 +0200 Message-ID: Subject: Re: building LLVM threads gets killed To: Brooks Davis Cc: dim@freebsd.org, freebsd-rwg@pdx.rh.cn85.dnsmgr.net, blubee blubeeme , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 09:03:51 -0000 > That's exactly why I keep the following in my /boot/loader.rc: I meant "in my /boot/loader.conf"... From owner-freebsd-current@freebsd.org Wed Aug 22 09:11:28 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 547141082C24 for ; Wed, 22 Aug 2018 09:11:28 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B95AD8B790 for ; Wed, 22 Aug 2018 09:11:27 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id j192-v6so1104432wmj.1 for ; Wed, 22 Aug 2018 02:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=HetXXDVGzZ9nY5nJfvOzgg6lmfQFy42nSApEuXTgBKI=; b=oMyRSy6oz5jxW5NxY7EF6yvJ0pvNmgA1r5r1VQnrrvZHBcDqrmNpYqchl7MCW8MeSf SpoIqQb9YgC6C9WbS1zcy9nWRqc++M2xrCI1I/CvMXyP9lxudivlLoxQbeQKbePLMaCS I/IpLYxZ3IoIOIRtATTIYNhHFhVuO/4MPmTmxpcly4KQ0BLdstQJfHZU06rCdPM+CN/i nan0MNardXR8MrXrZq+0HgEtiRzB6NOHf9Yc4QbPgKcTH/nhgzc9k5KXpex/aY8YmPAA cCcy5eQb7w9Zj1kIzjRGJhq8kInIby+ppuFgYo/z/ZQoME5JGVCvboqF3mVVIe2hzyFP x4cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=HetXXDVGzZ9nY5nJfvOzgg6lmfQFy42nSApEuXTgBKI=; b=dJQNTbN/L7wsSFKn6VgahF65W0cbLE+Ba5XKcRQK3kQTZcAVpV7VZMQSKfWe7P2NdR MRAW54R+iMH5VNMS6GTviYjYz74rT1Ul4LPTuhP3Fh50n79FHTZ2fiFOjMtOgG+kMJGD iEz0v0UsFJI3OKach5CfwmIBwEYexwJiyyJIF+NsSqJKPZWwu3LSbyyO59U6mbSbSv8V /xKKe/CO5QbGaze4RiNMsFcmq8OB51Vn8WD+32qE5CXHPOrU31+U+Sf7YdptUi2unLSk 8/Uv758g3JoSYjWE+3cFl9WWVplxsoAX+e0crbvMj2EJUX9iGCXYFAJxuH5Zj+zVH3L5 SbJA== X-Gm-Message-State: APzg51CIRYy1M5hzj1aFmUckTSfswdU+3mtihcK7p7NrcRdepXu4YZjI HMBIZb2YT6LB7hCWMR/ejNCBYZeRlZmHQA== X-Google-Smtp-Source: ANB0VdZOX7ClmP+zmzCamtEQc5JoHsNRfBqHQtvr85Z+Tm3RKZIUzJHEMAGpejWZR5LicMvcP4J1UA== X-Received: by 2002:a1c:d98a:: with SMTP id q132-v6mr1898524wmg.78.1534929086119; Wed, 22 Aug 2018 02:11:26 -0700 (PDT) Received: from [192.168.1.231] (host-78-150-66-180.as13285.net. [78.150.66.180]) by smtp.gmail.com with ESMTPSA id a6-v6sm1221077wmf.22.2018.08.22.02.11.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 02:11:25 -0700 (PDT) To: freebsd-current From: Graham Perrin Subject: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M Message-ID: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> Date: Wed, 22 Aug 2018 10:11:24 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 09:11:28 -0000 HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M. If neither drm-stable-kmod nor drm-next-kmod is used – commenting out # kld_list="/boot/modules/radeonkms.ko" in /etc/rc.conf and if boot is pure UEFI, without CSM, then the notebook can reliably resume from suspend. There's a distinctive single amber pulse of the (normally blue) radio button before suspend occurs. However: - without CSM, most of the startup routine is illegible, 'torn' – for example, I can't see what's typed when I boot to single user mode. ---- If either drm-stable-kmod or drm-next-kmod is used and if boot is pure UEFI, then the notebook can not suspend. No amber pulse of the radio button. With and without drm-next-kmod: if boot is hybrid UEFI with CSM, then suspend occurs, but resume fails. No beep, the computer restarts. debug.acpi.resume_beep=1 in /boot/loader.conf for an audible beep. ---- Please: might graphics/drm-devel-kmod be better for either the tearing (without CSM) or for suspend? ---- $ date ; uname -v Wed 22 Aug 2018 09:51:39 BST FreeBSD 12.0-ALPHA2 #2 r337986: Fri Aug 17 22:01:23 BST 2018     root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG $ pkg info graphics/drm-stable-kmod drm-stable-kmod-g20180802 Name           : drm-stable-kmod Version        : g20180802 Installed on   : Wed Aug 22 06:43:35 2018 BST Origin         : graphics/drm-stable-kmod Architecture   : FreeBSD:12:amd64 Prefix         : /usr/local Categories     : graphics kld Licenses       : BSD2CLAUSE, MIT, GPLv2 Maintainer     : jmd@FreeBSD.org WWW            : https://github.com/FreeBSDDesktop/kms-drm Comment        : DRM modules for the linuxkpi-based KMS components Options        :         DEBUG          : off Annotations    :         FreeBSD_version: 1200078         repo_type      : binary         repository     : FreeBSD Flat size      : 7.51MiB Description    : amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components. Currently corresponding to Linux 4.9 DRM. More stable state. amdgpu and radeonkms are known to fail with EFI boot. WWW: https://github.com/FreeBSDDesktop/kms-drm $ pciconf -lv | grep -A 4 vga vgapci0@pci0:1:0:0:     class=0x030000 card=0x17a9103c chip=0x68411002 rev=0x00 hdr=0x00     vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'     device     = 'Thames [Radeon HD 7550M/7570M/7650M]'     class      = display     subclass   = VGA $ From owner-freebsd-current@freebsd.org Wed Aug 22 10:52: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 EE6761084ED3 for ; Wed, 22 Aug 2018 10:52:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C2F68EA2B for ; Wed, 22 Aug 2018 10:52:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [192.168.1.32] (ip-213-127-237-35.ip.prioritytelecom.net [213.127.237.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 593783A04F; Wed, 22 Aug 2018 12:52:53 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1F225774-3A61-47BD-9CE3-22B7D08CC4DE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: building LLVM threads gets killed Date: Wed, 22 Aug 2018 12:52:45 +0200 In-Reply-To: <0846E103-2DCC-421F-B82B-1BE287002468@yahoo.com> Cc: FreeBSD Current To: Mark Millard References: <0846E103-2DCC-421F-B82B-1BE287002468@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 10:52:55 -0000 --Apple-Mail=_1F225774-3A61-47BD-9CE3-22B7D08CC4DE Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 22 Aug 2018, at 04:01, Mark Millard wrote: > > Brooks Davis brooks at freebsd.org wrote on > Tue Aug 21 20:29:45 UTC 2018 : > >> On Mon, Aug 20, 2018 at 07:33:32PM +0200, Dimitry Andric wrote: >>> . . . >>> >>> I have attached a patch for most of the llvm ports, which sets the >>> LLVM_PARALLEL_LINK_JOBS CMake flag during the configure phase. >> >> Committed in r477756. >> > > lld itself has --threads (default) and --no-threads > (non-default, single threaded link). (Mark Johnston > recently made me aware of this.) In my quick experiment > in just one context, --threads used 5 or so threads > in the lld process. (Likely helps with speed when > the hardware threads are simply available without > conflicts.) > > Does LLVM_PARALLEL_LINK_JOBS contribute to which of > these is in use? No, it just controls how many link processes ninja starts in parallel. If those link processes use threads, like lld does by default, it is outside the control of ninja. Note that lld uses threads to speed up linking, but it might use more memory, so you could turn it off if you are memory constrained. -Dimitry --Apple-Mail=_1F225774-3A61-47BD-9CE3-22B7D08CC4DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW31AfQAKCRCwXqMKLiCW oyt/AJ4kqoLdR1ZusuitzPa+oiQ6+nBncwCfdocDvjVJBqGTkVdnQ/mT3wFZ2Hc= =JDep -----END PGP SIGNATURE----- --Apple-Mail=_1F225774-3A61-47BD-9CE3-22B7D08CC4DE-- From owner-freebsd-current@freebsd.org Wed Aug 22 12:37: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 A77721087D61 for ; Wed, 22 Aug 2018 12:37:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660044.outbound.protection.outlook.com [40.107.66.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DCC4721E4 for ; Wed, 22 Aug 2018 12:37:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM (52.132.44.160) by YTOSPR01MB019.CANPRD01.PROD.OUTLOOK.COM (52.132.51.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.14; Wed, 22 Aug 2018 12:37:42 +0000 Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127]) by YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127%3]) with mapi id 15.20.1080.010; Wed, 22 Aug 2018 12:37:42 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" Subject: Heads up: nfsuserd -use-udpsock option no longer used Thread-Topic: Heads up: nfsuserd -use-udpsock option no longer used Thread-Index: AQHUOhRsS3eww7Am5UKszkG+9g0+ZQ== Date: Wed, 22 Aug 2018 12:37:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOSPR01MB019; 6:Awf2wcdDbIoIPkJIjWCZm0CbvRgbvpX4kuWKAYFk0QEZ6C2iLA+oGtXbK2sI5nkWVBGLGZmf5HEbTMPGbS6+4BLHD4wNgvQKXcXYnEsa06QVfQFs2LvH90J1YpefEMHmR8jLsvGThVXoPPG04PNJJq6CxVytSmgYolS3zoG+btapo86kJL1cSKdGzQd72DvfvAbFFfJqfElCQ9kgls5s2I843XsPtPlPsP4mIAVC+u31hTmYK07DmJOwpYgf4+tUNGpZkeeJCMiTfmlueolDFedS+7T01wrP6I4R0D4AeW4u9a9UDGtDmNzo49L0k5d0qYSyJlq4eZYsniiGfhDyhPYWMVrykpFuncf2MTF/KQO2ijuqS0mo+W+OzZFgoLHdqUZnUmGqvbc46N9XxRI0aURVsnY6TzTnZ3oBDG0TZfv2I/RI6zJdZGRPqAzebDiYt3e9cAlUPM4Yud2Yq5qLmw==; 5:J/OtsFelDCdj18GM22rlH8DejrmDaaWnJFCLDQ2XvG3hdCANIRXkFNsLtOfCkeLh64/lXO7Ks/LE7VNJcgnCdLWV5L0WRGvAF2kOOWrgH/F0mG2fch10E3wfyx1o2yuVWdMB6lXPm+cokDujG0Sde66cKmpyHEGpJ1QbsFpqLIU=; 7:T8laNjPlkHtmn7eVc2SQ0JsAvwy9Qzpp5/KxjvUV6xgUKBL+rHHibo9HjrY00L5gRlq6z79EsagG17aReTUeAp5UTR+M3gBnwG1TRtOjRQFvEBTBX/qvMq2G6VAsqUtoP1RtPag4O5nx9hBNgyawOxkdzCVM0KPaUFPQ6ME1G2okHO4DjjP3LaigAMjRTabxG5x9rYS0vFSXlsPX2D4lp6xYcG8VDayraCvdU3JJukmC4zOh9L4+MHCxzJvgQdag x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 12eec23f-9ca4-4ff1-bec4-08d6082c0db9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOSPR01MB019; x-ms-traffictypediagnostic: YTOSPR01MB019: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699016); SRVR:YTOSPR01MB019; BCL:0; PCL:0; RULEID:; SRVR:YTOSPR01MB019; x-forefront-prvs: 0772E5DAD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(376002)(396003)(39860400002)(199004)(189003)(8936002)(5640700003)(68736007)(74482002)(97736004)(33656002)(2906002)(6506007)(6916009)(6436002)(55016002)(7696005)(14454004)(256004)(99286004)(86362001)(478600001)(2501003)(53936002)(9686003)(5250100002)(105586002)(25786009)(486006)(106356001)(316002)(786003)(2351001)(81156014)(81166006)(8676002)(476003)(102836004)(2900100001)(26005)(5660300001)(305945005)(74316002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOSPR01MB019; H:YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: kBrq2kom16Y/nmQ86tvi3K7IVoSJk2DTXOjr8dcBRbzMotWosQgUCMPwu/UMoAUhPiZ+AT9nJg18J+Wfb6aGDOv4R36jjG+rEd0f9KWPun6idkeHILg7q3B7rg6vOmysLEYOpqQe14QTKOdZu286uMIbFaNVF7m9GI0WXbVgL93aIumUbThMYI+GQYddT7DD06Pc/JS3ei53kCpnSaRMNgGA1RX5bDNMFclKZyHw/5ZK50vRoAabd2SHi3kBzUOIECJ0PLFvvk+SBIp53HHjY7tBiCGrrLvX9kbe5XD/5nLmvyYFhzhtpGrUToVkwceQCE7tAurdL1/TqLSQ1qypx3EzmnerMz0cUprIa4nKQoE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 12eec23f-9ca4-4ff1-bec4-08d6082c0db9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2018 12:37:42.1063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOSPR01MB019 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 12:37:43 -0000 As of r338192 the command line option "-use-udpsock" no longer exists, since r320757 has been reverted. The behaviour is now back to always using a UDP socket the same as stable/1= 1. In other words, if you are using the nfsuserd with the "-use-udpsock" optio= n, just get rid of the "-use-udpsock" option and you will still have that behaviour= . rick From owner-freebsd-current@freebsd.org Wed Aug 22 13:48: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 B3ED7108985E for ; Wed, 22 Aug 2018 13:48:44 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F15E74FA8; Wed, 22 Aug 2018 13:48:43 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DD4672D6; Wed, 22 Aug 2018 09:48:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Aug 2018 09:48:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=2FoGBJVhAApc53ecZf1Vxwn4O9WA6 lP3zv7MO+/Dgl4=; b=UjpsMkbc9vzXPc/PiE791Ov7MnK46gLvlHj1aT94DlZ/q 5SQVVhnoBsaM3M53CwF+JOFR8fXabj2FboRg5+LQE1oFux9xneNMDcW0dk5sb8vd Ir4mO6cYBli5fEcIHrNa/X2mMn26ueaG8jACssmHELr+gCKTIPYkvgiwTGYM3JnX Y07BcN7eD2yVaOxWzgJor5z77yeczoze5Tfk6+nuXqg+z8g0xtAYwa2Xg8S1sPhV wG5lx8ayvvT/y3IgEg05MwkHgPWlnbTM1Xpq00dOuHMeoT4aVFFofTZ13V6vlg8z SLVbKf5qeHgDq07wDgKIdhcJm3oG1zzLKLqTfoV0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=2FoGBJ VhAApc53ecZf1Vxwn4O9WA6lP3zv7MO+/Dgl4=; b=fyataDV31N+euObxPeU2/O x7bcj21Xx3/MNwB2Rk/LXkMZfucCMW3TfnlHo7iKV7+nl8qFyeHaEkoxKSVPw6nx 4NvnTUff2fdw0Fk6ITkl1BDyc/41C+thLwGTfMBjOCpmyokvzacoFCifRKfnc8Kg wFR3EE+ou8uXkHoLI192EpsDoN+Goes4el4sggHT/JknO5pCK1YlBFqpT2Fspdjt FdB4XGhFGD8v/LyzbOon0o5cugV/gxrDDLsHCOVrmtNjNWZtYPLfal/eGoo1nn45 QRgcp3vx/bZU3CZFkxiupZp0o2QoNh+x+0uTN56jZ/Stn6jIMXZwdd0QFKgYKtaw == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 7DE96E48A7; Wed, 22 Aug 2018 09:48:34 -0400 (EDT) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) To: Manfred Antar , Alexey Dokuchaev Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> From: tech-lists Organization: none Message-ID: <60982d01-7d08-25b7-97c5-009a6be13b88@zyxst.net> Date: Wed, 22 Aug 2018 14:48:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> 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.27 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, 22 Aug 2018 13:48:45 -0000 On 22/08/2018 05:29, Manfred Antar wrote: > >> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote: >> >> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>> -------- Перенаправленное сообщение -------- >>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >>> Дата: Tue, 21 Aug 2018 16:41:42 +0700 >>> От: Alex V. Petrov >>> Кому: FreeBSD Ports >> Should be fixed as of r477761. >> >> ./danfe It's not fixed, seems to error elsewhere now: context: 12.0-ALPHA1 #0 r337886 / ports r477782 / empty /etc/make.conf This is a bare metal installation. root@desktop:/usr/ports/x11/nvidia-driver# make distclean && make clean && make MAKE_JOBS_UNSAFE=yes [...] cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-compare -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.nvidia_subr.o -MTnvidia_subr.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 -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-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_subr.c -o nvidia_subr.o nvidia_subr.c:1131:41: error: too many arguments to function call, expected 7, have 8 sc->dma_mask, PAGE_SIZE, 0, attr); ^~~~ /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, ^ nvidia_subr.c:1269:45: error: too many arguments to function call, expected 7, have 8 sc->dma_mask, PAGE_SIZE, 0, attr); ^~~~ /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, ^ 2 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia *** Error code 1 Stop. make[3]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src *** Error code 1 Stop. make[2]: stopped in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 *** Error code 1 Stop. make[1]: stopped in /usr/ports/x11/nvidia-driver *** Error code 1 Stop. make: stopped in /usr/ports/x11/nvidia-driver root@desktop:/usr/ports/x11/nvidia-driver# -- J. From owner-freebsd-current@freebsd.org Wed Aug 22 15:29:08 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 986B5108BC02 for ; Wed, 22 Aug 2018 15:29:08 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mx0b-0010f301.pphosted.com (mx0b-0010f301.pphosted.com [148.163.153.244]) (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 01D24792DD; Wed, 22 Aug 2018 15:29:07 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (m0102858.ppops.net [127.0.0.1]) by mx0b-0010f301.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7MF5neC007365; Wed, 22 Aug 2018 10:29:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice.edu; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=ricemail; bh=XTaOmK7sCCxgRv38JtA+m19y8Aj6W7TFXTwoitbsfDk=; b=aUe5LUM7LRAWWqQFR7LZHD2Rcq85sp302nPQLfsaJ2E+01eF5iO2QVGSm0rbDGhsYykX +aliwlNDJVtvpoNKRiZ5UUkE7c6/TR5RLMFi37Zbg8GovGJH6X3tYsrRAbgXDftru+XG voQnHCjAMP7uJHNwBCh59GTP9Uy3ruxGKCLp1+VnyxH0NrLeADOdB+Diplo9d5Yj2SI6 el5hkQBIwfFJh7nLxZjrl86rsi7klrPynP51JvLDP8jfRPe7gBAcgU1P+SIkGP946cjw n+GQ8egutdFv3BD6H7kU+uhwLs32FcK+Dqy3JGzXY1eXQhlI01EMdmoH28oUINkUqbgU ug== Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx0b-0010f301.pphosted.com with ESMTP id 2m00fdke02-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Aug 2018 10:29:06 -0500 Received-X: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id E80964C0818; Wed, 22 Aug 2018 10:29:05 -0500 (CDT) Received-X: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id E54034C06B3; Wed, 22 Aug 2018 10:29:05 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received-X: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id xlU3Y9oHwXJo; Wed, 22 Aug 2018 10:29:05 -0500 (CDT) Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 736E84C0751; Wed, 22 Aug 2018 10:29:05 -0500 (CDT) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) To: tech-lists , Manfred Antar , Alexey Dokuchaev Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> <60982d01-7d08-25b7-97c5-009a6be13b88@zyxst.net> From: Alan Cox Openpgp: preference=signencrypt Autocrypt: addr=alc@rice.edu; prefer-encrypt=mutual; keydata= xsBNBFG8q4IBCADBE55F7sX+cKhEadxhNkXrbtVSJhw3TQDPvc3nBWxsfdMAhPWozhpLczV/ hr8mDJV5tirit0qhw4ANPwtsn7i/xlcSdC9p8Jvkcpp/AfiA5B78Y08AsC6K6tbNHZ06qPq3 eCXDNbPzsUXyvyt25A+ZnQj4HbW4FpA6C5ITG1eeJPGO8WV9vhBQ4X/BWI61RXaJw68Jxtwo c9eovzdxbWTd5po/oGHL2ganYoBMu1OGpGFWvTDwy2ARCV7i+fSkfKXUPaQm17AuVVbZu8OU Ig6caCEA5MlZVsMpwuJQp7xdEQzPaDML3drkl32l3Rb09g5vKjjLHb+LXx/7PyeEWsG1ABEB AAHNGkFsYW4gQ294IDxhbGNARnJlZUJTRC5vcmc+wsB4BBMBAgAiBQJRvK14AhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCFEwQ8M+KJO7tKB/462f5Zzygqera1acLTIrIfdDXp cfyq3+OhFzbBh91b2Jw+CVKvH+hVpCUSW86Sgfv4sSvgsqdS9nMwN82MZDchNROfkkoY1Nkl 0EgayOmOoYroRp1bM65OZAMrw7qK/iG8FeJ1s6ex4wSSfeRETmFNhK0KMfTeLiKlIjW+KhIQ h+trVIWt9ZlvHI3xw6RUuEQ1CFvzETcwj/+YxLd8aha0Mr6qW/4VDw0G9g+YnqR8jnm1dOsO x8s+vJt2QmRuWGSsj5nk9Dc+Tpzytbvrv3rOCsEwuadWZU53/wL576XnqliWwkte3njN+BwI LoDuKBoqxIvdqI7lqTzYdww5BPd3zsBNBFG8q4IBCAC0hrybH/nTPvIeQm5qa5ZzwThdjb6y otBFjl/5LnMNfa2yhhJp0tQkr/WsJ/RiaYEmp7bGKnowbKR+6X7MF6qcRHwEPpibN8fpxKFg JlvhQhQWmU7nuBWqt8I1/y8aVLci7BPLRk6IKaMQJWWk18Wetijnao5gGEFu/iF9CzbYmJ/U ijVMJj08WlhQCiPnKFkirV8XjAOER5F2ecfLtfPLL/bZ+/Wm6xM+eo1ipc30oRf1Z7Rkcg94 RjiRpVacSnBQEFMXukD33w6WaKYT18B4rwN27tJfzTmGKRKggWEc3EWeQgzi3rD7x35owBJ7 x+G6lIjdSG4o9ytB3qTVazo3ABEBAAHCwF8EGAECAAkFAlG8q4ICGwwACgkQhRMEPDPiiTuH kAgAo3MUNRzGplyvgPezfnLgnwtlDYMF1HWp+67IIvY3WwcC51FQNHWmGis+H7Bor+aeSAfo KREw9l4U0Tu2YC9uiWKZzA4zer2WMhsB4VGMQ8GPuE2R2sFob5n293FsLWDSWM4Midory9zN EAYQ+Ijpv8WaATS217YYygA+iFlfMmQSKDS1G6HBnUjzQe23sX/06JAAxAvwmOI7OjwLlOCU Q5FaHPz6s8UjdHpZ/OUTElc7URPTr/KramlLhwuTRC2p8XyBrzYqz3Kfl42jEcOuxeHy07DG dm1Euqa5/CKTNBhMWjcujz11TUeI9+f5J2xUSlbj7nGJsnL5P34+SvtsKg== Message-ID: <44324f5e-5146-7525-7a60-1b774fc5d85a@rice.edu> Date: Wed, 22 Aug 2018 10:29:05 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <60982d01-7d08-25b7-97c5-009a6be13b88@zyxst.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=11 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808220154 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 15:29:08 -0000 On 08/22/2018 08:48, tech-lists wrote: > On 22/08/2018 05:29, Manfred Antar wrote: >> >>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev=20 >>> wrote: >>> >>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>>> -------- =D0=9F=D0=B5=D1=80=D0=B5=D0=BD=D0=B0=D0=BF=D1=80=D0=B0=D0=B2= =D0=BB=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5= =D0=BD=D0=B8=D0=B5 -------- >>>> =D0=A2=D0=B5=D0=BC=D0=B0: nvidia-driver build error (last ports, Fre= eBSD-HEAD) >>>> =D0=94=D0=B0=D1=82=D0=B0: Tue, 21 Aug 2018 16:41:42 +0700 >>>> =D0=9E=D1=82: Alex V. Petrov >>>> =D0=9A=D0=BE=D0=BC=D1=83: FreeBSD Ports >>> Should be fixed as of r477761. >>> >>> ./danfe > > It's not fixed, seems to error elsewhere now: > > context: 12.0-ALPHA1 #0 r337886 / ports r477782 / empty /etc/make.conf > > This is a bare metal installation. > > root@desktop:/usr/ports/x11/nvidia-driver# make distclean && make > clean && make MAKE_JOBS_UNSAFE=3Dyes > > [...] > > cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=3D\"390.77\" > -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 > -fno-strict-aliasing -mno-red-zone -mcmodel=3Dkernel -Wno-sign-compare > -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=3Dundef=20 > -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. > -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common=20 > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD=20 > -MF.depend.nvidia_subr.o -MTnvidia_subr.o -mcmodel=3Dkernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float=20 > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual > -Wundef -Wno-pointer-sign -D__printf__=3D__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-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 -= c > nvidia_subr.c -o nvidia_subr.o > nvidia_subr.c:1131:41: error: too many arguments to function call, > expected 7, have 8 > sc->dma_mask, PAGE_SIZE, 0, attr); > ^~~~ > /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared he= re > vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, > ^ > nvidia_subr.c:1269:45: error: too many arguments to function call, > expected 7, have 8 > sc->dma_mask, PAGE_SIZE, 0, attr); > ^~~~ > /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared he= re > vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, > ^ > 2 errors generated. > *** Error code 1 > > Stop. > make[4]: stopped in > /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvid= ia > *** Error code 1 > > Stop. > make[3]: stopped in > /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src > *** Error code 1 > > Stop. > make[2]: stopped in > /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/x11/nvidia-driver > *** Error code 1 > > Stop. > make: stopped in /usr/ports/x11/nvidia-driver > root@desktop:/usr/ports/x11/nvidia-driver# > All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should have their first parameter, typically kernel_arena, but sometimes kmem_arena, removed in FreeBSD 12. There is still one more pending change to kmem_free() that has not hit HEAD yet. That change will be the last. Alan From owner-freebsd-current@freebsd.org Wed Aug 22 15:46: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 B0196108C420 for ; Wed, 22 Aug 2018 15:46:19 +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 3AD307A76D; Wed, 22 Aug 2018 15:46:19 +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 w7MFk4SH064412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Aug 2018 18:46:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7MFk4SH064412 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7MFk3fR064411; Wed, 22 Aug 2018 18:46:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 Aug 2018 18:46:03 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180822154603.GW2340@kib.kiev.ua> References: <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 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, 22 Aug 2018 15:46:19 -0000 On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: > > > > On 20. Aug 2018, at 17:09, Konstantin Belousov wrote: > > > >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: > >> > >> See here for a screenshot (also including the output of "show pte > >> 0xfffff80001000000"): > >> > >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png > > It is too early for ddb routines to register. > > Ok can you try the following debugging patch, to verify my guess ? > > > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > > index 18777d23f09..cd05fdb763f 100644 > > --- a/sys/amd64/amd64/pmap.c > > +++ b/sys/amd64/amd64/pmap.c > > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) > > pd_p = (pd_entry_t *)DMPDkernphys; > > for (i = 0; i < (NPDEPG * nkdmpde); i++) > > pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | > > - X86_PG_M | X86_PG_A | pg_nx | > > - bootaddr_rwx(i << PDRSHIFT); > > + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; > > for (i = 0; i < nkdmpde; i++) > > pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW | > > X86_PG_V; > > With this change it boots okay (mptramp_pagetables is 0x1000000, as expected). Can you apply the following on top of the previous debugging patch and show me the line printed ? diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 3d70532b7fd..613fa9f2165 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) pmap->pm_pcids[i].pm_gen = 1; } pmap_activate_boot(pmap); +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx etext %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uintptr_t)KERNBASE); } void From owner-freebsd-current@freebsd.org Wed Aug 22 16:21: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 5166D108D6F8 for ; Wed, 22 Aug 2018 16:21:01 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) Received: from sonic305-20.consmr.mail.ir2.yahoo.com (sonic305-20.consmr.mail.ir2.yahoo.com [77.238.177.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 CF9337C52C for ; Wed, 22 Aug 2018 16:21:00 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) X-YMail-OSG: 7bsVqqUVM1nFVXXOEx3W6cVbZIyM7b1b5w.eQKLuhKy6mfZ3vPxVbJ19cyvuGgZ 7I5Ege0Th3B9HQd14OQ7XmNAuMK_9ehPSdXr1BpVNLWBO2PMsjN2trp.mIuDDq0IHXluYWh6i_mv xQN4cWqsIJc29vlYchQO_mmPREDktv1E.sGlz1ggO6x.sm3MdGtZLvnBAzuyorHGv4kEufSVWpBy q56exWU7aljwS96v0BjWkChlNPgEcjM62HAWHg0xy5ivUQs4K12PR.Xr7OmjnngAUh249zdMEyfU jUh68yVDWwdj52xrv9E8EsW.12yR_SM6jiAaoQS8nQxIIlSaiPuKyR52QUXR2C0mIG9k7PamSQx3 PnN6YbBlPRdqVY3olH7ixyA.wrQQ3EoRI86_ZxhBNcpJPLb.zzh6VLNgagVWWIWdImDNWCLaH0A_ OnNZ3kBC3GPwjQjuk5GLEem8ig3INXoC46EVEgjmrx2gy_KZDFxA26JPqoUvgfqynWfbiWSAFdMU zyCiQyqWEOCSB9PiI56A_Uiz5wrjsIF5YYktSNN5mdjqKrIDRLBrhuRE.zXttX5QdflgnidA_f8l fOMGUkQc0OTUGJQg30shlZ92DCG8wYh1RhxGLhMHnm2YmpvazvdXel5OiaVu5B4buOY1_zT.oomd pueQnkYOIV5nhr7RX4DVhXj0H_UjItrZfjcCzAIGLE7wb9y2gOmA2QEi4_DH5Z6x14pt_..7pabv Kz5b7dPXKh3st6UOUViNc.yn3GbVDaA5SeiRCMV9J_Vh36sEScXVSomAa8ecPIirkce38DmSkED6 eG6Hj6UCtqEWyk0h3tN.qghy7re9SL79Ni_1nG3IwVu4mfwmhjETSe7LbWxY3Z2Pi.eMXiXvcqgS AZST0tQeo3O.xbGCxDvgfdbq1S6aDVHmEfwpu_EB9BDmHX0z3RIBYUPS0P1CTfx0YXn_z8fqpb5f zaBZ7qvwNz6wLubsoMZQyjBxO7tOFCfy.GM_IV_KZ7CTDsPH4pRY2WuTy Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Wed, 22 Aug 2018 16:20:54 +0000 Received: from 108.161.151.160 (EHLO [188.125.73.26]) ([108.161.151.160]) by smtp428.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f5c5928fcbb5e86f470610eb59cfa5ca for ; Wed, 22 Aug 2018 16:20:53 +0000 (UTC) To: freebsd-current@freebsd.org From: Per Gunnarsson Subject: dmesg output I don't understand Message-ID: Date: Wed, 22 Aug 2018 18:20:48 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 16:21:01 -0000 Hello! What do these lines in my dmesg mean? I am on amd64. /usr/src Revision: 338177 /usr/ports Revision: 477773 P.S I got Fatal trap 12 with this revision after installing several fusefs modules from ports. After removing fuse from my loader.conf, things booted again. Regards, Per Gunnarsson lock order reversal:  1st 0xfffffe0000e82d80 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3916  2nd 0xfffff80005787000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 stack backtrace: #0 0xffffffff80c02573 at witness_debugger+0x73 #1 0xffffffff80c023f4 at witness_checkorder+0xe34 #2 0xffffffff80b9fe68 at _sx_xlock+0x68 #3 0xffffffff80ec518d at ufsdirhash_add+0x3d #4 0xffffffff80ec805f at ufs_direnter+0x49f #5 0xffffffff80ed04f9 at ufs_mkdir+0x8b9 #6 0xffffffff81201479 at VOP_MKDIR_APV+0xd9 #7 0xffffffff80c7d5aa at kern_mkdirat+0x1ca #8 0xffffffff8107ea21 at amd64_syscall+0x281 #9 0xffffffff81058d3d at fast_syscall_common+0x101 Security policy loaded: MAC/ntpd (mac_ntpd) acquiring duplicate lock of same type: "os.lock_mtx"  1st os.lock_mtx @ nvidia_os.c:886  2nd os.lock_mtx @ nvidia_os.c:886 stack backtrace: #0 0xffffffff80c02573 at witness_debugger+0x73 #1 0xffffffff80c023f4 at witness_checkorder+0xe34 #2 0xffffffff80b74cac at __mtx_lock_flags+0x9c #3 0xffffffff82f9ad8b at os_acquire_spinlock+0x1b #4 0xffffffff82e91adc at _nv032251rm+0xc lock order reversal:  1st 0xfffff8003033e068 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2590  2nd 0xfffffe0001a84200 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282  3rd 0xfffff80030340d88 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2590 stack backtrace: #0 0xffffffff80c02573 at witness_debugger+0x73 #1 0xffffffff80c023f4 at witness_checkorder+0xe34 #2 0xffffffff80b6a2db at lockmgr_xlock_hard+0x6b #3 0xffffffff80b6ace5 at __lockmgr_args+0x545 #4 0xffffffff80ebfe25 at ffs_lock+0xa5 #5 0xffffffff81201ef9 at VOP_LOCK1_APV+0xd9 #6 0xffffffff80c803e6 at _vn_lock+0x66 #7 0xffffffff80c6eccf at vget+0x7f #8 0xffffffff80c60eb1 at vfs_hash_get+0xd1 #9 0xffffffff80ebb69f at ffs_vgetf+0x3f #10 0xffffffff80eb10ed at softdep_sync_buf+0x5dd #11 0xffffffff80ec0c04 at ffs_syncvnode+0x294 #12 0xffffffff80eb0308 at softdep_fsync+0x4c8 #13 0xffffffff80ebfcfc at ffs_fsync+0x7c #14 0xffffffff81200e69 at VOP_FSYNC_APV+0xd9 #15 0xffffffff80c7cdd4 at kern_fsync+0x194 #16 0xffffffff8107ea21 at amd64_syscall+0x281 #17 0xffffffff81058d3d at fast_syscall_common+0x101 fuse-freebsd: version 0.4.4, FUSE ABI 7.8 From owner-freebsd-current@freebsd.org Wed Aug 22 16:37: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 92BA8108E2D4 for ; Wed, 22 Aug 2018 16:37:11 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D6537D5EC; Wed, 22 Aug 2018 16:37:11 +0000 (UTC) (envelope-from manfredantar@gmail.com) Received: by mail-qt0-x241.google.com with SMTP id x7-v6so2834900qtk.5; Wed, 22 Aug 2018 09:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ikxAzzygXDhnNkEMHpV8g6NZwg8ULErjWmiu0Vc3Hs8=; b=ZEiXkIvWdfTLlcaU1QxDsNXFdIC2SgqXGzF181LKvDurhrofxROBOqr9F3OlfE/iAV lYrLUgIWBEs4zi/Rq9S2ZxpMkB6fpuLaxS+fqzOutxLWoz47aUx+qjHKYBZU7yutxyru EBDYRsMCwClSKk+QZTuw0CwZnQTm85blTXTWDADBYMgg2uN60YWgQS92RzzSzvO5kBBY cSGmCvN9kPDkS45S6w/3eYcWfFAJFiFUH2X9BPNxtOmWs2ndM+BPMlZo0Rl0CUmat+pL bOGwjXXhea039txLaw+sLEBOqeyDIWOQ8WBwZj/ES59V2DPMhflXcBeEqm0EiCgfCst5 vBJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ikxAzzygXDhnNkEMHpV8g6NZwg8ULErjWmiu0Vc3Hs8=; b=jYT+hxX/cfnjDQyoDqlXIo4/wvRyMeuoEkEGyvLyfsvuwOQsAvCf6uURmOJj2ytdos ikkpNJZH/YRBGF1yV8FXeEAt2ZwvT4kYrUi9V0fafOiYxXRO0SG/613mScuziQKwDree GcdwaZoSbY8rpsZbdmwCVErcmdCk4iWtwNDd+MjeBwjsEXNOBgj/TRYrxgOvPcoLSJ2A vGq2KbVruFgoUAbL9tND419UN/m6TRuqlJH0NbmQQsUyqn9PW1WTnYMfkKRcpALF4VjH frZPjTypR4oI4ggHdxBWGiplqMmVFjj4eNAOd6rnhMRoPCaLxsGo4OnZsO3b0AYsfFgH P5Kg== X-Gm-Message-State: AOUpUlFr+fPdwExmyXXZtDFP/zRkSY2GrrmGlQ+O4DiyttIhe+Mbm20K d/NC4ynNH2eyl6ta/I1Z5kE= X-Google-Smtp-Source: AA+uWPxaCi0FRAUJ96JLVuOa35rY3dgnwlA/LslZFqF+MvjVue/te7YewR2aR0xPvYOtUat6clMVBQ== X-Received: by 2002:a0c:e9ce:: with SMTP id q14-v6mr52619654qvo.106.1534955830714; Wed, 22 Aug 2018 09:37:10 -0700 (PDT) Received: from octo.pozo.com (50-197-129-138-static.hfc.comcastbusiness.net. [50.197.129.138]) by smtp.gmail.com with ESMTPSA id n25-v6sm1054779qtp.94.2018.08.22.09.37.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 09:37:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) From: Manfred Antar In-Reply-To: <86b09a54-9394-675e-3722-7007fa66c9c1@rice.edu> Date: Wed, 22 Aug 2018 09:37:08 -0700 Cc: Alexey Dokuchaev , "Alex V. Petrov" , freebsd-current , alc@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <83B426AF-3B5E-4D19-9248-0CD33BB1038D@gmail.com> References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> <86b09a54-9394-675e-3722-7007fa66c9c1@rice.edu> To: Alan Cox X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 16:37:11 -0000 > On Aug 21, 2018, at 10:10 PM, Alan Cox wrote: >=20 > On 08/21/2018 23:29, Manfred Antar wrote: >>=20 >>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev = wrote: >>>=20 >>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>>> -------- =D0=9F=D0=B5=D1=80=D0=B5=D0=BD=D0=B0=D0=BF=D1=80=D0=B0=D0=B2= =D0=BB=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0= =BD=D0=B8=D0=B5 -------- >>>> =D0=A2=D0=B5=D0=BC=D0=B0: nvidia-driver build error (last ports, = FreeBSD-HEAD) >>>> =D0=94=D0=B0=D1=82=D0=B0: Tue, 21 Aug 2018 16:41:42 +0700 >>>> =D0=9E=D1=82: Alex V. Petrov >>>> =D0=9A=D0=BE=D0=BC=D1=83: FreeBSD Ports >>> Should be fixed as of r477761. >>>=20 >>> ./danfe >> emulators/open-vm-tools is also broken from the recent changes to = sys/vm: >> cc -O2 -pipe -isystem /usr/local/include -fno-strict-aliasing = -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -I/usr/ports/emulators/open-vm-tools/work/open-vm-tools-stable-10.2.5/open= -vm-tools/lib/include = -I/usr/ports/emulators/open-vm-tools/work/open-vm-tools-stable-10.2.5/open= -vm-tools/modules/shared/vmxnet -I. -I/usr/src/sys = -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer -MD -MF.depend.if_vxn.o -MTif_vxn.o = -mcmodel=3Dkernel -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 -Wcast-qual -Wundef = -Wno-pointer-sign -D__printf__=3D__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-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1999 -c = if_vxn.c -o if_vxn.o >> --- vmmemctl --- >> os.c:410:68: error: too many arguments to function call, expected 2, = have 3 >> p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, = M_WAITOK | M_ZERO); >> ~~~~~~~~~~~ = ^~~~~~~~~~~~~~~~~ >> /usr/src/sys/sys/malloc.h:55:18: note: expanded from macro 'M_WAITOK' >> #define M_WAITOK 0x0002 /* ok to block */ >> ^ >> /usr/src/sys/vm/vm_extern.h:67:1: note: 'kmem_malloc' declared here >> vm_offset_t kmem_malloc(vm_size_t size, int flags); >> ^ >> 1 error generated. >>=20 >> I also had to rebuild kde-workspace-kde4 and xorg-server before i = could start x without open-vm-tools. >> This is on a FreeBSD-12-Alpha2-current as of today.the old = open-vm-tools/modules/freebsd/vmmemctl >> will hang,so i needed to uninstall it to get x. >>=20 >> if these lines are removed from = open-vm-tools/modules/freebsd/vmmemctl/os.h open-vm-tools will compile = and work: >>=20 >> 407,411d406 >> < #if __FreeBSD_version < 1000000 >> < p->bitmap =3D (unsigned long *)kmem_alloc(kernel_map, p->size); >> < #else >> < p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, = p->size, M_WAITOK | M_ZERO); >> < #endif >>=20 >> Not sure if this is the right fix but it enabled me to use the = vm-tools again and the associated modules >=20 > Change this to >=20 > #if __FreeBSD_version < 1000000 > p->bitmap =3D (unsigned long *)kmem_alloc(kernel_map, p->size); > #elif __FreeBSD_version < 1200080 > p->bitmap =3D (unsigned long *)kmem_malloc(kernel_arena, p->size, > M_WAITOK | M_ZERO); > #else > p->bitmap =3D (unsigned long *)kmem_malloc(p->size, M_WAITOK | = M_ZERO); > #endif >=20 > That said, it's not clear to me why this allocation doesn't use > malloc(9), then no #if's would be required across different versions = of > FreeBSD. >=20 This works on current AMD64 Thanks From owner-freebsd-current@freebsd.org Wed Aug 22 16:50: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 E9492108EC4B for ; Wed, 22 Aug 2018 16:50:05 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7CD7E2B6 for ; Wed, 22 Aug 2018 16:50:05 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id f5743f3e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Wed, 22 Aug 2018 09:50:04 -0700 (PDT) Subject: Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M To: Graham Perrin , freebsd-current References: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> From: Pete Wright Message-ID: <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> Date: Wed, 22 Aug 2018 09:50:01 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> 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.27 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, 22 Aug 2018 16:50:06 -0000 On 8/22/18 2:11 AM, Graham Perrin wrote: > HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M. > > If neither drm-stable-kmod nor drm-next-kmod is used – commenting out > # kld_list="/boot/modules/radeonkms.ko" > in /etc/rc.conf > and if boot is pure UEFI, without CSM, > then the notebook can reliably resume from suspend. There's a > distinctive single amber pulse of the (normally blue) radio button > before suspend occurs. However: > > - without CSM, most of the startup routine is illegible, 'torn' > > – for example, I can't see what's typed when I boot to single user mode. > > ---- > > If either drm-stable-kmod or drm-next-kmod is used > and if boot is pure UEFI, > then the notebook can not suspend. No amber pulse of the radio button. > > With and without drm-next-kmod: > if boot is hybrid UEFI with CSM, > then suspend occurs, but resume fails. No beep, the computer restarts. > > debug.acpi.resume_beep=1 > in /boot/loader.conf for an audible beep. > > ---- > > Please: might graphics/drm-devel-kmod be better for either the tearing (without CSM) or for suspend? not sure this will address this specific issue - but have you tested setting this sysctl knob and seeing if that fixes your resume issues: hw.acpi.reset_video=1 -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Wed Aug 22 16:58:46 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 18F91108F095 for ; Wed, 22 Aug 2018 16:58:46 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8438D7E885 for ; Wed, 22 Aug 2018 16:58:45 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id j26-v6so2207725wre.2 for ; Wed, 22 Aug 2018 09:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JXxkgGiD6fG5F+3+iRpevIsh/a5Xdlt2V/eTHTQH07o=; b=pmT8DcauVoSTw7teZoWbsj0MkpVHKuPofx4Did/l6YaPuvgSP3uIsUPXo2z07iZk69 j1wVFl0OgrSq9rIqXOu+y2MtSvvoZ8WgKs/XJB7lXSyv3mb0NNiUUUCUh4WaBZTRXyQX /B1/bnopyb+Mx2lBIvI5ZISvPi3+9TqU46JwvY1IniHbgM3jUpY1g9qni1fI3UKl+qQG Vt+cj4aqWtwBtR6Ry+YIw2HgSZFo4l6fN5hPe8Mx8e7iaqhT/G48VC0M+zTvgtNbLWGH kajdD6s5IVr5VDM5Kn8pDkpk9m429MvqITDFeiv/xw0LGNTN//gW3P16AkGNYh/f6B5O 6ZDg== 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-transfer-encoding :content-language; bh=JXxkgGiD6fG5F+3+iRpevIsh/a5Xdlt2V/eTHTQH07o=; b=dCdZDNCj6i+01w8c50H/JPRYlq936lYycqnvolTBMJYX53nIXmOkBJRFo1sUr+/+ZF CRefyHZnDSHXCOGjU8Flb4MXyBU2qU3ZrT1eHX2fNuTqbSz/FGy8igW8ymfWdkzTfe72 Uu9EuO4TzxGT8bCvpiIHpPxqusrRQ8xGjFp8AxwTD8DN+eAl0eh0R4fn5kmLpazdkl6x QIXreirLsGS3hOeEQ+BGHYt3KP/awMS1g+tlIbj96uYLn2BanBTbLHJgRG1UCmLRHMzp t+oADDVupw7m8zTEsTw7Enoo8PyD6PnjX8mfYVLL5llL+R8FsU52Ne0rHkmIzZbBoTub QJpw== X-Gm-Message-State: AOUpUlFYobjPgcODXUZ/2pCASoLpS0z3tB320EFJTocCqRMkuvj49o1S 1x0E8JQsZGvgz5APvZpCIaiVJUzKh89zjw== X-Google-Smtp-Source: AA+uWPyzjfaloy0ySLIgGikPWDshMh6M83N1VtNIZ3v7v0QeTSdWAow37udffLx1aBHuzLFek0puQw== X-Received: by 2002:a5d:46d1:: with SMTP id g17-v6mr17184763wrs.76.1534957124109; Wed, 22 Aug 2018 09:58:44 -0700 (PDT) Received: from [192.168.1.231] (host-78-150-66-180.as13285.net. [78.150.66.180]) by smtp.gmail.com with ESMTPSA id w4-v6sm3284022wro.24.2018.08.22.09.58.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 09:58:43 -0700 (PDT) Subject: Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M To: freebsd-current References: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> From: Graham Perrin Message-ID: <549ab380-60a8-c919-980a-b5b6a541e3c9@gmail.com> Date: Wed, 22 Aug 2018 17:58:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 16:58:46 -0000 On 22/08/2018 17:50, Pete Wright wrote: > not sure this will address this specific issue - but have you tested setting this sysctl knob and seeing if that fixes your resume issues: > hw.acpi.reset_video=1 Thanks, I'll be away for around three weeks, I'll test some time in September. From owner-freebsd-current@freebsd.org Wed Aug 22 18:28: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 8AD541091826 for ; Wed, 22 Aug 2018 18:28:07 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0B5C8340D for ; Wed, 22 Aug 2018 18:28:06 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id o18-v6so3194034wmc.0 for ; Wed, 22 Aug 2018 11:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0GMMq9IxxEK0SAOPawvfs+fRRaxHK/+ZfQ6qcAQ71uM=; b=hRUoR2mLLlK9irRQ+Vvum1HasCb8ZwfxKJAQNU3ksSVnUqeJ1ViztCWFVZyXViCQs5 rwmpY79jleHQtXE4gI6mzYHDE/maegbelR95g0+/6DP32uM+V0Kr8JP98ii+dZIMdEFB 6HukZp74ZUCB2FO6/rGG736Ul+dIvr2GmtxXz5dHUxxOPLq/KH35073GqgFe3v4XFkCA mbLfXRLJd0rCQqhmnKyJtfd/czwzgNJnfy09QU6d8ZVhHmS+T33VwWBDJSyG5bvtgL9q qO2NL+Qr/1SVk+1xSEd+l4XmgmuGIw9xXH1JrrL2zu5G3cKLUOrMcGf6w5suT3Q+TiXT jO3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0GMMq9IxxEK0SAOPawvfs+fRRaxHK/+ZfQ6qcAQ71uM=; b=N5RFa0SBGKZUrLcRsRaXycXeqtvmwuLDa/Qg7jRHdKHx7gR5Gbu6DI1WtxPt8TnOPy 15T8BNQBpiPW/NU6gLM4RHakKh+mx6FXko+w2Nktc+PJJc8n/zxkpWNcHa/xc+4AhWTP 8/1ALySBVm+IrXDt/pFshZSvpGgpiOYJyMOdONiuawCrcMcOVIywfe0v5WoOMPh4ZMF0 bi+EO3FoAGSCGrXquFORj/mYtx6x6TgbIk2XtLlrlOJJd6pfMBSM+BJ3fEHh/g/zKXBX B3XqkXVkxBXC2D88OeRjDg9dAC7D2aEtNOQXAuECQEKEvLB3YMsHTpwZJ7CFbLz9WkG+ jrvw== X-Gm-Message-State: APzg51BSvL+Hizwp3bQLFD9CBXeJTgAKAudtbVHok6/XTplOtutNfi0w 6WusP5/ae7VlPQokcgCTOP0uLyOaqWCt+W1hb28= X-Google-Smtp-Source: ANB0VdYGLdM/38LKXoCKgX+3Tl8oTJaeHj7QfwFwWjHTg0Dus2Vg6EiBpzg4JIwgGSt1O9pFvePdNR9pzDOXKDNxKSo= X-Received: by 2002:a1c:be14:: with SMTP id o20-v6mr3141936wmf.73.1534962485160; Wed, 22 Aug 2018 11:28:05 -0700 (PDT) MIME-Version: 1.0 References: <93fcf295-1dae-12d4-5530-ef0c55bd8cc2@gmail.com> <0aa72278-c17b-0bd7-1f5b-960366890426@nomadlogic.org> <549ab380-60a8-c919-980a-b5b6a541e3c9@gmail.com> In-Reply-To: <549ab380-60a8-c919-980a-b5b6a541e3c9@gmail.com> From: Johannes Lundberg Date: Wed, 22 Aug 2018 19:27:28 +0100 Message-ID: Subject: Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M To: grahamperrin@gmail.com Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 18:28:07 -0000 On Wed, Aug 22, 2018 at 6:00 PM Graham Perrin wrote: > On 22/08/2018 17:50, Pete Wright wrote: > > not sure this will address this specific issue - but have you tested > setting this sysctl knob and seeing if that fixes your resume issues: > > hw.acpi.reset_video=1 > > Thanks, I'll be away for around three weeks, I'll test some time in > September. > Hi Make sure you also update the drm packages from ports when you're back. There was an issue causing kernel panic for amdgpu and radeon on suspend/resume that has been fixed. It should be available in an updated pkg later this week. Try drm-stable or drm-devel. drm-devel will require a rather recent 12/13-CURRENT. > > _______________________________________________ > 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 Aug 22 18:31:42 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 1375A1091983 for ; Wed, 22 Aug 2018 18:31:42 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FA56836E2; Wed, 22 Aug 2018 18:31:41 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4E1382CF; Wed, 22 Aug 2018 14:31:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Aug 2018 14:31:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=E0bCgzdAKyw+ZHWzC3+/6QCuj+p7y LmXDPTVF74fSFI=; b=do1nqq7SVZcxec6L59ugJsc0g3j823btC3Dmyed4Z47an K1vLxQ46riIMMYq88aaI9eoVMUwemg2xLI/cCDCB9FIfsa1wseL/Zxlyn0UGKYym g9hDYxVTxw/4hOB1OgxtpGUBFO8nYnk9jDjvE/CIxyGje2v1qTBxerYxJ9Ti9nd1 sZIgwSZ3lSKgwD7SSodIpsSs2NUJSf8y3MoYtvuhxq7mJcMKmMTC7ZQESpDgsPOT axJwhgeKnudWBhCz8JhaSfchPgzma+nnirs21AJ47gP0dFfvWNTINiyDdQf7ujZJ pNeDcX+TZOLwyUksbvMFiW6Pdvb3jqlOoFv6oIPQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=E0bCgz dAKyw+ZHWzC3+/6QCuj+p7yLmXDPTVF74fSFI=; b=Qd36WfEnKjhxKDUQnc7814 8oC1l5sx3o4rVgKpO2wb7UISjY4PJu6aJ/DYNhCcEix+IEBJ1H3pCxqpKsDFykhd EpPiHrISs5dCO8KYhMMEknPnPafVYR3ptLaziS/8kYBJM/3jhyfwh1qjwSJy9Y6A mode4zumJiQgFC6VOn2HRLX4uIs6AnduK5A81eX6EKG3gStX1NsJvOE+fbWmewxj F0vdrMR4U2gmuT8AZ9vPgNgL6jxNXCUs1ywtcr0RE0WFBwu/j2BAg2rIw4JNOgxu XAneG+es3SR/8wdLdL4BxFhQk1bhiODq7UedCWcX1OVeI8GW5Oeadh6qL5E4m74A == X-ME-Proxy: X-ME-Sender: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id A6A4DE4015; Wed, 22 Aug 2018 14:31:37 -0400 (EDT) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) To: Alan Cox , Manfred Antar , Alexey Dokuchaev Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> <60982d01-7d08-25b7-97c5-009a6be13b88@zyxst.net> <44324f5e-5146-7525-7a60-1b774fc5d85a@rice.edu> From: tech-lists Organization: none Message-ID: <444ae9d7-898c-2ad9-bb4d-83088127702f@zyxst.net> Date: Wed, 22 Aug 2018 19:31:37 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <44324f5e-5146-7525-7a60-1b774fc5d85a@rice.edu> 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.27 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, 22 Aug 2018 18:31:42 -0000 On 22/08/2018 16:29, Alan Cox wrote: > All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should > have their first parameter, typically kernel_arena, but sometimes > kmem_arena, removed in FreeBSD 12. > > There is still one more pending change to kmem_free() that has not hit > HEAD yet. That change will be the last. Thank you, that's very good news. Do you have an idea when the change will arrive in -HEAD? -- J. From owner-freebsd-current@freebsd.org Wed Aug 22 18: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 AF49E1091CA1 for ; Wed, 22 Aug 2018 18:39:45 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CC7D983B97 for ; Wed, 22 Aug 2018 18:39:43 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=1o2SVlLycJR54D3AnSHDpfsgG4CmH3qGCYEwfrkzjQ0=; b=EaeE7H0GXN4W2tkP1hmtfK27QArgXTlQkLl1jXQswZsK5GJNMUJJK8iO248L+6gFqT6iXYmbLziELn6OHkIL3A9ChY5mV3iTdF2XUluU6Xv0Zdi6NiFuG9/ErxJYnFQrN3KOrG4PPraDrfLJCpwiEnzVtS35npnfGM7qYWxtOIA= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 64dc7612 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 22 Aug 2018 18:32:52 +0000 (UTC) Date: Wed, 22 Aug 2018 21:32:47 +0300 From: Greg V Subject: Re: dmesg output I don't understand To: Per Gunnarsson Cc: freebsd-current@freebsd.org Message-Id: <1534962767.74383.2@hraggstad.unrelenting.technology> In-Reply-To: References: X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 18:39:45 -0000 On Wed, Aug 22, 2018 at 7:20 PM, Per Gunnarsson wrote: > Hello! > > What do these lines in my dmesg mean? > > I am on amd64. > > /usr/src Revision: 338177 > > /usr/ports Revision: 477773 > > P.S > > I got Fatal trap 12 with this revision after installing several fusefs > modules from ports. > > After removing fuse from my loader.conf, things booted again. > > Regards, > > Per Gunnarsson > > lock order reversal: > 1st 0xfffffe0000e82d80 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3916 > 2nd 0xfffff80005787000 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 Hi, this is debugging output you're seeing because your kernel is built with the WITNESS option. (e.g. the default GENERIC kernel in -CURRENT) lock order reversal is a very common message, you can ignore it. Switch to GENERIC-NODEBUG to get rid of the messages and get a performance boost (these safety checks impact syscall performance) From owner-freebsd-current@freebsd.org Wed Aug 22 18:30: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 7D65D10918D3 for ; Wed, 22 Aug 2018 18:30:11 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F063B83556 for ; Wed, 22 Aug 2018 18:30:10 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: by mail-pf1-x434.google.com with SMTP id b11-v6so1378080pfo.3 for ; Wed, 22 Aug 2018 11:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bQQP2lkwg92kML+IoMdcz/5c9zPBB0qC3JdQIS4MlQ=; b=ck553h83UCxcqDHzUVf/6nQhTcUCGMAmEQzf6rZCrCUl5nCMHn/QqXH5UkwieRV/hF nGVNmimFeT7cBTLObq2YC18a221j6SpXknm017MApI+ll9SPYFoOHv1UIIWNYdq7UGUA mnop5VkIaopR3EYa8a0pxQlWyFwH9GiRCrqCn5Epv/cspBSz5rxm4e+LZbMxgROVxEHV Ac97FwEj62JweQuDHI2g7dHhbbcIJDyPKY1bEz93itq1OaYN+RDhD7xWet1euRJN60jS 5F/Gmrgdyb4GcT8D3QN94HXCnScSt4ica1/FPIMEgvC9e0WV7XDYsav/gdPcZeXctX6/ X5rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5bQQP2lkwg92kML+IoMdcz/5c9zPBB0qC3JdQIS4MlQ=; b=GKk3S0ranIH4GAqGoK+wV7YeFn+Es5wtFtliFnlNVSip4hqVSFlsT7aUhftIVMoAm+ jiN1YqA142UowijiKh2c+nXUQOugMFU4oCCops8lgNPH45LMnf1qiWwUtJNDuJQBY5zT 3oc3E0lyNKTWXNCfmZSUHlBEJKM1OUTNcGoasWehXrdzqYFtLqZ6FFXlHr+OhbtnPws8 CIJxfjovZzyJfgqBFa+8MwaT2e/m54wtKXcUJeLHa5vohC/7dZyOWAttZzUMxoQbAGoR de+PvNMYID48cfGLmm1mOMJdh+ofYHYQ5r1qQnjxkueHTXHqflEy7VzI7KdKaIYis0D4 pgkA== X-Gm-Message-State: APzg51Bkseh9BXtk0cV3BLITepHNIOTafM+xMrNbOWrSVVbs7G92epON uLe1CSI8i5H691uXwotDwU+BdQ== X-Google-Smtp-Source: ANB0VdaeQMKvfYHml2udXcqguR3LDNGU+XFfxHD7J2XqC3B3/jydTZvo94Mvr4IpE1SZkBF2wIG1Og== X-Received: by 2002:a62:384a:: with SMTP id f71-v6mr7929340pfa.48.1534962610065; Wed, 22 Aug 2018 11:30:10 -0700 (PDT) Received: from [10.250.1.167] ([12.229.62.29]) by smtp.gmail.com with ESMTPSA id k1-v6sm2950804pfi.62.2018.08.22.11.30.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 11:30:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Native Encryption for ZFS on FreeBSD CFT From: Sean Fagan In-Reply-To: Date: Wed, 22 Aug 2018 11:30:07 -0700 Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> References: To: Alan Somers X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 22 Aug 2018 19:27:04 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 18:30:11 -0000 On Aug 21, 2018, at 8:16 PM, Alan Somers wrote: >=20 > > The last time I looked (which was a long time ago), Oracle's ZFS = encryption looked extremely vulnerable to watermarking attacks. Did = anybody ever fix that? This is the comment about dedup in zio_crypt.c: * CONSIDERATIONS FOR DEDUP: * In order for dedup to work, blocks that we want to dedup with one = another * need to use the same IV and encryption key, so that they will have = the same * ciphertext. Normally, one should never reuse an IV with the same = encryption * key or else AES-GCM and AES-CCM can both actually leak the plaintext = of both * blocks. In this case, however, since we are using the same plaintext = as * well all that we end up with is a duplicate of the original = ciphertext we * already had. As a result, an attacker with read access to the raw = disk will * be able to tell which blocks are the same but this information is = given away * by dedup anyway. In order to get the same IVs and encryption keys for * equivalent blocks of data we use an HMAC of the plaintext. We use an = HMAC * here so that a reproducible checksum of the plaintext is never = available to * the attacker. The HMAC key is kept alongside the master key, = encrypted on * disk. The first 64 bits of the HMAC are used in place of the random = salt, and * the next 96 bits are used as the IV. As a result of this mechanism, = dedup * will only work within a clone family since encrypted dedup requires = use of * the same master and HMAC keys. (So, same issue. I don=E2=80=99t think encryption and deduplication = should live together, so I would not have made that choice.) Sean. From owner-freebsd-current@freebsd.org Wed Aug 22 19:37:27 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 7425E1093337 for ; Wed, 22 Aug 2018 19:37:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 EF04586846 for ; Wed, 22 Aug 2018 19:37:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: t8iHhRAVM1mRQxs.zqI6pvZkKL6wm24PdMb9lxHR5DFtFHhliIJWvQmhdbVJBaO SLFDllTw0bpkYweQixw14YTwwW_1I.p_hhT3eZrOEQIlagk2.TbUEmyTM3GiZU6dTSCUYLjd4oJG EAiTzUu42Gtlk0apXVXr50sVVpwVEh1_UXDhNsaqRdfxkOq7HWEQKlhxBe3Q9FMmS4P7dQBh_t_p sV6pAEbxE6EtTG1nODvETtChqC3YoQcV90hvvetu0P92PguAhhlR6KKfxKto_C4P4ripDx_RLwao 7e0wZCvE8N2RqHwEGseMFCIA.ib8YjWdqHGuQKeeGepURYOUAPYOBWVfiPu_tf_7s.jQo63SIIjj 1UbnW5OkfUZTpgmeMDTPczI7iaoPcYvFDZdwK_0UsUj5QdKesLoEGbkoJOIOXzo0RWPwrGNSkpea 5cnU4X4F3xg37dVi6o8WMWN1WwhampBgKQbDjZyMxnyuhOMex_PIrW5txei1U_pRw0oAKg8zodS8 xlHftQEQtnCn3W0.q_VVyyZsEwzoWcqWaEUmeHsoi3b4CgNdSeNOEYWBfo2_707orO3SfgpN8vy7 az5aVrDA9FCZ1_GZdaxRW3x2PcZv2TyuWz6akUEMM._YBF7JhkolVGxpZIGYXZbYQznJm0MkRu7n 3.1tZypl8SXiMd3UI2pMT1woNWm0szD2YKfRDGK_ErALa4_i0C7qMCrKewA9Y0gfTwG89h0rQRPc nTllJslJ40dZ7ndtOumdu9_ZYH5bl7cuz_3RCw.0FrmEKnucvNLFCePjHb0zOEZDpgMClnRB3Q4r BoE1XVtnZRlwxEunWt4DYqt0BXWR_ba5FZmOAIAuKIyMISkgsRVoEY2ThyhxBWLU7xn76a.jhBEe _6Vx1VA7Yb3JQoC.S0kk_jpAnabYcBbOwhetSyWIhlZ6bV8QXnDEPqhmOh_CX8RPho0YVA6FP99A 6UiBq9CBmw9Bsd_tpsAhBvo8166Tkri4t4x81Ck6N547M8foccHEkvLWapPXh.SRN5vpn0FjWjAU FrNiuXvww Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Aug 2018 19:37:19 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp416.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0027db253217336906e8095658e50af8; Wed, 22 Aug 2018 19:37:19 +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.5 \(3445.9.1\)) Subject: Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs Message-Id: <023C54F9-8660-40C5-8348-DD05D5C97B25@yahoo.com> Date: Wed, 22 Aug 2018 12:37:18 -0700 To: brd@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:37:27 -0000 I'm just using this move as an example for some more general questions. After this change when I look at: = https://www.freebsd.org/cgi/man.cgi?query=3Ddevfs.conf&apropos=3D0&sektion= =3D5&manpath=3DFreeBSD+12-current&arch=3Ddefault&format=3Dhtml I see in the man page: FILES /etc/devfs.conf /usr/share/examples/etc/devfs.conf So . . . Roughly when are the "FreeBSD+12-current" man pages going to track the moves? Once everything has been moved? Are the examples also going to be moved/reorganized? Similar timing question to the above (if yes). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-current@freebsd.org Wed Aug 22 19:41:57 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 BE89F10937EE; Wed, 22 Aug 2018 19:41:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D4FA87177; Wed, 22 Aug 2018 19:41:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f53.google.com with SMTP id l26-v6so2262886lfc.8; Wed, 22 Aug 2018 12:41:56 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RD5GRRHc6X1znKWsJ+9utq8OFRZ9jwTiwJ24c16bRXE=; b=lCP/UYHHscX5PD+JfiP4J8DSqMnWki/u0CoG1Z99PWf7kTKYp87H5UCMUhHxxaUnO9 7ysc/0MpyQnOP/h04JPAEpGiq6ZywoUxUJkwIS8nMhV+F2y1lmG4Yyu/Jv1v2Xv4vTWm TaSQDlqxJsBTdDr7aJa8ZzPfX4II42OViNnsSS8jrRA4SmQeWIyPomgKPf4tQilOPnn2 KEBIontL/1rR+1tx72jXO2ozFLPIa37ipdOKf7zg+Vad1/9qxwjU1JvjSZ8KaaGjmkA7 C0t01CIQYbEa1tW7yQPoNRtW+tZzwrWiMb6yFYC9eOOsJpPFufPfj1oFQM21z1FCx4En H4AQ== X-Gm-Message-State: APzg51Bs1lvCmYnH+eZpEhGqVUgAxwEOq0hQUtwigY90EiSytmhH/hxN fPbsf0DnGRD/8yp+ERNYUvTsIdCKhvCPwX9ck5U= X-Google-Smtp-Source: ANB0VdazmXcqfQa30ukVrSF12oG5LmKPKkbyoSfSsZh7OXe46SQTW47gB6ZwLwFLTzhGMoaavcB2fyLJzZD2zPad8xA= X-Received: by 2002:a19:6619:: with SMTP id a25-v6mr3156876lfc.62.1534966561322; Wed, 22 Aug 2018 12:36:01 -0700 (PDT) MIME-Version: 1.0 References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> In-Reply-To: From: Alan Somers Date: Wed, 22 Aug 2018 13:35:48 -0600 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Sean Fagan Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:41:58 -0000 Only encrypting L0 blocks also leaks a lot of information. That means that, if encryption is set to anything but "off", watermarking attacks will still be possible based on the size and sparsity of a file. Because I believe that with any encryption mode, ZFS turns continuous runs of zeros into holes. And I don't see anything in zio_crypt.c that addresses that. -Alan On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan wrote: > On Aug 22, 2018, at 12:20 PM, Alan Somers wrote: > > ]That doesn't answer the question about what happens when dedup is > turned off. In that case, is the HMAC still used as the IV? If so, then > watermarking attacks are still possible. If ZFS switches to a random IV > when dedup is off, then it would probably be ok. > > From the same file: > > * Initialization Vector (IV): > > * An initialization vector for the encryption algorithms. This is used > to > * "tweak" the encryption algorithms so that two blocks of the same data > are > * encrypted into different ciphertext outputs, thus obfuscating block > patterns. > * The supported encryption modes (AES-GCM and AES-CCM) require that an IV > is > * never reused with the same encryption key. This value is stored > unencrypted > * and must simply be provided to the decryption function. We use a 96 bit > IV > * (as recommended by NIST) for all block encryption. For non-dedup blocks > we > * derive the IV randomly. The first 64 bits of the IV are stored in the > second > * word of DVA[2] and the remaining 32 bits are stored in the upper 32 > bits of > * blk_fill. This is safe because encrypted blocks can't use the upper 32 > bits > * of blk_fill. We only encrypt level 0 blocks, which normally have a fill > count > * of 1. The only exception is for DMU_OT_DNODE objects, where the fill > count of > * level 0 blocks is the number of allocated dnodes in that block. The > on-disk > * format supports at most 2^15 slots per L0 dnode block, because the > maximum > * block size is 16MB (2^24). In either case, for level 0 blocks this > number > * will still be smaller than UINT32_MAX so it is safe to store the IV in > the > * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fill > count > * for the dnode code. > > > Sean > > > From owner-freebsd-current@freebsd.org Wed Aug 22 19:46:31 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 B17471093B34; Wed, 22 Aug 2018 19:46:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A7AD88045; Wed, 22 Aug 2018 19:46:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f51.google.com with SMTP id j8-v6so2282605lfb.4; Wed, 22 Aug 2018 12:46:31 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=++NMJdGm2+cP9X5SmSlpRrJLyHTEQsGPgyG7tJMe5h8=; b=U9nBVhuiCQoX3z/ZbrhlrlFeQOIyVUnzi+cPwU4AuNivhaJddTLbh67BDLApFoxOj0 17t4/W4ei3AwzcSt+RXrisy4n+lKrwdjvwy7vqYaHyhZKYt7KPcxsF9d+V7X1BF/MBmh ZpUOj5qhGLXqZMIIROiAB4HwXgKd7OtkSBf+vy8nKty7T9u0ClOYXLc0k8fDlsbl9pAD s7rCTx/gL3SChd4WSjn3oDfsjrXN3QUaWUpLsg3/FTgnIemLiqwswNIQiFPQtw/lRjz0 ITQOLQZeXn/xIPuEovEEG9z9ax+LZcoolnf/AEe0+bfouxw8gbKiXvmdJ30a0MC3EaOi /VAg== X-Gm-Message-State: AOUpUlHMUQP8qz1hER5izdAw6eWS5IFe8Wre63sTY0tymqjEPlXc/DyR TGNkbY5CE1W+/LF9NOdpVDg3hqPr8yotNJNh05bf0A== X-Google-Smtp-Source: AA+uWPywVq7Knf1+i50rBYlrksxiyvFp4J8AjC1HFsXGRpNDhmn9WWKOOCAuLSikNgG1LrIPaO4x8J1uafv2jehzb6E= X-Received: by 2002:a19:1c4c:: with SMTP id c73-v6mr10783055lfc.90.1534965641770; Wed, 22 Aug 2018 12:20:41 -0700 (PDT) MIME-Version: 1.0 References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> In-Reply-To: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> From: Alan Somers Date: Wed, 22 Aug 2018 13:20:29 -0600 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: Sean Fagan Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:46:32 -0000 On Wed, Aug 22, 2018 at 12:30 PM Sean Fagan wrote: > On Aug 21, 2018, at 8:16 PM, Alan Somers wrote: > > > > > The last time I looked (which was a long time ago), Oracle's ZFS > encryption looked extremely vulnerable to watermarking attacks. Did > anybody ever fix that? > > This is the comment about dedup in zio_crypt.c: > > * CONSIDERATIONS FOR DEDUP: > * In order for dedup to work, blocks that we want to dedup with one > another > * need to use the same IV and encryption key, so that they will have the > same > * ciphertext. Normally, one should never reuse an IV with the same > encryption > * key or else AES-GCM and AES-CCM can both actually leak the plaintext o= f > both > * blocks. In this case, however, since we are using the same plaintext a= s > * well all that we end up with is a duplicate of the original ciphertext > we > * already had. As a result, an attacker with read access to the raw disk > will > * be able to tell which blocks are the same but this information is give= n > away > * by dedup anyway. In order to get the same IVs and encryption keys for > * equivalent blocks of data we use an HMAC of the plaintext. We use an > HMAC > * here so that a reproducible checksum of the plaintext is never > available to > * the attacker. The HMAC key is kept alongside the master key, encrypted > on > * disk. The first 64 bits of the HMAC are used in place of the random > salt, and > * the next 96 bits are used as the IV. As a result of this mechanism, > dedup > * will only work within a clone family since encrypted dedup requires us= e > of > * the same master and HMAC keys. > > (So, same issue. I don=E2=80=99t think encryption and deduplication shou= ld live > together, > so I would not have made that choice.) > > Sean. > That doesn't answer the question about what happens when dedup is turned off. In that case, is the HMAC still used as the IV? If so, then watermarking attacks are still possible. If ZFS switches to a random IV when dedup is off, then it would probably be ok. -Alan From owner-freebsd-current@freebsd.org Wed Aug 22 19:46: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 351311093B92 for ; Wed, 22 Aug 2018 19:46:55 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6BBE880A6 for ; Wed, 22 Aug 2018 19:46:54 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: by mail-pf1-x435.google.com with SMTP id i26-v6so1449675pfo.12 for ; Wed, 22 Aug 2018 12:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOv7n72cDyWUU7iJNV38AFpKId3+/WvjhxWV1Nrhajo=; b=Xbc+ow6mfHnVEE2ATrYMlU/GaFjnSxEAWHW9pHeKaFcGU6bpq3BaXtwIingm83bKpc bsLiQuI+npLzBU3DqFFDZ8Ae+Zb4joGMXP+zYUDhu9hsfacqZsmdh8lssc5siSx2ApMV yzNjfqElF2YbDKxTFQ/ihNbR7aJPaRcGk7QEBqNyrjVq9w3nv/+sZbJs28wK5aixu/FW Eb9kFUktBN7PxaClWKhgDIbyQxQa4EfXQMoPNsKKESZwDQ0KBFyTa8KlLq4BEVPTR7BF d1i531DhbBbkDsQKJVy+10SkwUs0O0ieEwf8rPOLEc+yr+6xaeY3j0rMYc75EKqBZa11 VKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NOv7n72cDyWUU7iJNV38AFpKId3+/WvjhxWV1Nrhajo=; b=olXswX5Ac2gzFvUv1g422+2nWpPYDlcJ5a43M+IYHjRxxnxlqfPXmhnVeHPwmCBj8L 5PH3RZm9bIRO7eIEJawa7RNZLCMu7WwXEsD7mDZ3kEzwQKw3pxD2qy4E1cht+5e5CwS5 ITHTMO+LRjgDy5XtPi6fn9iZKHc0JP4vu729WLpp6oiTVRGRfsTdOg+q8B3QDreAygtq Oz6k2VhFZeGt1dquZwiJAF2VnMRVb6LNjsiZpKpOFgrAhctTRXa+47NyO72Z+iMPLl3l bDrT7vUXaEp4oiDhg03D1G7C+TRIs0oPnUULB9pOykqExxb49Frnz2Ro3RP1rqvreZIE D23w== X-Gm-Message-State: AOUpUlFAo0INcGAPE4OliYWKqaRCDJYpwHcut3QWf5klrT84+zc9LyuI exJQ6CUSAj3mhQp5ZwoVjWMXLgrr4fU= X-Google-Smtp-Source: AA+uWPy3k3gfkTlpp2P9WYn/Eo7SXxsZojUiXVcRVZM3PEQLFTzvZyVw5y0OFJGhkVe5p0FZp5pszg== X-Received: by 2002:a63:1760:: with SMTP id 32-v6mr22399958pgx.31.1534967213704; Wed, 22 Aug 2018 12:46:53 -0700 (PDT) Received: from [10.250.1.167] ([12.229.62.29]) by smtp.gmail.com with ESMTPSA id f11-v6sm3347916pfa.131.2018.08.22.12.46.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 12:46:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Native Encryption for ZFS on FreeBSD CFT From: Sean Fagan In-Reply-To: Date: Wed, 22 Aug 2018 12:46:51 -0700 Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: <8C65E4ED-9AF3-4469-9C5A-BF058D50C3F5@ixsystems.com> References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> To: Alan Somers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:46:55 -0000 On Aug 22, 2018, at 12:35 PM, Alan Somers wrote: > Only encrypting L0 blocks also leaks a lot of information. That means = that, if encryption is set to anything but "off", watermarking attacks = will still be possible based on the size and sparsity of a file. = Because I believe that with any encryption mode, ZFS turns continuous = runs of zeros into holes. And I don't see anything in zio_crypt.c that = addresses that. I=E2=80=99m not sure about that. However, with compression=3Doff, dd if=3D/dev/zero of=3Dbigfile bs=3D1m count=3D1024 results in a file that is 1565148 blocks (of 128k bytes), which supports = your statement. With compression=3Don, it creates a 1 block file. Sean. From owner-freebsd-current@freebsd.org Wed Aug 22 19:48: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 65E071093CDA; Wed, 22 Aug 2018 19:48:14 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from turad.lysandor.de (turad.lysandor.de [136.243.10.60]) (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 798238832A; Wed, 22 Aug 2018 19:48:13 +0000 (UTC) (envelope-from flo@snakeoilproductions.net) Received: from localhost (localhost [127.0.0.1]) by turad.lysandor.de (Postfix) with ESMTP id 17775AA2C59; Wed, 22 Aug 2018 21:48:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at turad.lysandor.de Received: from turad.lysandor.de ([127.0.0.1]) by localhost (turad.lysandor.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MwTiTqzUPM-W; Wed, 22 Aug 2018 21:48:00 +0200 (CEST) Received: from [192.168.2.107] (p5089D4D5.dip0.t-ipconnect.de [80.137.212.213]) (Authenticated sender: flo@snakeoilproductions.net) by turad.lysandor.de (Postfix) with ESMTPSA id 340EDAA2A31; Wed, 22 Aug 2018 21:48:00 +0200 (CEST) From: Florian Limberger Subject: VGA adapter not working To: freebsd-x11@freebsd.org, freebsd-current@freebsd.org Message-ID: Date: Wed, 22 Aug 2018 21:47:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:48:15 -0000 Hi, I recently reinstalled my old Thinkpad T410 with ZFS and -CURRENT, but I cannot get my VGA adapter working. It worked before and it also works with Linux from a memory stick. The notebook has NVIDIA Optimus, but it is disabled and set to discrete graphics in the BIOS, using the x11/nvidia-driver-340 driver. X11 works, but it does not find the correct resolution for the display. Also, xrandr does not report any other possible outputs. Currently I am at a loss about what is wrong with the setup and would greatly appreciate any hints and ideas. Below are: - dmesg - output of pciconf -lvbce - output of devinfo -vr - output of pkg info - Xorg.log Thanks in advance! -flo === dmesg ---<>--- Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-ALPHA2 #2 r338043: Sun Aug 19 21:31:15 CEST 2018 root@nachtschatten.purplekraken.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz (2660.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x20655 Family=0x6 Model=0x25 Stepping=5 Features=0xbfebfbff Features2=0x29ae3ff AMD Features=0x28100800 AMD Features2=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3929583616 (3747 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. Firmware Warning (ACPI): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20180810/tbfadt-748) Firmware Warning (ACPI): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20180810/tbfadt-850) ioapic0 irqs 0-23 on motherboard Launching APs: 1 Timecounter "TSC-low" frequency 1330032104 Hz quality 1000 random: entropy device external interface [ath_hal] loaded module_register_init: MOD_LOAD (vesa, 0xffffffff81125590, 0) error 19 kbd1 at kbdmux0 netmap: loaded module nexus0 vtvga0: on motherboard cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: port 0xcf8-0xcff on acpi0 pci1: on pcib1 pcib2: irq 16 at device 1.0 on pci1 pci2: on pcib2 vgapci0: port 0x2000-0x207f mem 0xcc000000-0xccffffff,0xd0000000-0xdfffffff,0xce000000-0xcfffffff irq 16 at device 0.0 on pci2 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device hdac0: mem 0xcdefc000-0xcdefffff at device 0.1 on pci2 pci1: at device 22.0 (no driver attached) uart2: <5 Series/3400 Series Chipset KT Controller> port 0x1800-0x1807 mem 0xf2424000-0xf2424fff irq 17 at device 22.3 on pci1 uart2: Using 1 MSI message em0: port 0x1820-0x183f mem 0xf2400000-0xf241ffff,0xf2425000-0xf2425fff irq 20 at device 25.0 on pci1 em0: attach_pre capping queues at 1 em0: using 1024 tx descriptors and 1024 rx descriptors em0: msix_init qsets capped at 1 em0: Unable to map MSIX table em0: Using an MSI interrupt em0: allocated for 1 tx_queues em0: allocated for 1 rx_queues em0: Ethernet address: f0:de:f1:46:1b:8c em0: netmap queues/slots: TX 1/1024, RX 1/1024 ehci0: mem 0xf2428000-0xf24283ff irq 23 at device 26.0 on pci1 usbus0: EHCI version 1.0 usbus0 on ehci0 usbus0: 480Mbps High Speed USB v2.0 hdac1: mem 0xf2420000-0xf2423fff irq 17 at device 27.0 on pci1 pcib3: irq 20 at device 28.0 on pci1 pci3: on pcib3 pcib4: irq 21 at device 28.1 on pci1 pci4: on pcib4 iwn0: mem 0xf2000000-0xf2001fff irq 17 at device 0.0 on pci4 pcib5: irq 20 at device 28.4 on pci1 pci5: on pcib5 sdhci_pci0: mem 0xf2100000-0xf21000ff irq 16 at device 0.0 on pci5 sdhci_pci0: 1 slot(s) allocated ehci1: mem 0xf2428400-0xf24287ff irq 19 at device 29.0 on pci1 usbus1: EHCI version 1.0 usbus1 on ehci1 usbus1: 480Mbps High Speed USB v2.0 pcib6: at device 30.0 on pci1 pci6: on pcib6 isab0: at device 31.0 on pci1 isa0: on isab0 ahci0: port 0x1818-0x181f,0x180c-0x180f,0x1810-0x1817,0x1808-0x180b,0x1840-0x185f mem 0xf2427000-0xf24277ff irq 16 at device 31.2 on pci1 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdd000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 est0: on cpu0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) Timecounters tick every 1.000 msec hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 25 and 27 on hdaa4 pcm5: at nid 31 and 35 on hdaa4 ugen1.1: at usbus1 ugen0.1: at usbus0 uhub0: on usbus1 uhub1: on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number 173818D01765 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 500786MB (1025610768 512 byte sectors) ses0 at ahciem0 bus 0 scbus4 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device Trying to mount root from zfs:zroot/ROOT/default []... cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed GEOM_ELI: Device ada0p3.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: hardware Root mount waiting for: usbus1 usbus0 Root mount waiting for: usbus1 usbus0 uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered Root mount waiting for: usbus1 usbus0 ugen1.2: at usbus1 uhub2 on uhub0 uhub2: on usbus1 ugen0.2: at usbus0 uhub3 on uhub1 uhub3: on usbus0 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus1 usbus0 uhub2: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ukbd0 on uhub3 ukbd0: on usbus0 kbd2 at ukbd0 ugen0.4: at usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 Root mount waiting for: usbus0 ugen0.6: at usbus0 GEOM_ELI: Device ada0p2.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware lo0: link state changed to UP Link state changed to up em0: link state changed to UP ums0 on uhub3 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=1 ums1 on uhub3 ums1: on usbus0 ums1: 5 buttons and [XYZ] coordinates ID=0 ubt0 on uhub3 ubt0: on usbus0 WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() === pciconf hostb0@pci0:255:0:0: class=0x060000 card=0x219617aa chip=0x2c628086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Core Processor QuickPath Architecture Generic Non-core Registers' class = bridge subclass = HOST-PCI hostb1@pci0:255:0:1: class=0x060000 card=0x219617aa chip=0x2d018086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Core Processor QuickPath Architecture System Address Decoder' class = bridge subclass = HOST-PCI hostb2@pci0:255:2:0: class=0x060000 card=0x219617aa chip=0x2d108086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Core Processor QPI Link 0' class = bridge subclass = HOST-PCI hostb3@pci0:255:2:1: class=0x060000 card=0x219617aa chip=0x2d118086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '1st Generation Core i3/5/7 Processor QPI Physical 0' class = bridge subclass = HOST-PCI hostb4@pci0:255:2:2: class=0x060000 card=0x219617aa chip=0x2d128086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '1st Generation Core i3/5/7 Processor Reserved' class = bridge subclass = HOST-PCI hostb5@pci0:255:2:3: class=0x060000 card=0x219617aa chip=0x2d138086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '1st Generation Core i3/5/7 Processor Reserved' class = bridge subclass = HOST-PCI hostb6@pci0:0:0:0: class=0x060000 card=0x219317aa chip=0x00448086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Core Processor DRAM Controller' class = bridge subclass = HOST-PCI cap 09[e0] = vendor (length 12) Intel cap 0 version 1 PCI errors = Received Master-Abort pcib2@pci0:0:1:0: class=0x060400 card=0x219417aa chip=0x00458086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = 'Core Processor PCI Express x16 Root Port' class = bridge subclass = PCI-PCI cap 0d[88] = PCI Bridge card=0x219417aa cap 01[80] = powerspec 3 supports D0 D3 current D0 cap 05[90] = MSI supports 1 message cap 10[a0] = PCI-Express 2 root port max data 128(128) link x16(x16) speed 2.5(2.5) ASPM L0s/L1(L0s/L1) slot 17 power limit 75000 mW ecap 0002[100] = VC 1 max VC0 none0@pci0:0:22:0: class=0x078000 card=0x215f17aa chip=0x3b648086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset HECI Controller' class = simple comms bar [10] = type Memory, range 64, base 0xf2427800, size 16, enabled cap 01[50] = powerspec 3 supports D0 D3 current D3 cap 05[8c] = MSI supports 1 message, 64 bit uart2@pci0:0:22:3: class=0x070002 card=0x216217aa chip=0x3b678086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset KT Controller' class = simple comms subclass = UART bar [10] = type I/O Port, range 32, base 0x1800, size 8, enabled bar [14] = type Memory, range 32, base 0xf2424000, size 4096, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message em0@pci0:0:25:0: class=0x020000 card=0x215317aa chip=0x10ea8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82577LM Gigabit Network Connection' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf2400000, size 131072, enabled bar [14] = type Memory, range 32, base 0xf2425000, size 4096, enabled bar [18] = type I/O Port, range 32, base 0x1820, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:0: class=0x0c0320 card=0x216317aa chip=0x3b3c8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset USB2 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xf2428000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP hdac1@pci0:0:27:0: class=0x040300 card=0x215e17aa chip=0x3b568086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset High Definition Audio' class = multimedia subclass = HDA bar [10] = type Memory, range 64, base 0xf2420000, size 16384, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR NS ecap 0002[100] = VC 1 max VC1 ecap 0005[130] = Root Complex Link Declaration 1 pcib3@pci0:0:28:0: class=0x060400 card=0x216417aa chip=0x3b428086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port max data 128(128) link x0(x1) speed 0.0(2.5) ASPM disabled(L0s/L1) slot 0 power limit 100 mW cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x216417aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib4@pci0:0:28:1: class=0x060400 card=0x216417aa chip=0x3b448086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset PCI Express Root Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) slot 1 power limit 100 mW cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x216417aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:0:28:4: class=0x060400 card=0x216417aa chip=0x3b4a8086 rev=0x06 hdr=0x01 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset PCI Express Root Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 2 root port max data 128(128) link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) slot 4 power limit 100 mW cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x216417aa cap 01[a0] = powerspec 2 supports D0 D3 current D0 ehci1@pci0:0:29:0: class=0x0c0320 card=0x216317aa chip=0x3b348086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset USB2 Enhanced Host Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xf2428400, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib6@pci0:0:30:0: class=0x060401 card=0x216517aa chip=0x24488086 rev=0xa6 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Mobile PCI Bridge' class = bridge subclass = PCI-PCI cap 0d[50] = PCI Bridge card=0x216517aa isab0@pci0:0:31:0: class=0x060100 card=0x216617aa chip=0x3b078086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'QM57 Chipset LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 16) Intel cap 1 version 1 ahci0@pci0:0:31:2: class=0x010601 card=0x216817aa chip=0x3b2f8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset 6 port SATA AHCI Controller' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0x1818, size 8, enabled bar [14] = type I/O Port, range 32, base 0x180c, size 4, enabled bar [18] = type I/O Port, range 32, base 0x1810, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x1808, size 4, enabled bar [20] = type I/O Port, range 32, base 0x1840, size 32, enabled bar [24] = type Memory, range 32, base 0xf2427000, size 2048, enabled cap 05[80] = MSI supports 1 message enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair cap 13[b0] = PCI Advanced Features: FLR TP none1@pci0:0:31:3: class=0x0c0500 card=0x216717aa chip=0x3b308086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0xf2428800, size 256, enabled bar [20] = type I/O Port, range 32, base 0x1860, size 32, enabled none2@pci0:0:31:6: class=0x118000 card=0x219017aa chip=0x3b328086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '5 Series/3400 Series Chipset Thermal Subsystem' class = dasp bar [10] = type Memory, range 64, base 0xf2426000, size 4096, enabled cap 01[50] = powerspec 3 supports D0 D3 current D3 cap 05[80] = MSI supports 1 message vgapci0@pci0:1:0:0: class=0x030000 card=0x21d417aa chip=0x0a6c10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GT218M [NVS 3100M]' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xcc000000, size 16777216, enabled bar [14] = type Prefetchable Memory, range 64, base 0xd0000000, size 268435456, enabled bar [1c] = type Prefetchable Memory, range 64, base 0xce000000, size 33554432, enabled bar [24] = type I/O Port, range 32, base 0x2000, size 128, enabled cap 01[60] = powerspec 3 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[78] = PCI-Express 2 endpoint max data 128(128) RO NS link x16(x16) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) cap 09[b4] = vendor (length 20) ecap 0002[100] = VC 1 max VC0 ecap 0004[128] = Power Budgeting 1 ecap 000b[600] = Vendor 1 ID 1 hdac0@pci0:1:0:1: class=0x040300 card=0x218f17aa chip=0x0be310de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'High Definition Audio Controller' class = multimedia subclass = HDA bar [10] = type Memory, range 32, base 0xcdefc000, size 16384, enabled cap 01[60] = powerspec 3 supports D0 D3 current D0 cap 05[68] = MSI supports 1 message, 64 bit cap 10[78] = PCI-Express 2 endpoint max data 128(128) RO NS link x16(x16) speed 2.5(5.0) ASPM L0s/L1(L0s/L1) iwn0@pci0:3:0:0: class=0x028000 card=0x11118086 chip=0x42388086 rev=0x35 hdr=0x00 vendor = 'Intel Corporation' device = 'Centrino Ultimate-N 6300' class = network bar [10] = type Memory, range 64, base 0xf2000000, size 8192, enabled cap 01[c8] = powerspec 3 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR RO NS link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 0024d7ffff91b544 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error sdhci_pci0@pci0:13:0:0: class=0x080500 card=0x213317aa chip=0xe8221180 rev=0x01 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'MMC/SD Host Controller' class = base peripheral subclass = SD host controller bar [10] = type Memory, range 32, base 0xf2100000, size 256, enabled cap 05[50] = MSI supports 1 message, 64 bit enabled with 1 message cap 01[78] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[80] = PCI-Express 1 endpoint max data 128(128) RO NS link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0002[100] = VC 1 max VC0 ecap 0001[800] = AER 1 0 fatal 0 non-fatal 1 corrected PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error none3@pci0:13:0:1: class=0x088000 card=0x213417aa chip=0xe2301180 rev=0x01 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'R5U2xx (R5U230 / R5U231 / R5U241) [Memory Stick Host Controller]' class = base peripheral bar [10] = type Memory, range 32, base 0xf2100400, size 256, enabled cap 05[50] = MSI supports 1 message, 64 bit cap 01[78] = powerspec 3 supports D0 D1 D2 D3 current D3 cap 10[80] = PCI-Express 1 endpoint max data 128(128) RO NS link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error === devinfo nexus0 cryptosoft0 vtvga0 I/O memory addresses: 0xa0000-0xaffff apic0 ram0 I/O memory addresses: 0x0-0x9e7ff 0x100000-0xbf27bfff 0xbf282000-0xbf35dfff 0xbf40f000-0xbf46efff 0xbf70f000-0xbf716fff 0xbf71f000-0xbf76afff 0xbf7ff000-0xbf7fffff 0x100000000-0x137ffffff aesni0 acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x24-0x25 0x28-0x29 0x2c-0x2d 0x2e-0x2f 0x30-0x31 0x34-0x35 0x38-0x39 0x3c-0x3d 0x50-0x53 0x72-0x77 0x90-0x9f 0xa4-0xa5 0xa8-0xa9 0xac-0xad 0xb0-0xb5 0xb8-0xb9 0xbc-0xbd 0x800-0x80f 0x1000-0x107f 0x1180-0x11ff 0x15e0-0x15ef 0x1600-0x1641 0x1644-0x167f I/O memory addresses: 0xc0000-0xc3fff 0xc4000-0xc7fff 0xc8000-0xcbfff 0xcc000-0xcffff 0xd0000-0xd3fff 0xdc000-0xdffff 0xe0000-0xe3fff 0xe4000-0xe7fff 0xe8000-0xebfff 0xec000-0xeffff 0xf0000-0xfffff 0xe0000000-0xefffffff 0xfeaff000-0xfeafffff 0xfec00000-0xfed3ffff 0xfed45000-0xfed4bfff 0xfed4c000-0xffffffff acpi_ec0 pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__ I/O ports: 0x62 0x66 cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 acpi_perf0 est0 p4tcc0 acpi_throttle0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 acpi_perf1 est1 p4tcc1 acpi_throttle1 cpufreq1 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU4 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU5 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU6 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU7 pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_sysresource0 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ acpi_lid0 pnpinfo _HID=PNP0C0D _UID=0 at handle=\_SB_.LID_ acpi_button0 pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.UNCR pci0 PCI domain 0 bus numbers: 255 hostb0 pnpinfo vendor=0x8086 device=0x2c62 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=0 function=0 dbsf=pci0:255:0:0 hostb1 pnpinfo vendor=0x8086 device=0x2d01 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=0 function=1 dbsf=pci0:255:0:1 handle=\_SB_.UNCR.SAD_ hostb2 pnpinfo vendor=0x8086 device=0x2d10 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=2 function=0 dbsf=pci0:255:2:0 hostb3 pnpinfo vendor=0x8086 device=0x2d11 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=2 function=1 dbsf=pci0:255:2:1 hostb4 pnpinfo vendor=0x8086 device=0x2d12 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=2 function=2 dbsf=pci0:255:2:2 hostb5 pnpinfo vendor=0x8086 device=0x2d13 subvendor=0x17aa subdevice=0x2196 class=0x060000 at slot=2 function=3 dbsf=pci0:255:2:3 pcib1 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0 I/O ports: 0xcf8-0xcff pci1 PCI domain 0 bus numbers: 0 hostb6 pnpinfo vendor=0x8086 device=0x0044 subvendor=0x17aa subdevice=0x2193 class=0x060000 at slot=0 function=0 dbsf=pci0:0:0:0 pcib2 pnpinfo vendor=0x8086 device=0x0045 subvendor=0x17aa subdevice=0x2194 class=0x060400 at slot=1 function=0 dbsf=pci0:0:1:0 handle=\_SB_.PCI0.PEG_ I/O ports: 0x2000-0x2fff I/O memory addresses: 0xcc000000-0xcdefffff 0xce000000-0xdfffffff PCI domain 0 bus numbers: 1 pci2 pcib2 bus numbers: 1 vgapci0 pnpinfo vendor=0x10de device=0x0a6c subvendor=0x17aa subdevice=0x21d4 class=0x030000 at slot=0 function=0 dbsf=pci0:1:0:0 handle=\_SB_.PCI0.PEG_.VID_ Interrupt request lines: 0x108 pcib2 I/O port window: 0x2000-0x207f pcib2 memory window: 0xcc000000-0xccffffff pcib2 prefetch window: 0xce000000-0xcfffffff 0xd0000000-0xdfffffff nvidia0 drm0 drmn0 hdac0 pnpinfo vendor=0x10de device=0x0be3 subvendor=0x17aa subdevice=0x218f class=0x040300 at slot=0 function=1 dbsf=pci0:1:0:1 Interrupt request lines: 0x11 pcib2 memory window: 0xcdefc000-0xcdefffff hdacc0 pnpinfo vendor=0x10de device=0x000b revision=0x02 stepping=0x00 at cad=0 hdaa0 pnpinfo type=0x01 subsystem=0x10de0101 at nid=1 pcm0 at nid=5 hdacc1 pnpinfo vendor=0x10de device=0x000b revision=0x02 stepping=0x00 at cad=1 hdaa1 pnpinfo type=0x01 subsystem=0x10de0101 at nid=1 pcm1 at nid=5 hdacc2 pnpinfo vendor=0x10de device=0x000b revision=0x02 stepping=0x00 at cad=2 hdaa2 pnpinfo type=0x01 subsystem=0x10de0101 at nid=1 pcm2 at nid=5 hdacc3 pnpinfo vendor=0x10de device=0x000b revision=0x02 stepping=0x00 at cad=3 hdaa3 pnpinfo type=0x01 subsystem=0x10de0101 at nid=1 pcm3 at nid=5 unknown pnpinfo vendor=0x8086 device=0x3b64 subvendor=0x17aa subdevice=0x215f class=0x078000 at slot=22 function=0 dbsf=pci0:0:22:0 I/O memory addresses: 0xf2427800-0xf242780f uart2 pnpinfo vendor=0x8086 device=0x3b67 subvendor=0x17aa subdevice=0x2162 class=0x070002 at slot=22 function=3 dbsf=pci0:0:22:3 Interrupt request lines: 0x109 I/O ports: 0x1800-0x1807 I/O memory addresses: 0xf2424000-0xf2424fff em0 pnpinfo vendor=0x8086 device=0x10ea subvendor=0x17aa subdevice=0x2153 class=0x020000 at slot=25 function=0 dbsf=pci0:0:25:0 handle=\_SB_.PCI0.IGBE Interrupt request lines: 0x10a I/O ports: 0x1820-0x183f I/O memory addresses: 0xf2400000-0xf241ffff 0xf2425000-0xf2425fff ehci0 pnpinfo vendor=0x8086 device=0x3b3c subvendor=0x17aa subdevice=0x2163 class=0x0c0320 at slot=26 function=0 dbsf=pci0:0:26:0 handle=\_SB_.PCI0.EHC2 Interrupt request lines: 0x17 I/O memory addresses: 0xf2428000-0xf24283ff usbus0 uhub1 uhub3 pnpinfo vendor=0x8087 product=0x0020 devclass=0x09 devsubclass=0x00 devproto=0x01 sernum="" release=0x0000 mode=host intclass=0x09 intsubclass=0x00 intprotocol=0x00 at bus=0 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen0.2 ukbd0 pnpinfo vendor=0x13ba product=0x0017 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 at bus=0 hubaddr=2 port=1 devaddr=3 interface=0 ugen=ugen0.3 ums0 pnpinfo vendor=0x13ba product=0x0017 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0001 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 at bus=0 hubaddr=2 port=1 devaddr=3 interface=1 ugen=ugen0.3 ums1 pnpinfo vendor=0x1241 product=0x1166 devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0700 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 at bus=0 hubaddr=2 port=2 devaddr=4 interface=0 ugen=ugen0.4 ubt0 pnpinfo vendor=0x0a5c product=0x217f devclass=0xe0 devsubclass=0x01 devproto=0x01 sernum="889FFAEE410F" release=0x0360 mode=host intclass=0xe0 intsubclass=0x01 intprotocol=0x01 at bus=0 hubaddr=2 port=4 devaddr=5 interface=0 ugen=ugen0.5 hdac1 pnpinfo vendor=0x8086 device=0x3b56 subvendor=0x17aa subdevice=0x215e class=0x040300 at slot=27 function=0 dbsf=pci0:0:27:0 handle=\_SB_.PCI0.HDEF Interrupt request lines: 0x10b I/O memory addresses: 0xf2420000-0xf2423fff hdacc4 pnpinfo vendor=0x14f1 device=0x5069 revision=0x03 stepping=0x02 at cad=0 hdaa4 pnpinfo type=0x01 subsystem=0x17aa214c at nid=1 pcm4 at nid=25,27 pcm5 at nid=31,35 pcib3 pnpinfo vendor=0x8086 device=0x3b42 subvendor=0x17aa subdevice=0x2164 class=0x060400 at slot=28 function=0 dbsf=pci0:0:28:0 handle=\_SB_.PCI0.EXP1 PCI domain 0 bus numbers: 2 pci3 pcib3 bus numbers: 2 pcib4 pnpinfo vendor=0x8086 device=0x3b44 subvendor=0x17aa subdevice=0x2164 class=0x060400 at slot=28 function=1 dbsf=pci0:0:28:1 handle=\_SB_.PCI0.EXP2 I/O memory addresses: 0xf2000000-0xf20fffff PCI domain 0 bus numbers: 3 pci4 pcib4 bus numbers: 3 iwn0 pnpinfo vendor=0x8086 device=0x4238 subvendor=0x8086 subdevice=0x1111 class=0x028000 at slot=0 function=0 dbsf=pci0:3:0:0 Interrupt request lines: 0x10c pcib4 memory window: 0xf2000000-0xf2001fff pcib5 pnpinfo vendor=0x8086 device=0x3b4a subvendor=0x17aa subdevice=0x2164 class=0x060400 at slot=28 function=4 dbsf=pci0:0:28:4 handle=\_SB_.PCI0.EXP5 I/O memory addresses: 0xf2100000-0xf21fffff PCI domain 0 bus numbers: 13 pci5 pcib5 bus numbers: 13 sdhci_pci0 pnpinfo vendor=0x1180 device=0xe822 subvendor=0x17aa subdevice=0x2133 class=0x080500 at slot=0 function=0 dbsf=pci0:13:0:0 Interrupt request lines: 0x10d pcib5 memory window: 0xf2100000-0xf21000ff unknown pnpinfo vendor=0x1180 device=0xe230 subvendor=0x17aa subdevice=0x2134 class=0x088000 at slot=0 function=1 dbsf=pci0:13:0:1 pcib5 memory window: 0xf2100400-0xf21004ff ehci1 pnpinfo vendor=0x8086 device=0x3b34 subvendor=0x17aa subdevice=0x2163 class=0x0c0320 at slot=29 function=0 dbsf=pci0:0:29:0 handle=\_SB_.PCI0.EHC1 Interrupt request lines: 0x13 I/O memory addresses: 0xf2428400-0xf24287ff usbus1 uhub0 uhub2 pnpinfo vendor=0x8087 product=0x0020 devclass=0x09 devsubclass=0x00 devproto=0x01 sernum="" release=0x0000 mode=host intclass=0x09 intsubclass=0x00 intprotocol=0x00 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen1.2 pcib6 pnpinfo vendor=0x8086 device=0x2448 subvendor=0x17aa subdevice=0x2165 class=0x060401 at slot=30 function=0 dbsf=pci0:0:30:0 handle=\_SB_.PCI0.PCI1 PCI domain 0 bus numbers: 14 pci6 pcib6 bus numbers: 14 isab0 pnpinfo vendor=0x8086 device=0x3b07 subvendor=0x17aa subdevice=0x2166 class=0x060100 at slot=31 function=0 dbsf=pci0:0:31:0 handle=\_SB_.PCI0.LPC_ isa0 sc0 vga0 orm0 pnpinfo pnpid=ORM0000 ACPI I/O memory addresses: 0xd0000-0xd0fff 0xd1000-0xd1fff 0xdd000-0xdffff 0xe0000-0xeffff fdc0 ppc0 uart0 uart1 ahci0 pnpinfo vendor=0x8086 device=0x3b2f subvendor=0x17aa subdevice=0x2168 class=0x010601 at slot=31 function=2 dbsf=pci0:0:31:2 handle=\_SB_.PCI0.SAT1 Interrupt request lines: 0x10e I/O ports: 0x1808-0x180b 0x180c-0x180f 0x1810-0x1817 0x1818-0x181f 0x1840-0x185f I/O memory addresses: 0xf2427000-0xf24277ff ahcich0 at channel=0 I/O memory addresses: 0xf2427100-0xf242717f ahcich1 at channel=1 I/O memory addresses: 0xf2427180-0xf24271ff ahcich2 at channel=2 (disabled) ahcich3 at channel=3 (disabled) ahcich4 at channel=4 I/O memory addresses: 0xf2427300-0xf242737f ahcich5 at channel=5 I/O memory addresses: 0xf2427380-0xf24273ff ahciem0 I/O memory addresses: 0xf2427020-0xf2427023 0xf2427580-0xf2427587 unknown pnpinfo vendor=0x8086 device=0x3b30 subvendor=0x17aa subdevice=0x2167 class=0x0c0500 at slot=31 function=3 dbsf=pci0:0:31:3 handle=\_SB_.PCI0.SMBU I/O ports: 0x1860-0x187f I/O memory addresses: 0xf2428800-0xf24288ff unknown pnpinfo vendor=0x8086 device=0x3b32 subvendor=0x17aa subdevice=0x2190 class=0x118000 at slot=31 function=6 dbsf=pci0:0:31:6 I/O memory addresses: 0xf2426000-0xf2426fff acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.LPC_.SIO_ unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.LPC_.PIC_ I/O ports: 0x20-0x21 0xa0-0xa1 0x4d0-0x4d1 attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.LPC_.TIMR Interrupt request lines: 0x0 I/O ports: 0x40-0x43 hpet0 pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.LPC_.HPET Interrupt request lines: 0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107 ACPI I/O memory addresses: 0xfed00000-0xfed003ff atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.LPC_.DMAC DMA request lines: 4 I/O ports: 0x0-0xf 0x80-0x8f 0xc0-0xdf unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.LPC_.SPKR I/O ports: 0x61 fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.LPC_.FPU_ I/O ports: 0xf0 atrtc0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.LPC_.RTC_ Interrupt request lines: 0x8 I/O ports: 0x70-0x71 atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.KBD_ Interrupt request lines: 0x1 I/O ports: 0x60 0x64 atkbd0 psm0 Interrupt request lines: 0xc psmcpnp0 pnpinfo _HID=LEN0015 _UID=0 at handle=\_SB_.PCI0.LPC_.MOU_ unknown pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PCI0.LPC_.UART (disabled) unknown pnpinfo _HID=PNP0400 _UID=0 at handle=\_SB_.PCI0.LPC_.LPT_ (disabled) unknown pnpinfo _HID=PNP0401 _UID=0 at handle=\_SB_.PCI0.LPC_.ECP_ (disabled) unknown pnpinfo _HID=SMO1200 _UID=1 at handle=\_SB_.PCI0.LPC_.TPM_ I/O memory addresses: 0xfed40000-0xfed44fff unknown pnpinfo _HID=PNP0C09 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__ (disabled) unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.PUBS battery0 pnpinfo _HID=PNP0C0A _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.BAT0 unknown pnpinfo _HID=PNP0C0A _UID=1 at handle=\_SB_.PCI0.LPC_.EC__.BAT1 (disabled) acpi_acad0 pnpinfo _HID=ACPI0003 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.AC__ acpi_ibm0 pnpinfo _HID=IBM0068 _UID=0 at handle=\_SB_.PCI0.LPC_.EC__.HKEY unknown pnpinfo _HID=PNP0C14 _UID=0 at handle=\_SB_.PCI0.WMI1 unknown pnpinfo _HID=PNP0C14 _UID=1 at handle=\_SB_.WMI1 acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THM0 acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x1008-0x100b === pkg-info ImageMagick-6.9.9.28_1,1 Image processing tools (legacy version) ORBit2-2.14.19_2 High-performance CORBA ORB with support for the C language adwaita-icon-theme-3.22.0 GNOME Symbolic Icons alsa-lib-1.1.2_1 ALSA compatibility library alsa-plugins-1.1.1_3 ALSA compatibility library plugins apr-1.6.3.1.6.1_1 Apache Portability Library argyllcms-1.9.2_3 ICC compatible color management system aspell-0.60.6.1_7 Spelling checker with better suggestion logic than ispell at-spi2-atk-2.24.0 Assisted Technology Provider module for GTK+ at-spi2-core-2.24.0 Assistive Technology Service Provider Interface atk-2.24.0 GNOME accessibility toolkit (ATK) avahi-app-0.7_1 Service discovery on a local network boost-libs-1.68.0 Free portable C++ libraries (without Boost.Python) ca_root_nss-3.38 Root certificate bundle from the Mozilla Project cairo-1.14.8_2,2 Vector graphics library with cross-device output support cln-1.3.4 Class Library for Numbers cmake-3.12.0_1 Cross-platform Makefile generator colord-1.2.12 Manage color profiles to accurately color input/output devices consolekit2-1.2.0 Framework for defining and tracking users cups-2.2.8_1 Common UNIX Printing System curl-7.61.0_1 Command line tool and library for transferring data with URLs cvsps-2.1_2 Create patchset information from CVS db5-5.3.28_7 Oracle Berkeley DB, revision 5.3 dbus-1.10.16_1 Message bus system for inter-application communication dbus-glib-0.108 GLib bindings for the D-BUS messaging system dconf-0.26.1 Configuration database system for GNOME dejavu-2.37 Bitstream Vera Fonts clone with a wider range of characters desktop-file-utils-0.23 Couple of command line utilities for working with desktop entries dialog4ports-0.1.6 Console Interface to configure ports dmidecode-3.1_1 Tool for dumping DMI (SMBIOS) contents in human-readable format docbook-1.5 Meta-port for the different versions of the DocBook DTD docbook-sgml-4.5_1 DocBook SGML DTD docbook-xml-5.0_3 DocBook XML DTD docbook-xsl-1.76.1,1 XSL DocBook stylesheets ebook-tools-0.2.2_4 Accesses and converts various ebook file formats encodings-1.0.4_4,1 X.Org Encoding fonts exiv2-0.26,1 Exif, IPTC, and XMP metadata manipulation library and tools expat-2.2.5 XML 1.0 parser written in C ffmpeg-4.0.2_2,1 Realtime audio/video encoder/converter and streaming server fftw3-3.3.8_1 Fast C routines to compute the Discrete Fourier Transform firefox-61.0.2,1 Web browser based on the browser portion of Mozilla font-bh-ttf-1.0.3_3 X.Org Bigelow & Holmes TTF font font-misc-ethiopic-1.0.3_3 X.Org miscellaneous Ethiopic font font-misc-meltho-1.0.3_3 X.Org miscellaneous Meltho font font-util-1.3.1 Create an index of X font files in a directory fontconfig-2.12.6,1 XML-based font configuration API for X Windows freetype2-2.9.1 Free and portable TrueType font rendering engine fribidi-0.19.7 Free Implementation of the Unicode Bidirectional Algorithm gconf2-3.2.6_5 Configuration database system for GNOME gdbm-1.13_1 GNU database manager gdk-pixbuf2-2.36.11 Graphic library for GTK+ gettext-runtime-0.19.8.1_1 GNU gettext runtime libraries and programs gettext-tools-0.19.8.1 GNU gettext development and translation tools ghostscript9-agpl-base-9.23_1 PostScript and PDF interpreter ghostscript9-agpl-x11-9.23_1 PostScript and PDF interpreter, X11 support giflib-5.1.4 Tools and library routines for working with GIF images git-2.18.0_1 Distributed source code management tool glib-2.50.3_5,1 Some useful routines of C programming (current stable version) gmp-6.1.2 Free library for arbitrary precision arithmetic gnome_subr-1.0 Common startup and shutdown subroutines used by GNOME scripts gnupg-2.2.9_1 Complete and free PGP implementation gnutls-3.5.19 GNU Transport Layer Security library go-1.10.3,1 Go programming language gobject-introspection-1.50.0_1,1 Generate interface introspection data for GObject libraries gpgme-1.11.1 Library to make access to GnuPG easier gpgme-cpp-1.11.1 Gpgme C++ bindings gpgme-qt5-1.11.1 Gpgme Qt5 bindings graphite2-1.3.11 Rendering capabilities for complex non-Roman writing systems gstreamer1-1.12.3 Media applications framework gstreamer1-libav-1.12.3_2 GStreamer plug-in with many audio/video decoders/encoders gstreamer1-plugins-1.12.3_1 GStreamer written collection of plugins handling several media types gstreamer1-plugins-a52dec-1.12.3 GStreamer ATSC A/52 stream aka AC-3 (dvd audio) plugin gstreamer1-plugins-bad-1.12.3_2 GStreamer-plugins that need more quality, testing or documentation gstreamer1-plugins-core-1.12 Core set of typical audio and video GStreamer plugins gstreamer1-plugins-dts-1.12.3 GStreamer dts audio decode plugin gstreamer1-plugins-dvdread-1.12.3 GStreamer DVD access plugin with libdvdread gstreamer1-plugins-good-1.12.3 GStreamer-plugins good-quality plug-ins gstreamer1-plugins-mpg123-1.12.3 GStreamer MPEG Layer 1, 2, and 3 plugin gstreamer1-plugins-ogg-1.12.3 GStreamer Ogg bitstream plugin gstreamer1-plugins-pango-1.12.3 GStreamer pango textoverlay plugin gstreamer1-plugins-png-1.12.3 GStreamer png plugin gstreamer1-plugins-resindvd-1.12.3 GStreamer resindvd DVD playback plugin gstreamer1-plugins-theora-1.12.3 GStreamer theora plugin gstreamer1-plugins-ugly-1.12.3 GStreamer-plugins set of good-quality plug-ins that might have distribution problems gstreamer1-plugins-vorbis-1.12.3 GStreamer vorbis encoder/decoder plugin gtk-update-icon-cache-2.24.32 Gtk-update-icon-cache utility from the Gtk+ toolkit gtk2-2.24.32 Gimp Toolkit for X11 GUI (previous stable version) gtk3-3.22.29_1 Gimp Toolkit for X11 GUI (current stable version) hack-font-3.003 Typeface designed for source code hal-0.5.14_33 Hardware Abstraction Layer for simplifying device access harfbuzz-1.8.8 OpenType text shaping engine hicolor-icon-theme-0.15 High-color icon theme shell from the FreeDesktop project htop-2.2.0 Better top(1) - interactive process viewer hunspell-1.6.2_1 Improved spell-checker for Hungarian and other languages hyphen-2.8.8 Library for high quality hyphenation and justification iceauth-1.0.8_1 ICE authority file utility for X icu-62.1_2,1 International Components for Unicode (from IBM) indexinfo-0.3.1 Utility to regenerate the GNU info page index iso-codes-3.76 Lists of the country, language, and currency iso names iso8879-1986_3 Character entity sets from ISO 8879:1986 (SGML) jasper-1.900.1_17 Implementation of the codec specified in the JPEG-2000 standard jbig2dec-0.14 Decoder implementation of the JBIG2 image compression format jbigkit-2.1_1 Lossless compression for bi-level images such as scanned pages, faxes jpeg-turbo-2.0.0 SIMD-accelerated JPEG codec which replaces libjpeg jsoncpp-1.8.1_4 JSON reader and writer library for C++ kf5-attica-5.48.0_1 Open Collaboration Services API library KDE5 version kf5-baloo-5.48.0_1 KF5 Framework for searching and managing user metadata kf5-breeze-icons-5.48.0 Breeze icon theme for KDE kf5-extra-cmake-modules-5.48.0 Extra modules and scripts for CMake kf5-frameworkintegration-5.48.0_1 KF5 workspace and cross-framework integration plugins kf5-kactivities-5.48.0_2 KF5 runtime and library to organize work in separate activities kf5-kactivities-stats-5.48.0_2 KF5 statistics for activities kf5-karchive-5.48.0_1 KF5 library that provides classes for handling archive formats kf5-kauth-5.48.0_1 KF5 abstraction to system policy and authentication features kf5-kbookmarks-5.48.0_1 KF5 library for bookmarks and the XBEL format kf5-kcmutils-5.48.0_1 KF5 utilities for working with KCModules kf5-kcodecs-5.48.0_1 KF5 library for string manipulation kf5-kcompletion-5.48.0_1 KF5 text completion helpers and widgets kf5-kconfig-5.48.0_1 KF5 widgets for configuration dialogs kf5-kconfigwidgets-5.48.0_1 KF5 widgets for configuration dialogs kf5-kcoreaddons-5.48.0_1 KF5 addons to QtCore kf5-kcrash-5.48.0_1 KF5 library to handle crash analysis and bug report from apps kf5-kdbusaddons-5.48.0_1 KF5 addons to QtDBus kf5-kdeclarative-5.48.0_1 KF5 library providing integration of QML and KDE Frameworks kf5-kded-5.48.0_1 KF5 extensible deamon for providing system level services kf5-kdelibs4support-5.48.0_1 KF5 porting aid from KDELibs4 kf5-kdesignerplugin-5.48.0_1 KF5 integration of Frameworks widgets in Qt Designer/Creator kf5-kdesu-5.48.0_1 KF5 integration with su for elevated privileges kf5-kdewebkit-5.48.0_1 KF5 library providing integration of QtWebKit kf5-kdoctools-5.48.0_1 KF5 documentation generation from docbook kf5-kemoticons-5.48.0_1 KF5 library to convert emoticons kf5-kfilemetadata-5.48.0_1 KF5 library for extracting file metadata kf5-kglobalaccel-5.48.0_1 KF5 library to add support for global workspace shortcuts kf5-kguiaddons-5.48.0_1 KF5 addons to QtGui kf5-kholidays-5.48.0_1 KDE library for calendar holidays kf5-khtml-5.48.0_1 KF5 KTHML rendering engine kf5-ki18n-5.48.0_1 KF5 advanced internationalization framework kf5-kiconthemes-5.48.0_1 KF5 library for handling icons in applications kf5-kidletime-5.48.0_1 KF5 library for monitoring user activity kf5-kinit-5.48.0_1 KF5 process launcher to speed up launching KDE applications kf5-kio-5.48.0_1 KF5 resource and network access abstraction kf5-kirigami2-5.48.0_1 QtQuick based components set kf5-kitemmodels-5.48.0_1 KF5 models for Qt Model/View system kf5-kitemviews-5.48.0_1 KF5 widget addons for Qt Model/View kf5-kjobwidgets-5.48.0_1 KF5 widgets for tracking KJob instance kf5-kjs-5.48.0_1 KF5 library providing an ECMAScript interpreter kf5-kjsembed-5.48.0_1 KF5 library for binding JavaScript objects to QObjects kf5-knewstuff-5.48.0_1 KF5 library for downloading application assets from the network kf5-knotifications-5.48.0_1 KF5 abstraction for system notifications kf5-knotifyconfig-5.48.0_1 KF5 configuration system for KNotify kf5-kpackage-5.48.0_1 KF5 library to load and install packages kf5-kparts-5.48.0_1 KF5 document centric plugin system kf5-kpeople-5.48.0_1 KF5 library providing access to contacts kf5-kplotting-5.48.0_1 KF5 lightweight plotting framework kf5-kpty-5.48.0_1 KF5 pty abstraction kf5-krunner-5.48.0_1 KF5 parallelized query system kf5-kservice-5.48.0_1 KF5 advanced plugin and service introspection kf5-ktexteditor-5.48.0_1 KF5 advanced embeddable text editor kf5-ktextwidgets-5.48.0_1 KF5 advanced text editing widgets kf5-kunitconversion-5.48.0_1 KF5 library for unit conversion kf5-kwallet-5.48.0_2 KF5 secure and unified container for user passwords kf5-kwayland-5.48.0_1 KF5 Client and Server library wrapper for the Wayland libraries kf5-kwidgetsaddons-5.48.0_1 KF5 addons to QtWidgets kf5-kwindowsystem-5.48.0_1 KF5 library for access to the windowing system kf5-kxmlgui-5.48.0_1 KF5 user configurable main windows kf5-kxmlrpcclient-5.48.0_1 KF5 interaction with XMLRPC services kf5-oxygen-icons5-5.48.0 The Oxygen icon theme for KDE kf5-plasma-framework-5.48.0_1 KF5 plugin based UI runtime used to write user interfaces kf5-prison-5.48.0_1 API to produce barcodes kf5-solid-5.48.0_1 KF5 hardware integration and detection kf5-sonnet-5.48.0_1 KF5 plugin-based spell checking library kf5-syntax-highlighting-5.48.0_1 KF5 syntax highlighting engine for structured text and code kf5-threadweaver-5.48.0_1 KF5 addons to QtDBus lcms2-2.9 Accurate, fast, and small-footprint color management engine libGLU-9.0.0_3 OpenGL utility library libICE-1.0.9_2,1 Inter Client Exchange library for X11 libIDL-0.8.14_3 Library for creating trees of CORBA IDL files libSM-1.2.2_4,1 Session Management library for X11 libX11-1.6.5_1,1 X11 library libXScrnSaver-1.2.3_1 The XScrnSaver library libXau-1.0.8_4 Authentication Protocol library for X11 libXaw-1.0.13_1,2 X Athena Widgets library libXcomposite-0.4.4_4,1 X Composite extension library libXcursor-1.1.15_1 X client-side cursor loading library libXdamage-1.1.4_4 X Damage extension library libXdmcp-1.1.2_1 X Display Manager Control Protocol library libXext-1.3.3_2,1 X11 Extension library libXfixes-5.0.3_1 X Fixes extension library libXfont-1.5.4_1,2 X font library libXfont2-2.0.3_1 X font library libXfontcache-1.0.5_4 The Xfontcache library libXft-2.3.2_2 Client-sided font API for X applications libXi-1.7.9_1,1 X Input extension library libXinerama-1.1.4_1,1 X11 Xinerama library libXmu-1.1.2_4,1 X Miscellaneous Utilities libraries libXp-1.0.3_1,1 X print library libXpm-3.5.12_1 X Pixmap library libXrandr-1.5.1_1 X Resize and Rotate extension library libXrender-0.9.10_1 X Render extension library libXt-1.1.5_1,1 X Toolkit library libXtst-1.2.3_1 X Test extension libXv-1.0.11_1,1 X Video Extension library libXvMC-1.0.10_1 X Video Extension Motion Compensation library libXxf86vm-1.1.4_2 X Vidmode Extension liba52-0.7.4_3 Free library for decoding ATSC A/52 streams, aka AC-3 libarchive-3.3.2,1 Library to create and read several streaming archive formats libassuan-2.5.1 IPC library used by GnuPG and gpgme libcroco-0.6.12 CSS2 parsing library libdaemon-0.14_1 Lightweight C library that eases the writing of UNIX daemons libdbusmenu-qt5-0.9.3.160420160218_5 Qt4 implementation of the DBusMenu protocol libdca-0.0.6 Free DTS Coherent Acoustics decoder libdmtx-0.7.4_10 Library for reading and writing Data Matrix barcodes libdrm-2.4.93,1 Userspace interface to kernel Direct Rendering Module services libdvdnav-6.0.0 Videolan version of the libdvdnav project libdvdread-6.0.0 Videolan version of the libdvdread project libedit-3.1.20170329_2,1 Command line editor library libepoll-shim-0.0.20161220 epoll shim implemented using kevent libepoxy-1.4.3 Library to handle OpenGL function pointer management libevdev-1.4.4 Linux Event Device library libevent-2.1.8_1 API for executing callback functions on events or timeouts libffi-3.2.1_2 Foreign Function Interface libfontenc-1.1.3_2 The fontenc Library libgcrypt-1.8.3 General purpose cryptographic library based on the code from GnuPG libgit2-0.27.3 Portable, pure C implementation of the Git core libgpg-error-1.32 Common error values for all GnuPG components libgsf-1.14.41 Extensible I/O abstraction for dealing with structured file formats libgudev-230_1 GObject bindings for libudev. libiconv-1.14_11 Character set conversion library libidn-1.34 Internationalized Domain Names command line tool libidn2-2.0.5 Implementation of IDNA2008 internationalized domain names libijs-0.35_5 C library that supports plugin printer driver for Ghostscript libinotify-20180201 Kevent based inotify compatible library libinput-1.6.0 Generic input library libksba-1.3.5 KSBA is an X.509 Library liblqr-1-0.4.2 Easy to use C/C++ seam carving library libltdl-2.4.6 System independent dlopen wrapper liblz4-1.8.2,1 LZ4 compression library, lossless and very fast libmtdev-1.1.5 Multitouch Protocol Translation Library libnghttp2-1.32.0 HTTP/2.0 C Library libogg-1.3.3,4 Ogg bitstream library libpaper-1.1.24.4 Library providing routines for paper size management libpci-3.6.2 PCI configuration space I/O made easy libpciaccess-0.13.5 Generic PCI access library libpthread-stubs-0.4 This library provides weak aliases for pthread functions libqalculate-2.6.1 Multi-purpose desktop calculator (backend library) libqrencode-4.0.0 C library for encoding data in a QR Code symbol libraw-0.18.13_1 Library for manipulating raw images librsvg2-2.40.20 Library for parsing and rendering SVG vector-graphic files libssh2-1.8.0,3 Library implementing the SSH2 protocol libtasn1-4.13 ASN.1 structure parser library libtheora-1.1.1_7 Theora video codec for the Ogg multimedia streaming system libudev-devd-0.3 libudev-compatible interface for devd libunistring-0.9.10 Unicode string library libunwind-20170615 Generic stack unwinding library libuv-1.23.0 Multi-platform support library with a focus on asynchronous I/O libv4l-1.6.3_2 Video4Linux library libva-2.2.0_1 VAAPI wrapper and dummy driver libvdpau-1.1.1_1 VDPAU wrapper and tracing library libvolume_id-0.81.1 Library to provide file system type information libvorbis-1.3.6,3 Audio compression codec library libvpx-1.7.0_1 VP8/VP9 Codec SDK libwacom-0.23_1 Adds tablet support to libinput libwmf-0.2.8.4_15 Tools and library for converting Microsoft WMF (windows metafile) libx264-0.155.2917 H.264/MPEG-4 AVC Video Encoding (Library) libxcb-1.13 The X protocol C-language Binding (XCB) library libxkbcommon-0.8.0 Keymap handling library for toolkits and window systems libxkbfile-1.0.9_1 XKB file library libxml2-2.9.7 XML parser library for GNOME libxshmfence-1.2_3 Shared memory 'SyncFence' synchronization primitive libxslt-1.1.32 The XSLT C library for GNOME libzip-1.5.1 C library for reading, creating, and modifying ZIP archives linux_base-c6-6.9_8 Base set of packages needed in Linux mode (Linux CentOS 6.9) llvm60-6.0.1_2 LLVM and Clang lmdb-0.9.22,1 OpenLDAP Lightning Memory-Mapped Database lsof-4.92.b,8 Lists information about open files (similar to fstat(1)) lzo2-2.10_1 Portable speedy, lossless data compression library mesa-dri-18.1.5 OpenGL hardware acceleration drivers for DRI2+ mesa-libs-18.1.5 OpenGL libraries that support GLX and EGL clients mkfontdir-1.0.7 Create an index of X font files in a directory mkfontscale-1.1.3_1 Creates an index of scalable font files for X mksh-56c MirBSD Korn Shell mpfr-4.0.1 Library for multiple-precision floating-point computations mpg123-1.25.10 Command-line player for MPEG Layer 1, 2, and 3 audio files nettle-3.4 Low-level cryptographic library ninja-1.8.2,2 Ninja is a small build system closest in spirit to Make noto-lite-1.0.5_1 Google font family - lite version npth-1.6 New GNU Portable Threads nspr-4.19 Platform-neutral API for system level and libc like functions nss-3.38 Libraries to support development of security-enabled applications nvidia-driver-340-340.107 NVidia graphics card binary drivers for hardware OpenGL rendering opencv-core-3.4.1_2 Open Source Computer Vision library openjpeg-2.3.0_1 Open-source JPEG 2000 codec opus-1.2.1 IETF audio codec orc-0.4.25 Library and toolset to operate arrays of data p11-kit-0.23.13 Library for loading and enumerating of PKCS#11 modules p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication p5-CGI-4.40 Handle Common Gateway Interface requests and responses p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest Algorithms p5-Error-0.17026 Error/exception handling in object-oriented programming style p5-GSSAPI-0.28_1 Perl extension providing access to the GSSAPIv2 library p5-HTML-Parser-3.72 Perl5 module for parsing HTML documents p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML pango-1.42.0 Open-source framework for the layout and rendering of i18n text pciids-20180812 Database of all known IDs used in PCI devices pcre-8.42 Perl Compatible Regular Expressions library pcre2-10.31 Perl Compatible Regular Expressions library, version 2 perl5-5.26.2 Practical Extraction and Report Language phonon-qt5-4.10.1 KDE multimedia framework pinentry-1.1.0_1 Collection of simple PIN or passphrase entry dialogs pinentry-tty-1.1.0 Console version of the GnuPG password dialog pixman-0.34.0 Low-level pixel manipulation library pkg-1.10.5_1 Package manager pkgconf-1.4.2,1 Utility to help to configure compiler and linker flags plasma5-breeze-5.12.5_1 Plasma5 artwork, styles and assets for the Breeze visual style plasma5-drkonqi-5.12.5 Plasma5 crash handler plasma5-kactivitymanagerd-5.12.5_1 System service to manage user's activities, track the usage patterns plasma5-kde-cli-tools-5.12.5_1 Plasma5 non-interactive system tools plasma5-kdecoration-5.12.5_1 Plasma5 library to create window decorations plasma5-khotkeys-5.12.5_1 Plasma5 library for hotkeys plasma5-kinfocenter-5.12.5_1 Plasma5 utility providing system information plasma5-kmenuedit-5.12.5_1 Plasma5 menu editor plasma5-kscreenlocker-5.12.5_1 Plasma5 secure lock screen architecture plasma5-ksysguard-5.12.5_1 Plasma5 utility to track and control the running processes plasma5-kwin-5.12.5_1 Plasma5 window manager plasma5-libkscreen-5.12.5_1 Plasma5 screen management library plasma5-libksysguard-5.12.5_1 Plasma5 library to track and control running processes plasma5-milou-5.12.5_1 Plasma5 Plasmoid for search plasma5-plasma-desktop-5.12.5_3 Plasma5 plasma desktop plasma5-plasma-integration-5.12.5_1 Qt Platform Theme integration plugins for the Plasma workspaces plasma5-plasma-workspace-5.12.5_3 Plasma5 Plasma workspace plasma5-polkit-kde-agent-1-5.12.5_1 Plasma5 daemon providing a polkit authentication UI plasma5-systemsettings-5.12.5_1 Plasma5 system settings png-1.6.34 Library for manipulating PNG images policykit-0.9_10 Framework for controlling access to system-wide components polkit-0.114_1 Framework for controlling access to system-wide components polkit-qt5-0.112.0_1 Qt5 wrapper around Polkit libraries poppler-0.57.0_1 PDF rendering library poppler-data-0.4.9 Poppler encoding data poppler-qt5-0.57.0_1 Qt 5 bindings to poppler powerdxx-0.3.0 CPU clock speed/frequency daemon py36-mypy-0.620_1 Optional static typing for Python py36-psutil-5.4.7 Process utilities module for Python py36-setuptools-40.0.0 Python packages installer py36-typed-ast-1.1.0 Fast version of Python's ast module with support for PEP484 typed comments py37-setuptools-40.0.0 Python packages installer python27-2.7.15 Interpreted object-oriented programming language python36-3.6.6_1 Interpreted object-oriented programming language python37-3.7.0_2 Interpreted object-oriented programming language qt5-assistant-5.10.1 Qt 5 documentation browser qt5-concurrent-5.10.1 Qt multi-threading module qt5-core-5.10.1_3 Qt core non-graphical module qt5-dbus-5.10.1 Qt D-Bus inter-process communication module qt5-designer-5.10.1 Qt 5 graphical user interface designer qt5-graphicaleffects-5.10.1 Qt Quick graphical effects qt5-gui-5.10.1 Qt graphical user interface module qt5-help-5.10.1 Qt online help integration module qt5-linguisttools-5.10.1 Qt localization tools qt5-location-5.10.1 Qt location module qt5-multimedia-5.10.1 Qt audio, video, radio and camera support module qt5-network-5.10.1 Qt network module qt5-opengl-5.10.1 Qt 5-compatible OpenGL support module qt5-printsupport-5.10.1 Qt print support module qt5-qdbus-5.10.1 Qt command-line interface to D-Bus qt5-qml-5.10.1_1 Qt QML and JavaScript language module qt5-qtpaths-5.10.1 Command line client to QStandardPaths qt5-quick-5.10.1 Qt declarative framework for dynamic user interfaces qt5-quickcontrols-5.10.1 Set of controls for building complete interfaces in Qt Quick qt5-quickcontrols2-5.10.1 Set of controls for building complete interfaces in Qt Quick qt5-script-5.10.1 Qt 4-compatible scripting module qt5-sensors-5.10.1 Qt sensors module qt5-sql-5.10.1 Qt SQL database integration module qt5-sqldrivers-sqlite3-5.10.1 Qt SQLite 3 database plugin qt5-svg-5.10.1 Qt SVG support module qt5-testlib-5.10.1 Qt unit testing module qt5-uiplugin-5.10.1 Custom Qt widget plugin interface for Qt Designer qt5-uitools-5.10.1 Qt Designer UI forms support module qt5-virtualkeyboard-5.10.1 Qt 5 Virtual Keyboard Module qt5-webchannel-5.10.1 Qt 5 library for integration of C++/QML with HTML/js clients qt5-webkit-5.212.0.a2_10 QtWebKit with a more modern WebKit code base qt5-widgets-5.10.1 Qt C++ widgets module qt5-x11extras-5.10.1 Qt platform-specific features for X11-based systems qt5-xml-5.10.1 Qt SAX and DOM implementations qt5-xmlpatterns-5.10.1 Qt support for XPath, XQuery, XSLT and XML Schema qtchooser-39 Qt tool wrapper readline-7.0.3_1 Library for editing command lines as they are typed rhash-1.3.5 Utility and library for computing and checking of file hashes rxvt-unicode-9.22 Clone of the terminal emulator rxvt modified to support Unicode sdocbook-xml-1.1_2,2 "Simplified" DocBook XML DTD serf-1.3.9_3 Serf HTTP client library shared-mime-info-1.8 MIME types database from the freedesktop.org project spidermonkey52-52.8.0_1 Standalone JavaScript based from Mozilla 52-esr sqlite3-3.24.0_1 SQL database engine in a C library startup-notification-0.12_4 Library that supports startup notification spec from freedesktop.org subversion-1.10.2 Version control system taglib-1.11.1_1 Library for manipulating ID3 tags and Ogg comments tiff-4.0.9_1 Tools and library routines for working with TIFF images tmux-2.7 Terminal Multiplexer tpm-emulator-0.7.4_2 Trusted Platform Module (TPM) emulator trousers-0.3.14_2 Open-source TCG Software Stack utf8proc-2.1.0 UTF-8 processing library v4l_compat-1.6.3_1 Video4Linux IOCTL header files vim-console-8.1.0231 Improved version of the vi editor (console only) wayland-1.14.0 Wayland composite "server" webcamd-4.17.0.3 Port of Linux USB webcam and DVB drivers into userspace webp-1.0.0_1 Google WebP image format conversion tool x265-2.8_1 H.265/High Efficiency Video Coding (HEVC) format xauth-1.0.10 X authority file utility xbitmaps-1.1.2 X.Org bitmaps data xcb-util-0.4.0_2,1 Module with libxcb/libX11 extension/replacement libraries xcb-util-cursor-0.1.3 XCB cursor library xcb-util-image-0.4.0_1 Port of Xlib's XImage and XShmImage functions xcb-util-keysyms-0.4.0_1 Standard X key constants and conversion to/from keycodes xcb-util-renderutil-0.3.9_1 Convenience functions for the Render extension xcb-util-wm-0.4.1_3 Framework for window manager implementation xdg-utils-1.1.1 Tools to allow all applications to integrate with the free desktop xf86-input-evdev-2.10.6_1 X.Org event device input driver xf86-input-keyboard-1.9.0_2 X.Org keyboard input driver xf86-input-libinput-0.25.0_1 X.Org libinput input driver xf86-input-mouse-1.9.3_1 X.Org mouse input driver xf86-input-synaptics-1.9.1_1 X.Org synaptics input driver xf86-video-vesa-2.4.0_1 X.Org vesa display driver xinit-1.4.0,1 X Window System initializer xkbcomp-1.4.2 Compile XKB keyboard description xkeyboard-config-2.24 X Keyboard Configuration Database xmessage-1.0.5 Display message or query in a X window xmlcatmgr-2.2_2 SGML and XML catalog manager xmlcharent-0.3_2 XML character entities xorg-fonts-truetype-7.7_1 X.Org TrueType fonts xorg-minimal-7.5.2_2 X.Org minimal distribution metaport xorg-server-1.18.4_9,1 X.Org X server and related programs xorgproto-2018.4 xorg protocol headers xprop-1.2.3 Property displayer for X xrandr-1.5.0 Primitive command line interface to the RandR extension xset-1.2.4_1 User preference utility for X xsetroot-1.1.2 Root window parameter setting utility for X xvid-1.3.5,1 Opensource MPEG-4 codec, based on OpenDivx xwayland-1.19.1_9,1 X Clients under Wayland === Xorg.log [ 972.289] X.Org X Server 1.18.4 Release Date: 2016-07-19 [ 972.289] X Protocol Version 11, Revision 0 [ 972.289] Build Operating System: FreeBSD 12.0-ALPHA2 amd64 [ 972.289] Current Operating System: FreeBSD nachtschatten.purplekraken.com 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #2 r338043: Sun Aug 19 21:31:15 CEST 2018 root@nachtschatten.purplekraken.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 [ 972.290] Build Date: 18 August 2018 03:51:14PM [ 972.290] [ 972.290] Current version of pixman: 0.34.0 [ 972.290] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 972.290] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 972.290] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Aug 22 21:32:53 2018 [ 972.293] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d" [ 972.293] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d" [ 972.295] (==) No Layout section. Using the first Screen section. [ 972.295] (==) No screen section available. Using defaults. [ 972.295] (**) |-->Screen "Default Screen Section" (0) [ 972.295] (**) | |-->Monitor "" [ 972.295] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 972.295] (==) Automatically adding devices [ 972.295] (==) Automatically enabling devices [ 972.295] (==) Not automatically adding GPU devices [ 972.297] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 972.297] (WW) The directory "/usr/local/share/fonts/Caladea" does not exist. [ 972.297] Entry deleted from font path. [ 972.297] (WW) The directory "/usr/local/share/fonts/Carlito" does not exist. [ 972.297] Entry deleted from font path. [ 972.297] (WW) The directory "/usr/local/share/fonts/ChromeOS" does not exist. [ 972.297] Entry deleted from font path. [ 972.298] (WW) The directory "/usr/local/share/fonts/Droid" does not exist. [ 972.298] Entry deleted from font path. [ 972.298] (WW) The directory "/usr/local/share/fonts/GentiumBasic" does not exist. [ 972.298] Entry deleted from font path. [ 972.298] (WW) The directory "/usr/local/share/fonts/Liberation" does not exist. [ 972.298] Entry deleted from font path. [ 972.298] (WW) The directory "/usr/local/share/fonts/LinLibertineG" does not exist. [ 972.298] Entry deleted from font path. [ 972.299] (WW) The directory "/usr/local/share/fonts/noto" does not exist. [ 972.299] Entry deleted from font path. [ 972.299] (WW) The directory "/usr/local/share/fonts/roboto-fonts-ttf" does not exist. [ 972.299] Entry deleted from font path. [ 972.299] (WW) The directory "/usr/local/share/fonts/terminus-font" does not exist. [ 972.299] Entry deleted from font path. [ 972.299] (WW) The directory "/usr/local/share/fonts/misc/" does not exist. [ 972.299] Entry deleted from font path. [ 972.305] (WW) The directory "/usr/local/share/fonts/Type1/" does not exist. [ 972.305] Entry deleted from font path. [ 972.305] (WW) The directory "/usr/local/share/fonts/100dpi/" does not exist. [ 972.305] Entry deleted from font path. [ 972.305] (WW) The directory "/usr/local/share/fonts/75dpi/" does not exist. [ 972.305] Entry deleted from font path. [ 972.305] (**) FontPath set to: /usr/local/share/fonts/dejavu, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/ [ 972.305] (==) ModulePath set to "/usr/local/lib/xorg/modules" [ 972.305] (II) The server relies on devd to provide the list of input devices. If no devices become available, reconfigure devd or disable AutoAddDevices. [ 972.305] (II) Loader magic: 0x413020 [ 972.305] (II) Module ABI versions: [ 972.305] X.Org ANSI C Emulation: 0.4 [ 972.305] X.Org Video Driver: 20.0 [ 972.305] X.Org XInput driver : 22.1 [ 972.305] X.Org Server Extension : 9.0 [ 972.306] (--) PCI:*(0:1:0:0) 10de:0a6c:17aa:21d4 rev 162, Mem @ 0xcc000000/16777216, 0xd0000000/268435456, 0xce000000/33554432, I/O @ 0x00002000/128, BIOS @ 0x????????/65536 [ 972.306] (II) LoadModule: "glx" [ 972.307] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so [ 972.503] (II) Module glx: vendor="NVIDIA Corporation" [ 972.503] compiled for 4.0.2, module version = 1.0.0 [ 972.503] Module class: X.Org Server Extension [ 972.503] (II) NVIDIA GLX Module 340.107 Thu May 24 21:25:00 PDT 2018 [ 972.504] (==) Matched nv as autoconfigured driver 0 [ 972.505] (==) Matched modesetting as autoconfigured driver 1 [ 972.505] (==) Matched scfb as autoconfigured driver 2 [ 972.505] (==) Matched vesa as autoconfigured driver 3 [ 972.505] (==) Assigned the driver to the xf86ConfigLayout [ 972.505] (II) LoadModule: "nv" [ 972.507] (WW) Warning, couldn't open module nv [ 972.507] (II) UnloadModule: "nv" [ 972.507] (II) Unloading nv [ 972.507] (EE) Failed to load module "nv" (module does not exist, 0) [ 972.507] (II) LoadModule: "modesetting" [ 972.507] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so [ 972.508] (II) Module modesetting: vendor="X.Org Foundation" [ 972.508] compiled for 1.18.4, module version = 1.18.4 [ 972.508] Module class: X.Org Video Driver [ 972.508] ABI class: X.Org Video Driver, version 20.0 [ 972.509] (II) LoadModule: "scfb" [ 972.509] (WW) Warning, couldn't open module scfb [ 972.510] (II) UnloadModule: "scfb" [ 972.510] (II) Unloading scfb [ 972.510] (EE) Failed to load module "scfb" (module does not exist, 0) [ 972.510] (II) LoadModule: "vesa" [ 972.510] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so [ 972.511] (II) Module vesa: vendor="X.Org Foundation" [ 972.511] compiled for 1.18.4, module version = 2.4.0 [ 972.511] Module class: X.Org Video Driver [ 972.511] ABI class: X.Org Video Driver, version 20.0 [ 972.511] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 972.511] (II) VESA: driver for VESA chipsets: vesa [ 972.511] (--) Using syscons driver with X support (version 2.0) [ 972.512] (--) using VT number 9 [ 972.521] (EE) open /dev/dri/card0: No such file or directory [ 972.521] (WW) Falling back to old probe method for modesetting [ 972.521] (EE) open /dev/dri/card0: No such file or directory [ 972.521] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 972.521] (EE) Screen 0 deleted because of no matching config section. [ 972.521] (II) UnloadModule: "modesetting" [ 972.522] (II) Loading sub module "vbe" [ 972.522] (II) LoadModule: "vbe" [ 972.522] (II) Loading /usr/local/lib/xorg/modules/libvbe.so [ 972.523] (II) Module vbe: vendor="X.Org Foundation" [ 972.523] compiled for 1.18.4, module version = 1.1.0 [ 972.523] ABI class: X.Org Video Driver, version 20.0 [ 972.523] (II) Loading sub module "int10" [ 972.523] (II) LoadModule: "int10" [ 972.523] (II) Loading /usr/local/lib/xorg/modules/libint10.so [ 972.526] (II) Module int10: vendor="X.Org Foundation" [ 972.526] compiled for 1.18.4, module version = 1.0.0 [ 972.526] ABI class: X.Org Video Driver, version 20.0 [ 972.526] (II) VESA(0): initializing int10 [ 972.527] (II) VESA(0): Bad V_BIOS checksum [ 972.527] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 972.625] (II) VESA(0): VESA BIOS detected [ 972.625] (II) VESA(0): VESA VBE Version 3.0 [ 972.625] (II) VESA(0): VESA VBE Total Mem: 14336 kB [ 972.625] (II) VESA(0): VESA VBE OEM: NVIDIA [ 972.625] (II) VESA(0): VESA VBE OEM Software Rev: 112.24 [ 972.625] (II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation [ 972.625] (II) VESA(0): VESA VBE OEM Product: NVIDIA Quadro NVS170M [ 972.625] (II) VESA(0): VESA VBE OEM Product Rev: Chip Rev [ 972.806] (II) VESA(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 972.806] (==) VESA(0): Depth 24, (--) framebuffer bpp 32 [ 972.806] (==) VESA(0): RGB weight 888 [ 972.806] (==) VESA(0): Default visual is TrueColor [ 972.806] (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0) [ 972.806] (II) Loading sub module "ddc" [ 972.806] (II) LoadModule: "ddc" [ 972.806] (II) Module "ddc" already built-in [ 972.808] (II) VESA(0): VESA VBE DDC supported [ 972.808] (II) VESA(0): VESA VBE DDC Level 2 [ 972.808] (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec. [ 972.873] (II) VESA(0): VESA VBE DDC read successfully [ 972.873] (II) VESA(0): Manufacturer: AVA Model: 225a Serial#: 4559 [ 972.873] (II) VESA(0): Year: 2007 Week: 39 [ 972.873] (II) VESA(0): EDID Version: 1.3 [ 972.873] (II) VESA(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V [ 972.873] (II) VESA(0): Sync: Separate [ 972.873] (II) VESA(0): Max Image Size [cm]: horiz.: 47 vert.: 30 [ 972.873] (II) VESA(0): Gamma: 2.20 [ 972.873] (II) VESA(0): DPMS capabilities: Off; RGB/Color Display [ 972.874] (II) VESA(0): First detailed timing is preferred mode [ 972.874] (II) VESA(0): redX: 0.644 redY: 0.332 greenX: 0.285 greenY: 0.604 [ 972.874] (II) VESA(0): blueX: 0.151 blueY: 0.075 whiteX: 0.312 whiteY: 0.328 [ 972.874] (II) VESA(0): Supported established timings: [ 972.874] (II) VESA(0): 720x400@70Hz [ 972.874] (II) VESA(0): 640x480@60Hz [ 972.874] (II) VESA(0): 640x480@67Hz [ 972.874] (II) VESA(0): 640x480@72Hz [ 972.874] (II) VESA(0): 640x480@75Hz [ 972.874] (II) VESA(0): 800x600@56Hz [ 972.874] (II) VESA(0): 800x600@60Hz [ 972.874] (II) VESA(0): 800x600@72Hz [ 972.874] (II) VESA(0): 800x600@75Hz [ 972.874] (II) VESA(0): 832x624@75Hz [ 972.874] (II) VESA(0): 1024x768@60Hz [ 972.874] (II) VESA(0): 1024x768@70Hz [ 972.874] (II) VESA(0): 1024x768@75Hz [ 972.874] (II) VESA(0): 1280x1024@75Hz [ 972.874] (II) VESA(0): Manufacturer's mask: 0 [ 972.874] (II) VESA(0): Supported standard timings: [ 972.874] (II) VESA(0): #0: hsize: 1024 vsize 768 refresh: 72 vid: 19553 [ 972.874] (II) VESA(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [ 972.874] (II) VESA(0): #2: hsize: 1280 vsize 1024 refresh: 70 vid: 35457 [ 972.875] (II) VESA(0): #3: hsize: 1280 vsize 1024 refresh: 72 vid: 35969 [ 972.875] (II) VESA(0): #4: hsize: 1280 vsize 960 refresh: 60 vid: 16513 [ 972.875] (II) VESA(0): #5: hsize: 1680 vsize 1050 refresh: 60 vid: 179 [ 972.875] (II) VESA(0): Supported detailed timing: [ 972.875] (II) VESA(0): clock: 146.0 MHz Image Size: 470 x 300 mm [ 972.875] (II) VESA(0): h_active: 1680 h_sync: 1784 h_sync_end 1960 h_blank_end 2240 h_border: 0 [ 972.875] (II) VESA(0): v_active: 1050 v_sync: 1053 v_sync_end 1059 v_blanking: 1089 v_border: 0 [ 972.875] (II) VESA(0): Ranges: V min: 56 V max: 75 Hz, H min: 31 H max: 80 kHz, PixClock max 175 MHz [ 972.875] (II) VESA(0): Monitor name: 225WT [ 972.875] (II) VESA(0): Serial No: E4279JA004559 [ 972.875] (II) VESA(0): EDID (in hex): [ 972.875] (II) VESA(0): 00ffffffffffff0006c15a22cf110000 [ 972.875] (II) VESA(0): 27110103682f1e782ac3d0a455499a26 [ 972.875] (II) VESA(0): 135054bfef00614c8180818a818c8140 [ 972.875] (II) VESA(0): b3000101010108399030621a274068b0 [ 972.875] (II) VESA(0): 3600d62c1100001c000000fd00384b1f [ 972.875] (II) VESA(0): 5011000a202020202020000000fc0032 [ 972.875] (II) VESA(0): 323557540a20202020202020000000ff [ 972.875] (II) VESA(0): 0045343237394a4130303435353900e7 [ 972.875] (II) VESA(0): EDID vendor "AVA", prod id 8794 [ 972.876] (II) VESA(0): Using EDID range info for horizontal sync [ 972.876] (II) VESA(0): Using EDID range info for vertical refresh [ 972.876] (II) VESA(0): Printing DDC gathered Modelines: [ 972.876] (II) VESA(0): Modeline "1680x1050"x0.0 146.00 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.2 kHz eP) [ 972.876] (II) VESA(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 972.876] (II) VESA(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 972.876] (II) VESA(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 972.876] (II) VESA(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 972.876] (II) VESA(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 972.876] (II) VESA(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 972.876] (II) VESA(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 972.876] (II) VESA(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 972.876] (II) VESA(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 972.876] (II) VESA(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 972.876] (II) VESA(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 972.876] (II) VESA(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 972.876] (II) VESA(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 972.877] (II) VESA(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 972.877] (II) VESA(0): Modeline "1024x768"x72.0 78.43 1024 1080 1192 1360 768 769 772 801 -hsync +vsync (57.7 kHz e) [ 972.877] (II) VESA(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 972.877] (II) VESA(0): Modeline "1280x1024"x70.0 128.94 1280 1368 1504 1728 1024 1025 1028 1066 -hsync +vsync (74.6 kHz e) [ 972.877] (II) VESA(0): Modeline "1280x1024"x72.0 132.75 1280 1368 1504 1728 1024 1025 1028 1067 -hsync +vsync (76.8 kHz e) [ 972.877] (II) VESA(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 972.877] (II) VESA(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz e) [ 972.877] (II) VESA(0): Searching for matching VESA mode(s): [ 972.880] Mode: 100 (640x400) [ 972.880] ModeAttributes: 0x3bf [ 972.880] WinAAttributes: 0x7 [ 972.880] WinBAttributes: 0x0 [ 972.880] WinGranularity: 64 [ 972.880] WinSize: 64 [ 972.880] WinASegment: 0xa000 [ 972.880] WinBSegment: 0x0 [ 972.880] WinFuncPtr: 0xc0007e63 [ 972.880] BytesPerScanline: 640 [ 972.880] XResolution: 640 [ 972.881] YResolution: 400 [ 972.881] XCharSize: 8 [ 972.881] YCharSize: 16 [ 972.881] NumberOfPlanes: 1 [ 972.881] BitsPerPixel: 8 [ 972.881] NumberOfBanks: 1 [ 972.881] MemoryModel: 4 [ 972.881] BankSize: 0 [ 972.881] NumberOfImages: 14 [ 972.881] RedMaskSize: 0 [ 972.881] RedFieldPosition: 0 [ 972.881] GreenMaskSize: 0 [ 972.881] GreenFieldPosition: 0 [ 972.881] BlueMaskSize: 0 [ 972.881] BlueFieldPosition: 0 [ 972.881] RsvdMaskSize: 0 [ 972.881] RsvdFieldPosition: 0 [ 972.881] DirectColorModeInfo: 0 [ 972.881] PhysBasePtr: 0xcf000000 [ 972.881] LinBytesPerScanLine: 640 [ 972.881] BnkNumberOfImagePages: 14 [ 972.881] LinNumberOfImagePages: 14 [ 972.881] LinRedMaskSize: 0 [ 972.881] LinRedFieldPosition: 0 [ 972.881] LinGreenMaskSize: 0 [ 972.882] LinGreenFieldPosition: 0 [ 972.882] LinBlueMaskSize: 0 [ 972.882] LinBlueFieldPosition: 0 [ 972.882] LinRsvdMaskSize: 0 [ 972.882] LinRsvdFieldPosition: 0 [ 972.882] MaxPixelClock: 229500000 [ 972.885] Mode: 101 (640x480) [ 972.885] ModeAttributes: 0x3bf [ 972.885] WinAAttributes: 0x7 [ 972.885] WinBAttributes: 0x0 [ 972.885] WinGranularity: 64 [ 972.885] WinSize: 64 [ 972.885] WinASegment: 0xa000 [ 972.885] WinBSegment: 0x0 [ 972.885] WinFuncPtr: 0xc0007e63 [ 972.885] BytesPerScanline: 640 [ 972.885] XResolution: 640 [ 972.885] YResolution: 480 [ 972.885] XCharSize: 8 [ 972.885] YCharSize: 16 [ 972.885] NumberOfPlanes: 1 [ 972.886] BitsPerPixel: 8 [ 972.886] NumberOfBanks: 1 [ 972.886] MemoryModel: 4 [ 972.886] BankSize: 0 [ 972.886] NumberOfImages: 10 [ 972.886] RedMaskSize: 0 [ 972.886] RedFieldPosition: 0 [ 972.886] GreenMaskSize: 0 [ 972.886] GreenFieldPosition: 0 [ 972.886] BlueMaskSize: 0 [ 972.886] BlueFieldPosition: 0 [ 972.886] RsvdMaskSize: 0 [ 972.886] RsvdFieldPosition: 0 [ 972.886] DirectColorModeInfo: 0 [ 972.886] PhysBasePtr: 0xcf000000 [ 972.886] LinBytesPerScanLine: 640 [ 972.886] BnkNumberOfImagePages: 10 [ 972.886] LinNumberOfImagePages: 10 [ 972.886] LinRedMaskSize: 0 [ 972.886] LinRedFieldPosition: 0 [ 972.886] LinGreenMaskSize: 0 [ 972.886] LinGreenFieldPosition: 0 [ 972.886] LinBlueMaskSize: 0 [ 972.886] LinBlueFieldPosition: 0 [ 972.886] LinRsvdMaskSize: 0 [ 972.887] LinRsvdFieldPosition: 0 [ 972.887] MaxPixelClock: 229500000 [ 972.890] Mode: 102 (800x600) [ 972.890] ModeAttributes: 0x33f [ 972.890] WinAAttributes: 0x7 [ 972.890] WinBAttributes: 0x0 [ 972.890] WinGranularity: 64 [ 972.890] WinSize: 64 [ 972.890] WinASegment: 0xa000 [ 972.890] WinBSegment: 0x0 [ 972.890] WinFuncPtr: 0xc0007e63 [ 972.890] BytesPerScanline: 100 [ 972.890] XResolution: 800 [ 972.890] YResolution: 600 [ 972.890] XCharSize: 8 [ 972.890] YCharSize: 16 [ 972.890] NumberOfPlanes: 4 [ 972.890] BitsPerPixel: 4 [ 972.890] NumberOfBanks: 1 [ 972.890] MemoryModel: 3 [ 972.890] BankSize: 0 [ 972.890] NumberOfImages: 2 [ 972.890] RedMaskSize: 0 [ 972.890] RedFieldPosition: 0 [ 972.891] GreenMaskSize: 0 [ 972.891] GreenFieldPosition: 0 [ 972.891] BlueMaskSize: 0 [ 972.891] BlueFieldPosition: 0 [ 972.891] RsvdMaskSize: 0 [ 972.891] RsvdFieldPosition: 0 [ 972.891] DirectColorModeInfo: 0 [ 972.891] PhysBasePtr: 0x0 [ 972.891] LinBytesPerScanLine: 100 [ 972.891] BnkNumberOfImagePages: 2 [ 972.891] LinNumberOfImagePages: 2 [ 972.891] LinRedMaskSize: 0 [ 972.891] LinRedFieldPosition: 0 [ 972.891] LinGreenMaskSize: 0 [ 972.891] LinGreenFieldPosition: 0 [ 972.891] LinBlueMaskSize: 0 [ 972.891] LinBlueFieldPosition: 0 [ 972.891] LinRsvdMaskSize: 0 [ 972.891] LinRsvdFieldPosition: 0 [ 972.891] MaxPixelClock: 108500000 [ 972.894] Mode: 103 (800x600) [ 972.894] ModeAttributes: 0x3bf [ 972.894] WinAAttributes: 0x7 [ 972.895] WinBAttributes: 0x0 [ 972.895] WinGranularity: 64 [ 972.895] WinSize: 64 [ 972.895] WinASegment: 0xa000 [ 972.895] WinBSegment: 0x0 [ 972.895] WinFuncPtr: 0xc0007e63 [ 972.895] BytesPerScanline: 800 [ 972.895] XResolution: 800 [ 972.895] YResolution: 600 [ 972.895] XCharSize: 8 [ 972.895] YCharSize: 16 [ 972.895] NumberOfPlanes: 1 [ 972.895] BitsPerPixel: 8 [ 972.895] NumberOfBanks: 1 [ 972.895] MemoryModel: 4 [ 972.895] BankSize: 0 [ 972.895] NumberOfImages: 6 [ 972.895] RedMaskSize: 0 [ 972.895] RedFieldPosition: 0 [ 972.895] GreenMaskSize: 0 [ 972.895] GreenFieldPosition: 0 [ 972.895] BlueMaskSize: 0 [ 972.895] BlueFieldPosition: 0 [ 972.895] RsvdMaskSize: 0 [ 972.895] RsvdFieldPosition: 0 [ 972.895] DirectColorModeInfo: 0 [ 972.896] PhysBasePtr: 0xcf000000 [ 972.896] LinBytesPerScanLine: 800 [ 972.896] BnkNumberOfImagePages: 6 [ 972.896] LinNumberOfImagePages: 6 [ 972.896] LinRedMaskSize: 0 [ 972.896] LinRedFieldPosition: 0 [ 972.896] LinGreenMaskSize: 0 [ 972.896] LinGreenFieldPosition: 0 [ 972.896] LinBlueMaskSize: 0 [ 972.896] LinBlueFieldPosition: 0 [ 972.896] LinRsvdMaskSize: 0 [ 972.896] LinRsvdFieldPosition: 0 [ 972.896] MaxPixelClock: 229500000 [ 972.899] Mode: 104 (1024x768) [ 972.899] ModeAttributes: 0x33f [ 972.899] WinAAttributes: 0x7 [ 972.899] WinBAttributes: 0x0 [ 972.899] WinGranularity: 64 [ 972.899] WinSize: 64 [ 972.899] WinASegment: 0xa000 [ 972.899] WinBSegment: 0x0 [ 972.900] WinFuncPtr: 0xc0007e63 [ 972.900] BytesPerScanline: 128 [ 972.900] XResolution: 1024 [ 972.900] YResolution: 768 [ 972.900] XCharSize: 8 [ 972.900] YCharSize: 16 [ 972.900] NumberOfPlanes: 4 [ 972.900] BitsPerPixel: 4 [ 972.900] NumberOfBanks: 1 [ 972.900] MemoryModel: 3 [ 972.900] BankSize: 0 [ 972.900] NumberOfImages: 1 [ 972.900] RedMaskSize: 0 [ 972.900] RedFieldPosition: 0 [ 972.900] GreenMaskSize: 0 [ 972.900] GreenFieldPosition: 0 [ 972.900] BlueMaskSize: 0 [ 972.900] BlueFieldPosition: 0 [ 972.900] RsvdMaskSize: 0 [ 972.900] RsvdFieldPosition: 0 [ 972.900] DirectColorModeInfo: 0 [ 972.900] PhysBasePtr: 0x0 [ 972.900] LinBytesPerScanLine: 128 [ 972.900] BnkNumberOfImagePages: 1 [ 972.901] LinNumberOfImagePages: 1 [ 972.901] LinRedMaskSize: 0 [ 972.901] LinRedFieldPosition: 0 [ 972.901] LinGreenMaskSize: 0 [ 972.901] LinGreenFieldPosition: 0 [ 972.901] LinBlueMaskSize: 0 [ 972.901] LinBlueFieldPosition: 0 [ 972.901] LinRsvdMaskSize: 0 [ 972.901] LinRsvdFieldPosition: 0 [ 972.901] MaxPixelClock: 108500000 [ 972.904] Mode: 105 (1024x768) [ 972.904] ModeAttributes: 0x3bf [ 972.904] WinAAttributes: 0x7 [ 972.904] WinBAttributes: 0x0 [ 972.904] WinGranularity: 64 [ 972.904] WinSize: 64 [ 972.904] WinASegment: 0xa000 [ 972.904] WinBSegment: 0x0 [ 972.904] WinFuncPtr: 0xc0007e63 [ 972.904] BytesPerScanline: 1024 [ 972.904] XResolution: 1024 [ 972.904] YResolution: 768 [ 972.904] XCharSize: 8 [ 972.905] YCharSize: 16 [ 972.905] NumberOfPlanes: 1 [ 972.905] BitsPerPixel: 8 [ 972.905] NumberOfBanks: 1 [ 972.905] MemoryModel: 4 [ 972.905] BankSize: 0 [ 972.905] NumberOfImages: 3 [ 972.905] RedMaskSize: 0 [ 972.905] RedFieldPosition: 0 [ 972.905] GreenMaskSize: 0 [ 972.905] GreenFieldPosition: 0 [ 972.905] BlueMaskSize: 0 [ 972.905] BlueFieldPosition: 0 [ 972.905] RsvdMaskSize: 0 [ 972.905] RsvdFieldPosition: 0 [ 972.905] DirectColorModeInfo: 0 [ 972.905] PhysBasePtr: 0xcf000000 [ 972.905] LinBytesPerScanLine: 1024 [ 972.905] BnkNumberOfImagePages: 3 [ 972.905] LinNumberOfImagePages: 3 [ 972.905] LinRedMaskSize: 0 [ 972.905] LinRedFieldPosition: 0 [ 972.905] LinGreenMaskSize: 0 [ 972.905] LinGreenFieldPosition: 0 [ 972.905] LinBlueMaskSize: 0 [ 972.905] LinBlueFieldPosition: 0 [ 972.906] LinRsvdMaskSize: 0 [ 972.906] LinRsvdFieldPosition: 0 [ 972.906] MaxPixelClock: 229500000 [ 972.909] Mode: 10e (320x200) [ 972.909] ModeAttributes: 0x3bf [ 972.909] WinAAttributes: 0x7 [ 972.909] WinBAttributes: 0x0 [ 972.909] WinGranularity: 64 [ 972.909] WinSize: 64 [ 972.909] WinASegment: 0xa000 [ 972.909] WinBSegment: 0x0 [ 972.909] WinFuncPtr: 0xc0007e63 [ 972.909] BytesPerScanline: 640 [ 972.909] XResolution: 320 [ 972.909] YResolution: 200 [ 972.909] XCharSize: 8 [ 972.909] YCharSize: 8 [ 972.909] NumberOfPlanes: 1 [ 972.909] BitsPerPixel: 16 [ 972.909] NumberOfBanks: 1 [ 972.909] MemoryModel: 6 [ 972.910] BankSize: 0 [ 972.910] NumberOfImages: 30 [ 972.910] RedMaskSize: 5 [ 972.910] RedFieldPosition: 11 [ 972.910] GreenMaskSize: 6 [ 972.910] GreenFieldPosition: 5 [ 972.910] BlueMaskSize: 5 [ 972.910] BlueFieldPosition: 0 [ 972.910] RsvdMaskSize: 0 [ 972.910] RsvdFieldPosition: 0 [ 972.910] DirectColorModeInfo: 0 [ 972.910] PhysBasePtr: 0xcf000000 [ 972.910] LinBytesPerScanLine: 640 [ 972.910] BnkNumberOfImagePages: 30 [ 972.910] LinNumberOfImagePages: 30 [ 972.910] LinRedMaskSize: 5 [ 972.910] LinRedFieldPosition: 11 [ 972.910] LinGreenMaskSize: 6 [ 972.910] LinGreenFieldPosition: 5 [ 972.910] LinBlueMaskSize: 5 [ 972.910] LinBlueFieldPosition: 0 [ 972.910] LinRsvdMaskSize: 0 [ 972.910] LinRsvdFieldPosition: 0 [ 972.910] MaxPixelClock: 229500000 [ 972.913] *Mode: 10f (320x200) [ 972.914] ModeAttributes: 0x3bf [ 972.914] WinAAttributes: 0x7 [ 972.914] WinBAttributes: 0x0 [ 972.914] WinGranularity: 64 [ 972.914] WinSize: 64 [ 972.914] WinASegment: 0xa000 [ 972.914] WinBSegment: 0x0 [ 972.914] WinFuncPtr: 0xc0007e63 [ 972.914] BytesPerScanline: 1280 [ 972.914] XResolution: 320 [ 972.914] YResolution: 200 [ 972.914] XCharSize: 8 [ 972.914] YCharSize: 8 [ 972.914] NumberOfPlanes: 1 [ 972.914] BitsPerPixel: 32 [ 972.914] NumberOfBanks: 1 [ 972.914] MemoryModel: 6 [ 972.914] BankSize: 0 [ 972.914] NumberOfImages: 14 [ 972.914] RedMaskSize: 8 [ 972.914] RedFieldPosition: 16 [ 972.914] GreenMaskSize: 8 [ 972.914] GreenFieldPosition: 8 [ 972.914] BlueMaskSize: 8 [ 972.914] BlueFieldPosition: 0 [ 972.915] RsvdMaskSize: 8 [ 972.915] RsvdFieldPosition: 24 [ 972.915] DirectColorModeInfo: 0 [ 972.915] PhysBasePtr: 0xcf000000 [ 972.915] LinBytesPerScanLine: 1280 [ 972.915] BnkNumberOfImagePages: 14 [ 972.915] LinNumberOfImagePages: 14 [ 972.915] LinRedMaskSize: 8 [ 972.915] LinRedFieldPosition: 16 [ 972.915] LinGreenMaskSize: 8 [ 972.915] LinGreenFieldPosition: 8 [ 972.915] LinBlueMaskSize: 8 [ 972.915] LinBlueFieldPosition: 0 [ 972.915] LinRsvdMaskSize: 8 [ 972.915] LinRsvdFieldPosition: 24 [ 972.915] MaxPixelClock: 229500000 [ 972.918] Mode: 111 (640x480) [ 972.918] ModeAttributes: 0x3bf [ 972.918] WinAAttributes: 0x7 [ 972.919] WinBAttributes: 0x0 [ 972.919] WinGranularity: 64 [ 972.919] WinSize: 64 [ 972.919] WinASegment: 0xa000 [ 972.919] WinBSegment: 0x0 [ 972.919] WinFuncPtr: 0xc0007e63 [ 972.919] BytesPerScanline: 1280 [ 972.919] XResolution: 640 [ 972.919] YResolution: 480 [ 972.919] XCharSize: 8 [ 972.919] YCharSize: 16 [ 972.919] NumberOfPlanes: 1 [ 972.919] BitsPerPixel: 16 [ 972.919] NumberOfBanks: 1 [ 972.919] MemoryModel: 6 [ 972.919] BankSize: 0 [ 972.919] NumberOfImages: 4 [ 972.919] RedMaskSize: 5 [ 972.919] RedFieldPosition: 11 [ 972.919] GreenMaskSize: 6 [ 972.919] GreenFieldPosition: 5 [ 972.919] BlueMaskSize: 5 [ 972.919] BlueFieldPosition: 0 [ 972.919] RsvdMaskSize: 0 [ 972.919] RsvdFieldPosition: 0 [ 972.919] DirectColorModeInfo: 0 [ 972.920] PhysBasePtr: 0xcf000000 [ 972.920] LinBytesPerScanLine: 1280 [ 972.920] BnkNumberOfImagePages: 4 [ 972.920] LinNumberOfImagePages: 4 [ 972.920] LinRedMaskSize: 5 [ 972.920] LinRedFieldPosition: 11 [ 972.920] LinGreenMaskSize: 6 [ 972.920] LinGreenFieldPosition: 5 [ 972.920] LinBlueMaskSize: 5 [ 972.920] LinBlueFieldPosition: 0 [ 972.920] LinRsvdMaskSize: 0 [ 972.920] LinRsvdFieldPosition: 0 [ 972.920] MaxPixelClock: 229500000 [ 972.923] *Mode: 112 (640x480) [ 972.923] ModeAttributes: 0x3bf [ 972.923] WinAAttributes: 0x7 [ 972.923] WinBAttributes: 0x0 [ 972.923] WinGranularity: 64 [ 972.923] WinSize: 64 [ 972.923] WinASegment: 0xa000 [ 972.923] WinBSegment: 0x0 [ 972.923] WinFuncPtr: 0xc0007e63 [ 972.923] BytesPerScanline: 2560 [ 972.923] XResolution: 640 [ 972.924] YResolution: 480 [ 972.924] XCharSize: 8 [ 972.924] YCharSize: 16 [ 972.924] NumberOfPlanes: 1 [ 972.924] BitsPerPixel: 32 [ 972.924] NumberOfBanks: 1 [ 972.924] MemoryModel: 6 [ 972.924] BankSize: 0 [ 972.924] NumberOfImages: 1 [ 972.924] RedMaskSize: 8 [ 972.924] RedFieldPosition: 16 [ 972.924] GreenMaskSize: 8 [ 972.924] GreenFieldPosition: 8 [ 972.924] BlueMaskSize: 8 [ 972.924] BlueFieldPosition: 0 [ 972.924] RsvdMaskSize: 8 [ 972.924] RsvdFieldPosition: 24 [ 972.924] DirectColorModeInfo: 0 [ 972.924] PhysBasePtr: 0xcf000000 [ 972.924] LinBytesPerScanLine: 2560 [ 972.924] BnkNumberOfImagePages: 1 [ 972.924] LinNumberOfImagePages: 1 [ 972.924] LinRedMaskSize: 8 [ 972.924] LinRedFieldPosition: 16 [ 972.924] LinGreenMaskSize: 8 [ 972.924] LinGreenFieldPosition: 8 [ 972.925] LinBlueMaskSize: 8 [ 972.925] LinBlueFieldPosition: 0 [ 972.925] LinRsvdMaskSize: 8 [ 972.925] LinRsvdFieldPosition: 24 [ 972.925] MaxPixelClock: 229500000 [ 972.928] Mode: 114 (800x600) [ 972.928] ModeAttributes: 0x3bf [ 972.928] WinAAttributes: 0x7 [ 972.928] WinBAttributes: 0x0 [ 972.928] WinGranularity: 64 [ 972.928] WinSize: 64 [ 972.928] WinASegment: 0xa000 [ 972.928] WinBSegment: 0x0 [ 972.928] WinFuncPtr: 0xc0007e63 [ 972.928] BytesPerScanline: 1600 [ 972.928] XResolution: 800 [ 972.928] YResolution: 600 [ 972.928] XCharSize: 8 [ 972.928] YCharSize: 16 [ 972.928] NumberOfPlanes: 1 [ 972.928] BitsPerPixel: 16 [ 972.929] NumberOfBanks: 1 [ 972.929] MemoryModel: 6 [ 972.929] BankSize: 0 [ 972.929] NumberOfImages: 2 [ 972.929] RedMaskSize: 5 [ 972.929] RedFieldPosition: 11 [ 972.929] GreenMaskSize: 6 [ 972.929] GreenFieldPosition: 5 [ 972.929] BlueMaskSize: 5 [ 972.929] BlueFieldPosition: 0 [ 972.929] RsvdMaskSize: 0 [ 972.929] RsvdFieldPosition: 0 [ 972.929] DirectColorModeInfo: 0 [ 972.929] PhysBasePtr: 0xcf000000 [ 972.929] LinBytesPerScanLine: 1600 [ 972.929] BnkNumberOfImagePages: 2 [ 972.929] LinNumberOfImagePages: 2 [ 972.929] LinRedMaskSize: 5 [ 972.929] LinRedFieldPosition: 11 [ 972.929] LinGreenMaskSize: 6 [ 972.929] LinGreenFieldPosition: 5 [ 972.929] LinBlueMaskSize: 5 [ 972.929] LinBlueFieldPosition: 0 [ 972.929] LinRsvdMaskSize: 0 [ 972.929] LinRsvdFieldPosition: 0 [ 972.930] MaxPixelClock: 229500000 [ 972.933] *Mode: 115 (800x600) [ 972.933] ModeAttributes: 0x3bf [ 972.933] WinAAttributes: 0x7 [ 972.933] WinBAttributes: 0x0 [ 972.933] WinGranularity: 64 [ 972.933] WinSize: 64 [ 972.933] WinASegment: 0xa000 [ 972.933] WinBSegment: 0x0 [ 972.933] WinFuncPtr: 0xc0007e63 [ 972.933] BytesPerScanline: 3200 [ 972.933] XResolution: 800 [ 972.933] YResolution: 600 [ 972.933] XCharSize: 8 [ 972.933] YCharSize: 16 [ 972.933] NumberOfPlanes: 1 [ 972.933] BitsPerPixel: 32 [ 972.933] NumberOfBanks: 1 [ 972.933] MemoryModel: 6 [ 972.933] BankSize: 0 [ 972.933] NumberOfImages: 1 [ 972.933] RedMaskSize: 8 [ 972.933] RedFieldPosition: 16 [ 972.933] GreenMaskSize: 8 [ 972.933] GreenFieldPosition: 8 [ 972.934] BlueMaskSize: 8 [ 972.934] BlueFieldPosition: 0 [ 972.934] RsvdMaskSize: 8 [ 972.934] RsvdFieldPosition: 24 [ 972.934] DirectColorModeInfo: 0 [ 972.934] PhysBasePtr: 0xcf000000 [ 972.934] LinBytesPerScanLine: 3200 [ 972.934] BnkNumberOfImagePages: 1 [ 972.934] LinNumberOfImagePages: 1 [ 972.934] LinRedMaskSize: 8 [ 972.934] LinRedFieldPosition: 16 [ 972.934] LinGreenMaskSize: 8 [ 972.934] LinGreenFieldPosition: 8 [ 972.934] LinBlueMaskSize: 8 [ 972.934] LinBlueFieldPosition: 0 [ 972.934] LinRsvdMaskSize: 8 [ 972.934] LinRsvdFieldPosition: 24 [ 972.934] MaxPixelClock: 229500000 [ 972.937] Mode: 117 (1024x768) [ 972.937] ModeAttributes: 0x3bf [ 972.937] WinAAttributes: 0x7 [ 972.937] WinBAttributes: 0x0 [ 972.938] WinGranularity: 64 [ 972.938] WinSize: 64 [ 972.938] WinASegment: 0xa000 [ 972.938] WinBSegment: 0x0 [ 972.938] WinFuncPtr: 0xc0007e63 [ 972.938] BytesPerScanline: 2048 [ 972.938] XResolution: 1024 [ 972.938] YResolution: 768 [ 972.938] XCharSize: 8 [ 972.938] YCharSize: 16 [ 972.938] NumberOfPlanes: 1 [ 972.938] BitsPerPixel: 16 [ 972.938] NumberOfBanks: 1 [ 972.938] MemoryModel: 6 [ 972.938] BankSize: 0 [ 972.938] NumberOfImages: 1 [ 972.938] RedMaskSize: 5 [ 972.938] RedFieldPosition: 11 [ 972.938] GreenMaskSize: 6 [ 972.938] GreenFieldPosition: 5 [ 972.938] BlueMaskSize: 5 [ 972.938] BlueFieldPosition: 0 [ 972.938] RsvdMaskSize: 0 [ 972.938] RsvdFieldPosition: 0 [ 972.938] DirectColorModeInfo: 0 [ 972.939] PhysBasePtr: 0xcf000000 [ 972.939] LinBytesPerScanLine: 2048 [ 972.939] BnkNumberOfImagePages: 1 [ 972.939] LinNumberOfImagePages: 1 [ 972.939] LinRedMaskSize: 5 [ 972.939] LinRedFieldPosition: 11 [ 972.939] LinGreenMaskSize: 6 [ 972.939] LinGreenFieldPosition: 5 [ 972.939] LinBlueMaskSize: 5 [ 972.939] LinBlueFieldPosition: 0 [ 972.939] LinRsvdMaskSize: 0 [ 972.939] LinRsvdFieldPosition: 0 [ 972.939] MaxPixelClock: 229500000 [ 972.942] *Mode: 118 (1024x768) [ 972.942] ModeAttributes: 0x3bf [ 972.942] WinAAttributes: 0x7 [ 972.942] WinBAttributes: 0x0 [ 972.942] WinGranularity: 64 [ 972.942] WinSize: 64 [ 972.942] WinASegment: 0xa000 [ 972.942] WinBSegment: 0x0 [ 972.942] WinFuncPtr: 0xc0007e63 [ 972.942] BytesPerScanline: 4096 [ 972.943] XResolution: 1024 [ 972.943] YResolution: 768 [ 972.943] XCharSize: 8 [ 972.943] YCharSize: 16 [ 972.943] NumberOfPlanes: 1 [ 972.943] BitsPerPixel: 32 [ 972.943] NumberOfBanks: 1 [ 972.943] MemoryModel: 6 [ 972.943] BankSize: 0 [ 972.943] NumberOfImages: 1 [ 972.943] RedMaskSize: 8 [ 972.943] RedFieldPosition: 16 [ 972.943] GreenMaskSize: 8 [ 972.943] GreenFieldPosition: 8 [ 972.943] BlueMaskSize: 8 [ 972.943] BlueFieldPosition: 0 [ 972.943] RsvdMaskSize: 8 [ 972.943] RsvdFieldPosition: 24 [ 972.943] DirectColorModeInfo: 0 [ 972.943] PhysBasePtr: 0xcf000000 [ 972.943] LinBytesPerScanLine: 4096 [ 972.943] BnkNumberOfImagePages: 1 [ 972.943] LinNumberOfImagePages: 1 [ 972.943] LinRedMaskSize: 8 [ 972.943] LinRedFieldPosition: 16 [ 972.943] LinGreenMaskSize: 8 [ 972.944] LinGreenFieldPosition: 8 [ 972.944] LinBlueMaskSize: 8 [ 972.944] LinBlueFieldPosition: 0 [ 972.944] LinRsvdMaskSize: 8 [ 972.944] LinRsvdFieldPosition: 24 [ 972.944] MaxPixelClock: 229500000 [ 972.947] Mode: 130 (320x200) [ 972.947] ModeAttributes: 0x3bf [ 972.947] WinAAttributes: 0x7 [ 972.947] WinBAttributes: 0x0 [ 972.947] WinGranularity: 64 [ 972.947] WinSize: 64 [ 972.947] WinASegment: 0xa000 [ 972.947] WinBSegment: 0x0 [ 972.947] WinFuncPtr: 0xc0007e63 [ 972.947] BytesPerScanline: 320 [ 972.947] XResolution: 320 [ 972.947] YResolution: 200 [ 972.947] XCharSize: 8 [ 972.947] YCharSize: 8 [ 972.947] NumberOfPlanes: 1 [ 972.947] BitsPerPixel: 8 [ 972.947] NumberOfBanks: 1 [ 972.947] MemoryModel: 4 [ 972.947] BankSize: 0 [ 972.948] NumberOfImages: 62 [ 972.948] RedMaskSize: 0 [ 972.948] RedFieldPosition: 0 [ 972.948] GreenMaskSize: 0 [ 972.948] GreenFieldPosition: 0 [ 972.948] BlueMaskSize: 0 [ 972.948] BlueFieldPosition: 0 [ 972.948] RsvdMaskSize: 0 [ 972.948] RsvdFieldPosition: 0 [ 972.948] DirectColorModeInfo: 0 [ 972.948] PhysBasePtr: 0xcf000000 [ 972.948] LinBytesPerScanLine: 320 [ 972.948] BnkNumberOfImagePages: 62 [ 972.948] LinNumberOfImagePages: 62 [ 972.948] LinRedMaskSize: 0 [ 972.948] LinRedFieldPosition: 0 [ 972.948] LinGreenMaskSize: 0 [ 972.948] LinGreenFieldPosition: 0 [ 972.948] LinBlueMaskSize: 0 [ 972.948] LinBlueFieldPosition: 0 [ 972.948] LinRsvdMaskSize: 0 [ 972.948] LinRsvdFieldPosition: 0 [ 972.948] MaxPixelClock: 229500000 [ 972.951] Mode: 131 (320x400) [ 972.952] ModeAttributes: 0x3bf [ 972.952] WinAAttributes: 0x7 [ 972.952] WinBAttributes: 0x0 [ 972.952] WinGranularity: 64 [ 972.952] WinSize: 64 [ 972.952] WinASegment: 0xa000 [ 972.952] WinBSegment: 0x0 [ 972.952] WinFuncPtr: 0xc0007e63 [ 972.952] BytesPerScanline: 320 [ 972.952] XResolution: 320 [ 972.952] YResolution: 400 [ 972.952] XCharSize: 8 [ 972.952] YCharSize: 16 [ 972.952] NumberOfPlanes: 1 [ 972.952] BitsPerPixel: 8 [ 972.952] NumberOfBanks: 1 [ 972.952] MemoryModel: 4 [ 972.952] BankSize: 0 [ 972.952] NumberOfImages: 30 [ 972.952] RedMaskSize: 0 [ 972.952] RedFieldPosition: 0 [ 972.952] GreenMaskSize: 0 [ 972.952] GreenFieldPosition: 0 [ 972.952] BlueMaskSize: 0 [ 972.952] BlueFieldPosition: 0 [ 972.953] RsvdMaskSize: 0 [ 972.953] RsvdFieldPosition: 0 [ 972.953] DirectColorModeInfo: 0 [ 972.953] PhysBasePtr: 0xcf000000 [ 972.953] LinBytesPerScanLine: 320 [ 972.953] BnkNumberOfImagePages: 30 [ 972.953] LinNumberOfImagePages: 30 [ 972.953] LinRedMaskSize: 0 [ 972.953] LinRedFieldPosition: 0 [ 972.953] LinGreenMaskSize: 0 [ 972.953] LinGreenFieldPosition: 0 [ 972.953] LinBlueMaskSize: 0 [ 972.953] LinBlueFieldPosition: 0 [ 972.953] LinRsvdMaskSize: 0 [ 972.953] LinRsvdFieldPosition: 0 [ 972.953] MaxPixelClock: 229500000 [ 972.956] Mode: 132 (320x400) [ 972.956] ModeAttributes: 0x3bf [ 972.956] WinAAttributes: 0x7 [ 972.956] WinBAttributes: 0x0 [ 972.956] WinGranularity: 64 [ 972.956] WinSize: 64 [ 972.956] WinASegment: 0xa000 [ 972.956] WinBSegment: 0x0 [ 972.956] WinFuncPtr: 0xc0007e63 [ 972.957] BytesPerScanline: 640 [ 972.957] XResolution: 320 [ 972.957] YResolution: 400 [ 972.957] XCharSize: 8 [ 972.957] YCharSize: 16 [ 972.957] NumberOfPlanes: 1 [ 972.957] BitsPerPixel: 16 [ 972.957] NumberOfBanks: 1 [ 972.957] MemoryModel: 6 [ 972.957] BankSize: 0 [ 972.957] NumberOfImages: 14 [ 972.957] RedMaskSize: 5 [ 972.957] RedFieldPosition: 11 [ 972.957] GreenMaskSize: 6 [ 972.957] GreenFieldPosition: 5 [ 972.957] BlueMaskSize: 5 [ 972.957] BlueFieldPosition: 0 [ 972.957] RsvdMaskSize: 0 [ 972.957] RsvdFieldPosition: 0 [ 972.957] DirectColorModeInfo: 0 [ 972.957] PhysBasePtr: 0xcf000000 [ 972.957] LinBytesPerScanLine: 640 [ 972.957] BnkNumberOfImagePages: 14 [ 972.957] LinNumberOfImagePages: 14 [ 972.957] LinRedMaskSize: 5 [ 972.958] LinRedFieldPosition: 11 [ 972.958] LinGreenMaskSize: 6 [ 972.958] LinGreenFieldPosition: 5 [ 972.958] LinBlueMaskSize: 5 [ 972.958] LinBlueFieldPosition: 0 [ 972.958] LinRsvdMaskSize: 0 [ 972.958] LinRsvdFieldPosition: 0 [ 972.958] MaxPixelClock: 229500000 [ 972.961] *Mode: 133 (320x400) [ 972.961] ModeAttributes: 0x3bf [ 972.961] WinAAttributes: 0x7 [ 972.961] WinBAttributes: 0x0 [ 972.961] WinGranularity: 64 [ 972.961] WinSize: 64 [ 972.961] WinASegment: 0xa000 [ 972.961] WinBSegment: 0x0 [ 972.961] WinFuncPtr: 0xc0007e63 [ 972.961] BytesPerScanline: 1280 [ 972.961] XResolution: 320 [ 972.961] YResolution: 400 [ 972.961] XCharSize: 8 [ 972.961] YCharSize: 16 [ 972.961] NumberOfPlanes: 1 [ 972.961] BitsPerPixel: 32 [ 972.962] NumberOfBanks: 1 [ 972.962] MemoryModel: 6 [ 972.962] BankSize: 0 [ 972.962] NumberOfImages: 6 [ 972.962] RedMaskSize: 8 [ 972.962] RedFieldPosition: 16 [ 972.962] GreenMaskSize: 8 [ 972.962] GreenFieldPosition: 8 [ 972.962] BlueMaskSize: 8 [ 972.962] BlueFieldPosition: 0 [ 972.962] RsvdMaskSize: 8 [ 972.962] RsvdFieldPosition: 24 [ 972.962] DirectColorModeInfo: 0 [ 972.962] PhysBasePtr: 0xcf000000 [ 972.962] LinBytesPerScanLine: 1280 [ 972.962] BnkNumberOfImagePages: 6 [ 972.962] LinNumberOfImagePages: 6 [ 972.962] LinRedMaskSize: 8 [ 972.962] LinRedFieldPosition: 16 [ 972.962] LinGreenMaskSize: 8 [ 972.962] LinGreenFieldPosition: 8 [ 972.962] LinBlueMaskSize: 8 [ 972.962] LinBlueFieldPosition: 0 [ 972.962] LinRsvdMaskSize: 8 [ 972.962] LinRsvdFieldPosition: 24 [ 972.963] MaxPixelClock: 229500000 [ 972.966] Mode: 134 (320x240) [ 972.966] ModeAttributes: 0x3bf [ 972.966] WinAAttributes: 0x7 [ 972.966] WinBAttributes: 0x0 [ 972.966] WinGranularity: 64 [ 972.966] WinSize: 64 [ 972.966] WinASegment: 0xa000 [ 972.966] WinBSegment: 0x0 [ 972.966] WinFuncPtr: 0xc0007e63 [ 972.966] BytesPerScanline: 320 [ 972.966] XResolution: 320 [ 972.966] YResolution: 240 [ 972.966] XCharSize: 8 [ 972.966] YCharSize: 8 [ 972.966] NumberOfPlanes: 1 [ 972.966] BitsPerPixel: 8 [ 972.966] NumberOfBanks: 1 [ 972.966] MemoryModel: 4 [ 972.966] BankSize: 0 [ 972.966] NumberOfImages: 30 [ 972.966] RedMaskSize: 0 [ 972.966] RedFieldPosition: 0 [ 972.966] GreenMaskSize: 0 [ 972.967] GreenFieldPosition: 0 [ 972.967] BlueMaskSize: 0 [ 972.967] BlueFieldPosition: 0 [ 972.967] RsvdMaskSize: 0 [ 972.967] RsvdFieldPosition: 0 [ 972.967] DirectColorModeInfo: 0 [ 972.967] PhysBasePtr: 0xcf000000 [ 972.967] LinBytesPerScanLine: 320 [ 972.967] BnkNumberOfImagePages: 30 [ 972.967] LinNumberOfImagePages: 30 [ 972.967] LinRedMaskSize: 0 [ 972.967] LinRedFieldPosition: 0 [ 972.967] LinGreenMaskSize: 0 [ 972.967] LinGreenFieldPosition: 0 [ 972.967] LinBlueMaskSize: 0 [ 972.967] LinBlueFieldPosition: 0 [ 972.967] LinRsvdMaskSize: 0 [ 972.967] LinRsvdFieldPosition: 0 [ 972.967] MaxPixelClock: 229500000 [ 972.970] Mode: 135 (320x240) [ 972.970] ModeAttributes: 0x3bf [ 972.970] WinAAttributes: 0x7 [ 972.970] WinBAttributes: 0x0 [ 972.970] WinGranularity: 64 [ 972.971] WinSize: 64 [ 972.971] WinASegment: 0xa000 [ 972.971] WinBSegment: 0x0 [ 972.971] WinFuncPtr: 0xc0007e63 [ 972.971] BytesPerScanline: 640 [ 972.971] XResolution: 320 [ 972.971] YResolution: 240 [ 972.971] XCharSize: 8 [ 972.971] YCharSize: 8 [ 972.971] NumberOfPlanes: 1 [ 972.971] BitsPerPixel: 16 [ 972.971] NumberOfBanks: 1 [ 972.971] MemoryModel: 6 [ 972.971] BankSize: 0 [ 972.971] NumberOfImages: 19 [ 972.971] RedMaskSize: 5 [ 972.971] RedFieldPosition: 11 [ 972.971] GreenMaskSize: 6 [ 972.971] GreenFieldPosition: 5 [ 972.971] BlueMaskSize: 5 [ 972.971] BlueFieldPosition: 0 [ 972.971] RsvdMaskSize: 0 [ 972.971] RsvdFieldPosition: 0 [ 972.971] DirectColorModeInfo: 0 [ 972.971] PhysBasePtr: 0xcf000000 [ 972.972] LinBytesPerScanLine: 640 [ 972.972] BnkNumberOfImagePages: 19 [ 972.972] LinNumberOfImagePages: 19 [ 972.972] LinRedMaskSize: 5 [ 972.972] LinRedFieldPosition: 11 [ 972.972] LinGreenMaskSize: 6 [ 972.972] LinGreenFieldPosition: 5 [ 972.972] LinBlueMaskSize: 5 [ 972.972] LinBlueFieldPosition: 0 [ 972.972] LinRsvdMaskSize: 0 [ 972.972] LinRsvdFieldPosition: 0 [ 972.972] MaxPixelClock: 229500000 [ 972.975] *Mode: 136 (320x240) [ 972.975] ModeAttributes: 0x3bf [ 972.975] WinAAttributes: 0x7 [ 972.975] WinBAttributes: 0x0 [ 972.975] WinGranularity: 64 [ 972.975] WinSize: 64 [ 972.975] WinASegment: 0xa000 [ 972.975] WinBSegment: 0x0 [ 972.975] WinFuncPtr: 0xc0007e63 [ 972.975] BytesPerScanline: 1280 [ 972.975] XResolution: 320 [ 972.976] YResolution: 240 [ 972.976] XCharSize: 8 [ 972.976] YCharSize: 8 [ 972.976] NumberOfPlanes: 1 [ 972.976] BitsPerPixel: 32 [ 972.976] NumberOfBanks: 1 [ 972.976] MemoryModel: 6 [ 972.976] BankSize: 0 [ 972.976] NumberOfImages: 10 [ 972.976] RedMaskSize: 8 [ 972.976] RedFieldPosition: 16 [ 972.976] GreenMaskSize: 8 [ 972.976] GreenFieldPosition: 8 [ 972.976] BlueMaskSize: 8 [ 972.976] BlueFieldPosition: 0 [ 972.976] RsvdMaskSize: 8 [ 972.976] RsvdFieldPosition: 24 [ 972.976] DirectColorModeInfo: 0 [ 972.976] PhysBasePtr: 0xcf000000 [ 972.976] LinBytesPerScanLine: 1280 [ 972.976] BnkNumberOfImagePages: 10 [ 972.976] LinNumberOfImagePages: 10 [ 972.976] LinRedMaskSize: 8 [ 972.976] LinRedFieldPosition: 16 [ 972.976] LinGreenMaskSize: 8 [ 972.977] LinGreenFieldPosition: 8 [ 972.977] LinBlueMaskSize: 8 [ 972.977] LinBlueFieldPosition: 0 [ 972.977] LinRsvdMaskSize: 8 [ 972.977] LinRsvdFieldPosition: 24 [ 972.977] MaxPixelClock: 229500000 [ 972.980] Mode: 13d (640x400) [ 972.980] ModeAttributes: 0x3bf [ 972.980] WinAAttributes: 0x7 [ 972.980] WinBAttributes: 0x0 [ 972.980] WinGranularity: 64 [ 972.980] WinSize: 64 [ 972.980] WinASegment: 0xa000 [ 972.980] WinBSegment: 0x0 [ 972.980] WinFuncPtr: 0xc0007e63 [ 972.980] BytesPerScanline: 1280 [ 972.980] XResolution: 640 [ 972.980] YResolution: 400 [ 972.980] XCharSize: 8 [ 972.980] YCharSize: 16 [ 972.980] NumberOfPlanes: 1 [ 972.980] BitsPerPixel: 16 [ 972.980] NumberOfBanks: 1 [ 972.980] MemoryModel: 6 [ 972.981] BankSize: 0 [ 972.981] NumberOfImages: 6 [ 972.981] RedMaskSize: 5 [ 972.981] RedFieldPosition: 11 [ 972.981] GreenMaskSize: 6 [ 972.981] GreenFieldPosition: 5 [ 972.981] BlueMaskSize: 5 [ 972.981] BlueFieldPosition: 0 [ 972.981] RsvdMaskSize: 0 [ 972.981] RsvdFieldPosition: 0 [ 972.981] DirectColorModeInfo: 0 [ 972.981] PhysBasePtr: 0xcf000000 [ 972.981] LinBytesPerScanLine: 1280 [ 972.981] BnkNumberOfImagePages: 6 [ 972.981] LinNumberOfImagePages: 6 [ 972.981] LinRedMaskSize: 5 [ 972.981] LinRedFieldPosition: 11 [ 972.981] LinGreenMaskSize: 6 [ 972.981] LinGreenFieldPosition: 5 [ 972.981] LinBlueMaskSize: 5 [ 972.981] LinBlueFieldPosition: 0 [ 972.981] LinRsvdMaskSize: 0 [ 972.981] LinRsvdFieldPosition: 0 [ 972.981] MaxPixelClock: 229500000 [ 972.985] *Mode: 13e (640x400) [ 972.985] ModeAttributes: 0x3bf [ 972.985] WinAAttributes: 0x7 [ 972.985] WinBAttributes: 0x0 [ 972.985] WinGranularity: 64 [ 972.985] WinSize: 64 [ 972.985] WinASegment: 0xa000 [ 972.985] WinBSegment: 0x0 [ 972.985] WinFuncPtr: 0xc0007e63 [ 972.985] BytesPerScanline: 2560 [ 972.985] XResolution: 640 [ 972.985] YResolution: 400 [ 972.985] XCharSize: 8 [ 972.985] YCharSize: 16 [ 972.985] NumberOfPlanes: 1 [ 972.985] BitsPerPixel: 32 [ 972.985] NumberOfBanks: 1 [ 972.985] MemoryModel: 6 [ 972.985] BankSize: 0 [ 972.985] NumberOfImages: 2 [ 972.985] RedMaskSize: 8 [ 972.985] RedFieldPosition: 16 [ 972.986] GreenMaskSize: 8 [ 972.986] GreenFieldPosition: 8 [ 972.986] BlueMaskSize: 8 [ 972.986] BlueFieldPosition: 0 [ 972.986] RsvdMaskSize: 8 [ 972.986] RsvdFieldPosition: 24 [ 972.986] DirectColorModeInfo: 0 [ 972.986] PhysBasePtr: 0xcf000000 [ 972.986] LinBytesPerScanLine: 2560 [ 972.986] BnkNumberOfImagePages: 2 [ 972.986] LinNumberOfImagePages: 2 [ 972.986] LinRedMaskSize: 8 [ 972.986] LinRedFieldPosition: 16 [ 972.986] LinGreenMaskSize: 8 [ 972.986] LinGreenFieldPosition: 8 [ 972.986] LinBlueMaskSize: 8 [ 972.986] LinBlueFieldPosition: 0 [ 972.986] LinRsvdMaskSize: 8 [ 972.986] LinRsvdFieldPosition: 24 [ 972.986] MaxPixelClock: 229500000 [ 972.989] Mode: 160 (1280x800) [ 972.990] ModeAttributes: 0x3bf [ 972.990] WinAAttributes: 0x7 [ 972.990] WinBAttributes: 0x0 [ 972.990] WinGranularity: 64 [ 972.990] WinSize: 64 [ 972.990] WinASegment: 0xa000 [ 972.990] WinBSegment: 0x0 [ 972.990] WinFuncPtr: 0xc0007e63 [ 972.990] BytesPerScanline: 1280 [ 972.990] XResolution: 1280 [ 972.990] YResolution: 800 [ 972.990] XCharSize: 8 [ 972.990] YCharSize: 16 [ 972.990] NumberOfPlanes: 1 [ 972.990] BitsPerPixel: 8 [ 972.990] NumberOfBanks: 1 [ 972.990] MemoryModel: 4 [ 972.990] BankSize: 0 [ 972.990] NumberOfImages: 2 [ 972.990] RedMaskSize: 0 [ 972.990] RedFieldPosition: 0 [ 972.990] GreenMaskSize: 0 [ 972.990] GreenFieldPosition: 0 [ 972.990] BlueMaskSize: 0 [ 972.990] BlueFieldPosition: 0 [ 972.991] RsvdMaskSize: 0 [ 972.991] RsvdFieldPosition: 0 [ 972.991] DirectColorModeInfo: 0 [ 972.991] PhysBasePtr: 0xcf000000 [ 972.991] LinBytesPerScanLine: 1280 [ 972.991] BnkNumberOfImagePages: 2 [ 972.991] LinNumberOfImagePages: 2 [ 972.991] LinRedMaskSize: 0 [ 972.991] LinRedFieldPosition: 0 [ 972.991] LinGreenMaskSize: 0 [ 972.991] LinGreenFieldPosition: 0 [ 972.991] LinBlueMaskSize: 0 [ 972.991] LinBlueFieldPosition: 0 [ 972.991] LinRsvdMaskSize: 0 [ 972.991] LinRsvdFieldPosition: 0 [ 972.991] MaxPixelClock: 229500000 [ 972.994] *Mode: 161 (1280x800) [ 972.994] ModeAttributes: 0x3bf [ 972.994] WinAAttributes: 0x7 [ 972.994] WinBAttributes: 0x0 [ 972.995] WinGranularity: 64 [ 972.995] WinSize: 64 [ 972.995] WinASegment: 0xa000 [ 972.995] WinBSegment: 0x0 [ 972.995] WinFuncPtr: 0xc0007e63 [ 972.995] BytesPerScanline: 5120 [ 972.995] XResolution: 1280 [ 972.995] YResolution: 800 [ 972.995] XCharSize: 8 [ 972.995] YCharSize: 16 [ 972.995] NumberOfPlanes: 1 [ 972.995] BitsPerPixel: 32 [ 972.995] NumberOfBanks: 1 [ 972.995] MemoryModel: 6 [ 972.995] BankSize: 0 [ 972.995] NumberOfImages: 1 [ 972.995] RedMaskSize: 8 [ 972.995] RedFieldPosition: 16 [ 972.995] GreenMaskSize: 8 [ 972.995] GreenFieldPosition: 8 [ 972.995] BlueMaskSize: 8 [ 972.995] BlueFieldPosition: 0 [ 972.995] RsvdMaskSize: 8 [ 972.995] RsvdFieldPosition: 24 [ 972.996] DirectColorModeInfo: 0 [ 972.996] PhysBasePtr: 0xcf000000 [ 972.996] LinBytesPerScanLine: 5120 [ 972.996] BnkNumberOfImagePages: 1 [ 972.996] LinNumberOfImagePages: 1 [ 972.996] LinRedMaskSize: 8 [ 972.996] LinRedFieldPosition: 16 [ 972.996] LinGreenMaskSize: 8 [ 972.996] LinGreenFieldPosition: 8 [ 972.996] LinBlueMaskSize: 8 [ 972.996] LinBlueFieldPosition: 0 [ 972.996] LinRsvdMaskSize: 8 [ 972.996] LinRsvdFieldPosition: 24 [ 972.996] MaxPixelClock: 229500000 [ 972.999] Mode: 162 (768x480) [ 972.999] ModeAttributes: 0x3bf [ 972.999] WinAAttributes: 0x7 [ 972.999] WinBAttributes: 0x0 [ 972.999] WinGranularity: 64 [ 972.999] WinSize: 64 [ 972.999] WinASegment: 0xa000 [ 973.000] WinBSegment: 0x0 [ 973.000] WinFuncPtr: 0xc0007e63 [ 973.000] BytesPerScanline: 768 [ 973.000] XResolution: 768 [ 973.000] YResolution: 480 [ 973.000] XCharSize: 8 [ 973.000] YCharSize: 16 [ 973.000] NumberOfPlanes: 1 [ 973.000] BitsPerPixel: 8 [ 973.000] NumberOfBanks: 1 [ 973.000] MemoryModel: 4 [ 973.000] BankSize: 0 [ 973.000] NumberOfImages: 8 [ 973.000] RedMaskSize: 0 [ 973.000] RedFieldPosition: 0 [ 973.000] GreenMaskSize: 0 [ 973.000] GreenFieldPosition: 0 [ 973.000] BlueMaskSize: 0 [ 973.000] BlueFieldPosition: 0 [ 973.000] RsvdMaskSize: 0 [ 973.000] RsvdFieldPosition: 0 [ 973.000] DirectColorModeInfo: 0 [ 973.000] PhysBasePtr: 0xcf000000 [ 973.000] LinBytesPerScanLine: 768 [ 973.000] BnkNumberOfImagePages: 8 [ 973.001] LinNumberOfImagePages: 8 [ 973.001] LinRedMaskSize: 0 [ 973.001] LinRedFieldPosition: 0 [ 973.001] LinGreenMaskSize: 0 [ 973.001] LinGreenFieldPosition: 0 [ 973.001] LinBlueMaskSize: 0 [ 973.001] LinBlueFieldPosition: 0 [ 973.001] LinRsvdMaskSize: 0 [ 973.001] LinRsvdFieldPosition: 0 [ 973.001] MaxPixelClock: 229500000 [ 973.004] *Mode: 163 (848x480) [ 973.004] ModeAttributes: 0x3bf [ 973.004] WinAAttributes: 0x7 [ 973.004] WinBAttributes: 0x0 [ 973.004] WinGranularity: 64 [ 973.004] WinSize: 64 [ 973.004] WinASegment: 0xa000 [ 973.004] WinBSegment: 0x0 [ 973.004] WinFuncPtr: 0xc0007e63 [ 973.004] BytesPerScanline: 3392 [ 973.005] XResolution: 848 [ 973.005] YResolution: 480 [ 973.005] XCharSize: 8 [ 973.005] YCharSize: 16 [ 973.005] NumberOfPlanes: 1 [ 973.005] BitsPerPixel: 32 [ 973.005] NumberOfBanks: 1 [ 973.005] MemoryModel: 6 [ 973.005] BankSize: 0 [ 973.005] NumberOfImages: 1 [ 973.005] RedMaskSize: 8 [ 973.005] RedFieldPosition: 16 [ 973.005] GreenMaskSize: 8 [ 973.005] GreenFieldPosition: 8 [ 973.005] BlueMaskSize: 8 [ 973.005] BlueFieldPosition: 0 [ 973.005] RsvdMaskSize: 8 [ 973.005] RsvdFieldPosition: 24 [ 973.005] DirectColorModeInfo: 0 [ 973.005] PhysBasePtr: 0xcf000000 [ 973.005] LinBytesPerScanLine: 3392 [ 973.005] BnkNumberOfImagePages: 1 [ 973.005] LinNumberOfImagePages: 1 [ 973.005] LinRedMaskSize: 8 [ 973.006] LinRedFieldPosition: 16 [ 973.006] LinGreenMaskSize: 8 [ 973.006] LinGreenFieldPosition: 8 [ 973.006] LinBlueMaskSize: 8 [ 973.006] LinBlueFieldPosition: 0 [ 973.006] LinRsvdMaskSize: 8 [ 973.006] LinRsvdFieldPosition: 24 [ 973.006] MaxPixelClock: 229500000 [ 973.006] [ 973.006] (II) VESA(0): Total Memory: 224 64KB banks (14336kB) [ 973.006] (II) VESA(0): : Using hsync range of 31.00-80.00 kHz [ 973.006] (II) VESA(0): : Using vrefresh range of 56.00-75.00 Hz [ 973.006] (II) VESA(0): : Using maximum pixel clock of 175.00 MHz [ 973.006] (WW) VESA(0): Unable to estimate virtual size [ 973.006] (II) VESA(0): Not using built-in mode "1280x800" (no mode of this name) [ 973.009] (II) VESA(0): Not using built-in mode "848x480" (no mode of this name) [ 973.010] (II) VESA(0): Not using built-in mode "640x400" (no mode of this name) [ 973.010] (II) VESA(0): Not using built-in mode "320x400" (no mode of this name) [ 973.010] (II) VESA(0): Not using built-in mode "320x240" (no mode of this name) [ 973.010] (II) VESA(0): Not using built-in mode "320x200" (no mode of this name) [ 973.010] (--) VESA(0): Virtual size is 1024x768 (pitch 1024) [ 973.010] (**) VESA(0): *Built-in mode "1024x768" [ 973.010] (**) VESA(0): *Built-in mode "800x600" [ 973.010] (**) VESA(0): *Built-in mode "640x480" [ 973.010] (**) VESA(0): Display dimensions: (470, 300) mm [ 973.010] (**) VESA(0): DPI set to (55, 65) [ 973.010] (**) VESA(0): Using "Shadow Framebuffer" [ 973.010] (II) Loading sub module "shadow" [ 973.010] (II) LoadModule: "shadow" [ 973.011] (II) Loading /usr/local/lib/xorg/modules/libshadow.so [ 973.012] (II) Module shadow: vendor="X.Org Foundation" [ 973.012] compiled for 1.18.4, module version = 1.1.0 [ 973.012] ABI class: X.Org ANSI C Emulation, version 0.4 [ 973.012] (II) Loading sub module "fb" [ 973.012] (II) LoadModule: "fb" [ 973.012] (II) Loading /usr/local/lib/xorg/modules/libfb.so [ 973.015] (II) Module fb: vendor="X.Org Foundation" [ 973.015] compiled for 1.18.4, module version = 1.0.0 [ 973.015] ABI class: X.Org ANSI C Emulation, version 0.4 [ 973.015] (==) Depth 24 pixmap format is 32 bpp [ 973.015] (II) Loading sub module "int10" [ 973.016] (II) LoadModule: "int10" [ 973.016] (II) Loading /usr/local/lib/xorg/modules/libint10.so [ 973.016] (II) Module int10: vendor="X.Org Foundation" [ 973.016] compiled for 1.18.4, module version = 1.0.0 [ 973.016] ABI class: X.Org Video Driver, version 20.0 [ 973.016] (II) VESA(0): initializing int10 [ 973.016] (II) VESA(0): Bad V_BIOS checksum [ 973.016] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 973.122] (II) VESA(0): VESA BIOS detected [ 973.122] (II) VESA(0): VESA VBE Version 3.0 [ 973.122] (II) VESA(0): VESA VBE Total Mem: 14336 kB [ 973.122] (II) VESA(0): VESA VBE OEM: NVIDIA [ 973.122] (II) VESA(0): VESA VBE OEM Software Rev: 112.24 [ 973.123] (II) VESA(0): VESA VBE OEM Vendor: NVIDIA Corporation [ 973.123] (II) VESA(0): VESA VBE OEM Product: NVIDIA Quadro NVS170M [ 973.123] (II) VESA(0): VESA VBE OEM Product Rev: Chip Rev [ 973.126] (II) VESA(0): virtual address = 0x805800000, VGAbase = 0x8017e1000 physical address = 0xcf000000, size = 14680064 [ 973.133] (II) VESA(0): Setting up VESA Mode 0x118 (1024x768) [ 973.266] (==) VESA(0): Default visual is TrueColor [ 973.268] (==) VESA(0): Backing store enabled [ 973.270] (==) VESA(0): DPMS enabled [ 973.270] (==) RandR enabled [ 973.299] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) [ 973.412] (II) config/devd: probing input devices... [ 973.413] (II) config/devd: adding input device (null) (/dev/kbdmux) [ 973.413] (II) LoadModule: "kbd" [ 973.413] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so [ 973.414] (II) Module kbd: vendor="X.Org Foundation" [ 973.414] compiled for 1.18.4, module version = 1.9.0 [ 973.414] Module class: X.Org XInput Driver [ 973.414] ABI class: X.Org XInput driver, version 22.1 [ 973.414] (II) Using input driver 'kbd' for 'kbdmux' [ 973.414] (**) kbdmux: always reports core events [ 973.414] (**) kbdmux: always reports core events [ 973.414] (**) Option "Protocol" "standard" [ 973.415] (**) Option "XkbRules" "base" [ 973.415] (**) Option "XkbModel" "pc105" [ 973.415] (**) Option "XkbLayout" "us" [ 973.415] (**) Option "config_info" "devd:kbdmux" [ 973.415] (II) XINPUT: Adding extended input device "kbdmux" (type: KEYBOARD, id 6) [ 973.418] (II) config/devd: kbdmux is enabled, ignoring device ukbd0 [ 973.418] (II) config/devd: kbdmux is enabled, ignoring device atkbd0 [ 973.418] (II) config/devd: adding input device (null) (/dev/sysmouse) [ 973.418] (II) LoadModule: "mouse" [ 973.419] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 973.421] (II) Module mouse: vendor="X.Org Foundation" [ 973.421] compiled for 1.18.4, module version = 1.9.3 [ 973.421] Module class: X.Org XInput Driver [ 973.421] ABI class: X.Org XInput driver, version 22.1 [ 973.421] (II) Using input driver 'mouse' for 'sysmouse' [ 973.421] (**) sysmouse: always reports core events [ 973.421] (**) Option "Device" "/dev/sysmouse" [ 973.421] (==) sysmouse: Protocol: "Auto" [ 973.421] (**) sysmouse: always reports core events [ 973.421] (==) sysmouse: Emulate3Buttons, Emulate3Timeout: 50 [ 973.421] (**) sysmouse: ZAxisMapping: buttons 4 and 5 [ 973.421] (**) sysmouse: Buttons: 5 [ 973.421] (**) Option "config_info" "devd:sysmouse" [ 973.422] (II) XINPUT: Adding extended input device "sysmouse" (type: MOUSE, id 7) [ 973.422] (**) sysmouse: (accel) keeping acceleration scheme 1 [ 973.422] (**) sysmouse: (accel) acceleration profile 0 [ 973.422] (**) sysmouse: (accel) acceleration factor: 2.000 [ 973.422] (**) sysmouse: (accel) acceleration threshold: 4 [ 973.422] (II) sysmouse: SetupAuto: hw.iftype is 4, hw.model is 0 [ 973.422] (II) sysmouse: SetupAuto: protocol is SysMouse [ 973.422] (II) config/devd: device /dev/ums0 already opened [ 973.422] (II) config/devd: device /dev/ums1 already opened [ 973.482] (II) config/devd: adding input device Mouse (/dev/psm0) [ 973.482] (II) Using input driver 'mouse' for 'Mouse' [ 973.483] (**) Mouse: always reports core events [ 973.483] (**) Option "Device" "/dev/psm0" [ 973.483] (==) Mouse: Protocol: "Auto" [ 973.483] (**) Mouse: always reports core events [ 973.540] (==) Mouse: Emulate3Buttons, Emulate3Timeout: 50 [ 973.540] (**) Mouse: ZAxisMapping: buttons 4 and 5 [ 973.541] (**) Mouse: Buttons: 5 [ 973.541] (**) Option "config_info" "devd:psm0" [ 973.541] (II) XINPUT: Adding extended input device "Mouse" (type: MOUSE, id 8) [ 973.541] (**) Mouse: (accel) keeping acceleration scheme 1 [ 973.541] (**) Mouse: (accel) acceleration profile 0 [ 973.541] (**) Mouse: (accel) acceleration factor: 2.000 [ 973.541] (**) Mouse: (accel) acceleration threshold: 4 [ 973.558] (II) Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 [ 973.559] (II) Mouse: SetupAuto: protocol is PS/2 [ 973.718] (II) Mouse: ps2EnableDataReporting: succeeded From owner-freebsd-current@freebsd.org Wed Aug 22 20:04:05 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 16107109458C for ; Wed, 22 Aug 2018 20:04:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 7159A892F1 for ; Wed, 22 Aug 2018 20:04:04 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 96355 invoked by uid 89); 22 Aug 2018 20:03:56 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 22 Aug 2018 20:03:56 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180822154603.GW2340@kib.kiev.ua> Date: Wed, 22 Aug 2018 22:03:54 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180815135531.GA2340@kib.kiev.ua> <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 20:04:05 -0000 > On 22. Aug 2018, at 17:46, Konstantin Belousov wrote= : >=20 >> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: >>=20 >>=20 >>>> On 20. Aug 2018, at 17:09, Konstantin Belousov wr= ote: >>>>=20 >>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: >>>>=20 >>>> See here for a screenshot (also including the output of "show pte >>>> 0xfffff80001000000"): >>>>=20 >>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-dd= b1-png >>> It is too early for ddb routines to register. >>> Ok can you try the following debugging patch, to verify my guess ? >>>=20 >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>> index 18777d23f09..cd05fdb763f 100644 >>> --- a/sys/amd64/amd64/pmap.c >>> +++ b/sys/amd64/amd64/pmap.c >>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) >>> pd_p =3D (pd_entry_t *)DMPDkernphys; >>> for (i =3D 0; i < (NPDEPG * nkdmpde); i++) >>> pd_p[i] =3D (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | >>> - X86_PG_M | X86_PG_A | pg_nx | >>> - bootaddr_rwx(i << PDRSHIFT); >>> + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; >>> for (i =3D 0; i < nkdmpde; i++) >>> pdp_p[i] =3D (DMPDkernphys + ptoa(i)) | X86_PG_RW | >>> X86_PG_V; >>=20 >> With this change it boots okay (mptramp_pagetables is 0x1000000, as expec= ted). >=20 > Can you apply the following on top of the previous debugging patch and sho= w > me the line printed ? >=20 > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 3d70532b7fd..613fa9f2165 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) > pmap->pm_pcids[i].pm_gen =3D 1; > } > pmap_activate_boot(pmap); > +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx e= text %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (uintptr= _t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uintptr= _t)KERNBASE); > } >=20 > void bootaddr addr 0x1000000 rwx 0 btext 0xffffffff80342000 _end 0xffffffff823cf8= 40 brwsection #ffffffff81a00000 etext 0xffffffff812041e4 KERNBASE 0xffffffff= 80000000 Best, Michael From owner-freebsd-current@freebsd.org Wed Aug 22 19:23:17 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 869281092D1B for ; Wed, 22 Aug 2018 19:23:17 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 077D585F84 for ; Wed, 22 Aug 2018 19:23:17 +0000 (UTC) (envelope-from sef@ixsystems.com) Received: by mail-pg1-x52b.google.com with SMTP id v66-v6so1353524pgb.10 for ; Wed, 22 Aug 2018 12:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D/sOF9M653EyysrHa6kRvzooofB4wXSSbyiXGMKzKho=; b=eYVaWtL1ri+DsgOhZ//EhWj4+Tu/cLRI9J/yuVEb8eLeMiXK5HjZslNIuQLzFhJRIo 7835/ebDJxUaQ4VGS+28XYYX/JzaQ6QvsiLRNvqlUqAZ8xaFBFDUBFqrTf0yXkG+g5eb rYgyXZXc/2NpspVbPA8SXfg5hte4r2E9CYMHAwKrwTWMcf8KpCl6npCLRrGDic4r+tiH liLbRQxem8ZX6srx0HGrDWGjD0pKc5i/osalTEO+TKBw8LlgeeLCRAf48QaB6pdhPwI2 M/DJ2tS5nW5NcVkGdBbPqLVQhFFERfGpgzAiNSU+X/EM61eL6Mzygcvs1iUQGUIxJgYa b5mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D/sOF9M653EyysrHa6kRvzooofB4wXSSbyiXGMKzKho=; b=SOo7dD2p5cWOJi4s5ylEmsHgOVesR2ex8njikngS36UcyYftoNSpEHWHM/IJHAlWw7 4gf5nWvNQYnXlXv+N90qGmDdJ5HsQZtXbKNgPiqTBhInq7Ylc2EFYrTjZwEjzm72DyZs V/KAP8H2kL5P1MZsAmYwO6mkQyyrnM7MHL5sqKZeHOXiAHRzgOE0L3XQYgox8YjSCqHE ymGCnDYZLbhbST8nlNsz0vAwY5IDXL5ZVaDAEw8/A4wgj+mrrihuQyONCVdxnfnTSxnK HLYBS5hDG2UTcEDjR0jOMb/AcvjCEI4/Kiy9pka8vtKoiMmnmsrrSWj6ApAqIyxs/IMI OUdA== X-Gm-Message-State: AOUpUlFTYyfrNhDmLIL6JqgDx88YOk6H/9IUnLe5DhGphGDmdnwBfi/d MT4zQP6h/LAAGn8u/J+uKPQ6lo3BGus= X-Google-Smtp-Source: AA+uWPy7qBnVsW/ddNGHTfD8QVfJR8B8yh+lvBsj2w0I+v7RXU2FzSkYkz9cgPgts9KVw15fI7rsug== X-Received: by 2002:a63:2b82:: with SMTP id r124-v6mr9594282pgr.159.1534965796135; Wed, 22 Aug 2018 12:23:16 -0700 (PDT) Received: from [10.250.1.167] ([12.229.62.29]) by smtp.gmail.com with ESMTPSA id h130-v6sm6345969pgc.88.2018.08.22.12.23.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Aug 2018 12:23:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Native Encryption for ZFS on FreeBSD CFT From: Sean Fagan In-Reply-To: Date: Wed, 22 Aug 2018 12:23:13 -0700 Cc: Matthew Macy , FreeBSD CURRENT , freebsd-fs Content-Transfer-Encoding: quoted-printable Message-Id: References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> To: Alan Somers X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 22 Aug 2018 20:21:07 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 19:23:17 -0000 On Aug 22, 2018, at 12:20 PM, Alan Somers wrote: > ]That doesn't answer the question about what happens when dedup is = turned off. In that case, is the HMAC still used as the IV? If so, = then watermarking attacks are still possible. If ZFS switches to a = random IV when dedup is off, then it would probably be ok. =46rom the same file: * Initialization Vector (IV): = =20 * An initialization vector for the encryption algorithms. This is used = to =20 * "tweak" the encryption algorithms so that two blocks of the same data = are =20 * encrypted into different ciphertext outputs, thus obfuscating block = patterns. =20 * The supported encryption modes (AES-GCM and AES-CCM) require that an = IV is =20 * never reused with the same encryption key. This value is stored = unencrypted =20 * and must simply be provided to the decryption function. We use a 96 = bit IV =20 * (as recommended by NIST) for all block encryption. For non-dedup = blocks we =20 * derive the IV randomly. The first 64 bits of the IV are stored in the = second =20 * word of DVA[2] and the remaining 32 bits are stored in the upper 32 = bits of =20 * blk_fill. This is safe because encrypted blocks can't use the upper = 32 bits =20 * of blk_fill. We only encrypt level 0 blocks, which normally have a = fill count =20 * of 1. The only exception is for DMU_OT_DNODE objects, where the fill = count of =20 * level 0 blocks is the number of allocated dnodes in that block. The = on-disk =20 * format supports at most 2^15 slots per L0 dnode block, because the = maximum =20 * block size is 16MB (2^24). In either case, for level 0 blocks this = number =20 * will still be smaller than UINT32_MAX so it is safe to store the IV = in the =20 * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fill = count =20 * for the dnode code. = =20 Sean From owner-freebsd-current@freebsd.org Wed Aug 22 20:23: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 17D341094E18 for ; Wed, 22 Aug 2018 20:23:50 +0000 (UTC) (envelope-from andreas@naund.org) Received: from naund.org (172-11-194-172.lightspeed.sntcca.sbcglobal.net [172.11.194.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4A09B8A156 for ; Wed, 22 Aug 2018 20:23:48 +0000 (UTC) (envelope-from andreas@naund.org) Received: (from andreas@localhost) by naund.org (8.11.6/8.11.6-20030329ao) id w7MKLaK10381 for freebsd-current@freebsd.org; Wed, 22 Aug 2018 13:21:36 -0700 Date: Wed, 22 Aug 2018 13:21:35 -0700 From: Andreas Ott To: freebsd-current@freebsd.org Subject: timing issue with ifconfig em(4) at rc.d start? Message-ID: <20180822132135.A9818@naund.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 20:23:50 -0000 Yesterday I installed a server from scratch from image FreeBSD-12.0-ALPHA2-amd64-20180816-r337934-memstick.img, then I updated sources with svn and did make buildworld, buildkernel, installkernel, installworld, mergemaster. Upon reboot I can no longer talk to the server on IPv4 but it works on IPv6, ifconfig tells me there is no 'inet' address configured. No IPv4 inet routes are in place either. If I run '/etc/rc.d/netif restart' from root shell on KVM console, I can observe that the interface is taken down, the link light goes dark, and then comes back up. However the "UP" log notification appears in time *after* ifconfig attempts to apply settings to an interface that is still down as it prints out to screen (em1 is shown there as 'status: no carrier' at the time). em1: link state changed to DOWN Link state changed to up em1: link state changed to UP Is there a way to delay the 'ifconfig inet' until after the link light comes up? Or how do I force configuring an interface that's down in rc? Nothing changed on the configuration side or the network switch side since the original install. I also see in em(4) that the driver has been reworked for 12.0, so maybe this is due to a code change? This is running on hardware Dell R610 with a 4-port Intel PCIe NIC card em0@pci0:6:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 em1@pci0:6:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 em2@pci0:7:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 em3@pci0:7:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet $ freebsd-version -ku 12.0-ALPHA2 12.0-ALPHA2 $uname -a FreeBSD f-current239.sjelab.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 r338153: Tue Aug 21 21:02:41 UTC 2018 root@f-current239.sjelab.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC Relevant network config bits from /etc/rc.conf ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" defaultrouter="100.79.136.1" ifconfig_em1="inet6 2600:c02:b020:136::239 prefixlen 64" ipv6_defaultrouter="2600:c02:b020:136::2" $ ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=81049b ether a0:36:9f:30:de:ad inet6 fe80::a236:9fff:fe3d:ead%em1 prefixlen 64 scopeid 0x6 inet6 2600:c02:b020:136::239 prefixlen 64 media: Ethernet autoselect (1000baseT ) status: active nd6 options=21 More details are available if needed. Thanks, andreas -- Andreas Ott K6OTT +1.408.431.8727 andreas@naund.org From owner-freebsd-current@freebsd.org Wed Aug 22 20:30: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 C063510951AC for ; Wed, 22 Aug 2018 20:30:50 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 308F48A5AC for ; Wed, 22 Aug 2018 20:30:50 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf1-x12e.google.com with SMTP id c21-v6so2376779lfh.3 for ; Wed, 22 Aug 2018 13:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u8PuyQqOFtgt1prfnoFQ/sGkzz4a/vk3Xms0qo8Uceg=; b=tG/NvvmlzV+0eHa0Nuav0UkwBRQziecEhYOXfYudLFfEkHXbA7SdmqmThtzEgVStg5 VMfIclEQs/qsH7o9W2lf7h/tHy2ZKFvEuvjYzjg96ncJ/zG3Fos5drMU4zN1OaT+lfWq 6RqCyCCW8yHCT9eZFU2BrkWeNIeTSxTpQrob4LZvbxOjju8SUnVRoaqLgB23T68KMTMD zZ6bIAv2pkAl+Hz1Ic4Jscs3gKN13190kKmg9wqTOy5r8qZxHi9Ro102Tn+xGU7oV3vz w9bvn5LM8dfWKmtexjj23fpgfKKuRPC60k/58fzPbA4mGHmO34vkh+VE1Gu6uM0OdND/ L8Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u8PuyQqOFtgt1prfnoFQ/sGkzz4a/vk3Xms0qo8Uceg=; b=T8qgmiGzMV4nj1fJmLFDdL0WPsJrpGLZEkjpjL37HS7xuwr7HpoNi5unnsR+kFRtoP j9UGjGmSNskhKouykzKIlvIsUpqWYYiQANZ2dgLU68Q0x0wOaNEeeGRlydLXJQZlCcsb Fs4xrrnd3a0dqCYUWNRLs6cLlF3i8Q0QZdIjgHir2w2355mLd8infzPY5gaQgVj3Ev83 Ygr/aqWtTQdsVdu7FKYRS/tlo5Jzs/bJCCMfQqFhNBn0lEAyJpgLaNpuuYl2BRlahmsZ g0Y8E8Mvf8yYjz9mRvh9zI/lq62eGjtpODHBEV2WzLUoctMwCdwALdFA9S0eI3fBWis7 FvmA== X-Gm-Message-State: APzg51A1NzBNKiMJyw0PIMDdlgnyExjY8l2Pa8QfTR3X0senZ6BdT9CS hO518R80MLnvLpJ1TMGzaaFbE7pasKaddGLr1mM1vhU7 X-Google-Smtp-Source: ANB0Vda/T1sLd0AbWTJjswuApd64HxPkKt3C45xK7CEb99CiRGJ7c/R+haVETVY1e4QfiBTUirVvrRZ9lSWNwqZXMdg= X-Received: by 2002:a19:730d:: with SMTP id o13-v6mr5370827lfc.130.1534969848846; Wed, 22 Aug 2018 13:30:48 -0700 (PDT) MIME-Version: 1.0 References: <20180822132135.A9818@naund.org> In-Reply-To: <20180822132135.A9818@naund.org> From: Freddie Cash Date: Wed, 22 Aug 2018 13:30:37 -0700 Message-ID: Subject: Re: timing issue with ifconfig em(4) at rc.d start? To: andreas@naund.org Cc: FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 20:30:51 -0000 On Wed, Aug 22, 2018 at 1:25 PM Andreas Ott wrote: > Yesterday I installed a server from scratch from image > FreeBSD-12.0-ALPHA2-amd64-20180816-r337934-memstick.img, > then I updated sources with svn and did make buildworld, buildkernel, > installkernel, installworld, mergemaster. Upon reboot I can no longer > talk to the server on IPv4 but it works on IPv6, ifconfig tells me > there is no 'inet' address configured. No IPv4 inet routes are in > place either. > > If I run '/etc/rc.d/netif restart' from root shell on KVM console, I can > observe that the interface is taken down, the link light goes dark, > and then comes back up. However the "UP" log notification appears in > time *after* ifconfig attempts to apply settings to an interface > that is still down as it prints out to screen (em1 is shown there > as 'status: no carrier' at the time). > > em1: link state changed to DOWN > > > > Link state changed to up > em1: link state changed to UP > > Is there a way to delay the 'ifconfig inet' until after the link light > comes up? Or how do I force configuring an interface that's down in rc? > Nothing changed on the configuration side or the network switch > side since the original install. I also see in em(4) that the driver > has been reworked for 12.0, so maybe this is due to a code change? > > > This is running on hardware Dell R610 with a 4-port Intel PCIe NIC card > > em0@pci0:6:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em1@pci0:6:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em2@pci0:7:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > em3@pci0:7:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > > > $ freebsd-version -ku > 12.0-ALPHA2 > 12.0-ALPHA2 > > $uname -a > FreeBSD f-current239.sjelab.net 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 > r338153: Tue Aug 21 21:02:41 UTC 2018 root@f-current239.sjelab.net: > /usr/obj/usr/src/amd64.amd64/sys/GENERIC > > Relevant network config bits from /etc/rc.conf > > ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" > defaultrouter="100.79.136.1" > ifconfig_em1="inet6 2600:c02:b020:136::239 prefixlen 64" > ipv6_defaultrouter="2600:c02:b020:136::2" > There's nothing wrong with the timing. Your rc.conf is incorrect. The second ifconfig_em1 line overrides the former. These are variable declarations, not commands. The last setting for a variable is the only one that takes place. Either look through /etc/defaults/rc.conf for the ipv6-related entries, or switch to using an alias entry for ipv6: ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" ifconfig_em1_alias0="inet6 2600:c02:b020:136::239 prefixlen 64" -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@freebsd.org Wed Aug 22 20:38:28 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 E8D0E10956B0 for ; Wed, 22 Aug 2018 20:38:27 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A9368B038 for ; Wed, 22 Aug 2018 20:38:27 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4A22217363 for ; Wed, 22 Aug 2018 20:38:27 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-pf1-f172.google.com with SMTP id x17-v6so1521429pfh.5 for ; Wed, 22 Aug 2018 13:38:27 -0700 (PDT) X-Gm-Message-State: AOUpUlG0cYvWArn1WYyj+ULEYGvbqFn4qQ3sYPx7VnZfDD+Y4hNLEt5H xkA7y1IuAtuv+j8DV1CQiIKbb5gYiauV3WOn9lc= X-Google-Smtp-Source: AA+uWPwnS2gko34Vf89XeKLskLVjIIe8fO1NbtRuzqwAehuX3bSd0XSRDiM/98H2wA51iZf0opo/yqcgGuU2nQB8IrE= X-Received: by 2002:a62:89d8:: with SMTP id n85-v6mr59089395pfk.83.1534970306197; Wed, 22 Aug 2018 13:38:26 -0700 (PDT) MIME-Version: 1.0 References: <20180821113051.7d35bc39@x23> In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Wed, 22 Aug 2018 22:38:13 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related To: "Bjoern A. Zeeb" Cc: Marko Zec , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 20:38:28 -0000 On Tue, Aug 21, 2018 at 3:15 PM Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On 21 Aug 2018, at 12:31, Olivier Cochard-Labb=C3=A9 wrote: > > > Do you have a last-good revision? > > > Hi, Since VIMAGE was enabled by default on GENERIC (r327969). So perhaps VIMAGE+carp never works on i386 ? From owner-freebsd-current@freebsd.org Wed Aug 22 21:15: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 ED2FC10960D9 for ; Wed, 22 Aug 2018 21:15:39 +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 785F18CE04; Wed, 22 Aug 2018 21:15:39 +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 w7MLFSd4041013 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Aug 2018 00:15:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7MLFSd4041013 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7MLFSPX041007; Thu, 23 Aug 2018 00:15:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 Aug 2018 00:15:28 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180822211528.GB2340@kib.kiev.ua> References: <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 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, 22 Aug 2018 21:15:40 -0000 On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote: > > > > On 22. Aug 2018, at 17:46, Konstantin Belousov wrote: > > > >> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: > >> > >> > >>>> On 20. Aug 2018, at 17:09, Konstantin Belousov wrote: > >>>> > >>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: > >>>> > >>>> See here for a screenshot (also including the output of "show pte > >>>> 0xfffff80001000000"): > >>>> > >>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png > >>> It is too early for ddb routines to register. > >>> Ok can you try the following debugging patch, to verify my guess ? > >>> > >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > >>> index 18777d23f09..cd05fdb763f 100644 > >>> --- a/sys/amd64/amd64/pmap.c > >>> +++ b/sys/amd64/amd64/pmap.c > >>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) > >>> pd_p = (pd_entry_t *)DMPDkernphys; > >>> for (i = 0; i < (NPDEPG * nkdmpde); i++) > >>> pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | > >>> - X86_PG_M | X86_PG_A | pg_nx | > >>> - bootaddr_rwx(i << PDRSHIFT); > >>> + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; > >>> for (i = 0; i < nkdmpde; i++) > >>> pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW | > >>> X86_PG_V; > >> > >> With this change it boots okay (mptramp_pagetables is 0x1000000, as expected). > > > > Can you apply the following on top of the previous debugging patch and show > > me the line printed ? > > > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > > index 3d70532b7fd..613fa9f2165 100644 > > --- a/sys/amd64/amd64/pmap.c > > +++ b/sys/amd64/amd64/pmap.c > > @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) > > pmap->pm_pcids[i].pm_gen = 1; > > } > > pmap_activate_boot(pmap); > > +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx etext %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uintptr_t)KERNBASE); > > } > > > > void > > bootaddr addr 0x1000000 rwx 0 btext 0xffffffff80342000 _end 0xffffffff823cf840 brwsection #ffffffff81a00000 etext 0xffffffff812041e4 KERNBASE 0xffffffff80000000 > Try this, please. Revert all debugging pmap.c patches that I provided before. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 4ca2e07e578..2ee8f862854 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); #define GiB(v) (v ## ULL << 30) +#define AP_BOOTPT_SZ (PAGE_SIZE * 3) + extern struct pcpu __pcpu[]; /* Temporary variables for init_secondary() */ @@ -101,45 +103,78 @@ char *dbg_stack; static int start_ap(int apic_id); +static bool +is_kernel_paddr(vm_paddr_t pa) +{ + + return (pa >= trunc_2mpage(btext - KERNBASE) && + pa < round_page(_end - KERNBASE)); +} + +static bool +is_mpboot_good(vm_paddr_t start, vm_paddr_t end) +{ + + return (start + AP_BOOTPT_SZ <= GiB(4) && + end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem); +} + /* * Calculate usable address in base memory for AP trampoline code. */ void mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) { + vm_paddr_t start, end; unsigned int i; bool allocated; alloc_ap_trampoline(physmap, physmap_idx); + /* + * Find a memory region big enough below the 4GB boundary to + * store the initial page tables. Region must be mapped by + * the direct map. + * + * Note that it needs to be aligned to a page boundary. + */ allocated = false; for (i = *physmap_idx; i <= *physmap_idx; i -= 2) { /* - * Find a memory region big enough below the 4GB - * boundary to store the initial page tables. Region - * must be mapped by the direct map. - * - * Note that it needs to be aligned to a page - * boundary. + * First, try to chomp at the start of the physmap region. + * Kernel binary might claim it already. + */ + start = round_page(physmap[i]); + end = trunc_page(physmap[i + 1]); + if (is_mpboot_good(start, end) && + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { + allocated = true; + physmap[i] = start + AP_BOOTPT_SZ; + break; + } + + /* + * Second, try to chomp at the end. Again, check + * against kernel. */ - if (physmap[i] >= GiB(4) || physmap[i + 1] - - round_page(physmap[i]) < PAGE_SIZE * 3 || - atop(physmap[i + 1]) > Maxmem) - continue; - - allocated = true; - mptramp_pagetables = round_page(physmap[i]); - physmap[i] = round_page(physmap[i]) + (PAGE_SIZE * 3); + end = trunc_page(physmap[i + 1]); + start = end - AP_BOOTPT_SZ; + if (start >= physmap[i] && is_mpboot_good(start, end) && + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { + allocated = true; + physmap[i + 1] = start; + break; + } + } + if (allocated) { + mptramp_pagetables = start; if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) { memmove(&physmap[i], &physmap[i + 2], sizeof(*physmap) * (*physmap_idx - i + 2)); *physmap_idx -= 2; } - break; - } - - if (!allocated) { - mptramp_pagetables = trunc_page(boot_address) - (PAGE_SIZE * 3); + } else { + mptramp_pagetables = trunc_page(boot_address) - AP_BOOTPT_SZ; if (bootverbose) printf( "Cannot find enough space for the initial AP page tables, placing them at %#x", From owner-freebsd-current@freebsd.org Wed Aug 22 21:39: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 07B0C1096A3E for ; Wed, 22 Aug 2018 21:39:10 +0000 (UTC) (envelope-from andreas@naund.org) Received: from naund.org (172-11-194-172.lightspeed.sntcca.sbcglobal.net [172.11.194.172]) by mx1.freebsd.org (Postfix) with ESMTP id 4F64F8E089 for ; Wed, 22 Aug 2018 21:39:08 +0000 (UTC) (envelope-from andreas@naund.org) Received: (from andreas@localhost) by naund.org (8.11.6/8.11.6-20030329ao) id w7MLd6w11492; Wed, 22 Aug 2018 14:39:06 -0700 Date: Wed, 22 Aug 2018 14:39:06 -0700 From: Andreas Ott To: Freddie Cash Cc: freebsd-current@freebsd.org Subject: Re: timing issue with ifconfig em(4) at rc.d start? Message-ID: <20180822143906.U998@naund.org> References: <20180822132135.A9818@naund.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from fjwcash@gmail.com on Wed, Aug 22, 2018 at 01:30:37PM -0700 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 21:39:10 -0000 Hi, On Wed, Aug 22, 2018 at 01:30:37PM -0700, Freddie Cash wrote: > There's nothing wrong with the timing. Your rc.conf is incorrect. > > The second ifconfig_em1 line overrides the former. These are variable > declarations, not commands. The last setting for a variable is the only > one that takes place. Thanks for pointing this out. Sorry for the noise, I was able to track this down to a scripting error that placed the lines into my /etc/rc.conf . > Either look through /etc/defaults/rc.conf for the ipv6-related entries, or > switch to using an alias entry for ipv6: > > ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" > ifconfig_em1_alias0="inet6 2600:c02:b020:136::239 prefixlen 64" I think the inet6 syntax from the sample in /etc/defaults/rc.conf and after reading more in rc.conf(5) would be ifconfig_em1="inet 100.79.136.239 netmask 255.255.255.0 up" ifconfig_em1_ipv6="inet6 2600:c02:b020:136::239 prefixlen 64" and I can confirm that after making the change this now works. -andreas From owner-freebsd-current@freebsd.org Wed Aug 22 22:10:38 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 0115010978EB for ; Wed, 22 Aug 2018 22:10:38 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 5A5338FDB6 for ; Wed, 22 Aug 2018 22:10:37 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 98583 invoked by uid 89); 22 Aug 2018 22:10:36 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 22 Aug 2018 22:10:36 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180822211528.GB2340@kib.kiev.ua> Date: Thu, 23 Aug 2018 00:10:34 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> References: <07E28AC5-EBE6-4893-810A-6C03F07925C8@grem.de> <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> <20180822211528.GB2340@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 22:10:38 -0000 > On 22. Aug 2018, at 23:15, Konstantin Belousov wrote= : >=20 >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote: >>=20 >>=20 >>>> On 22. Aug 2018, at 17:46, Konstantin Belousov wr= ote: >>>>=20 >>>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: >>>>=20 >>>>=20 >>>>>> On 20. Aug 2018, at 17:09, Konstantin Belousov w= rote: >>>>>>=20 >>>>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: >>>>>>=20 >>>>>> See here for a screenshot (also including the output of "show pte >>>>>> 0xfffff80001000000"): >>>>>>=20 >>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-= ddb1-png >>>>> It is too early for ddb routines to register. >>>>> Ok can you try the following debugging patch, to verify my guess ? >>>>>=20 >>>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>>>> index 18777d23f09..cd05fdb763f 100644 >>>>> --- a/sys/amd64/amd64/pmap.c >>>>> +++ b/sys/amd64/amd64/pmap.c >>>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) >>>>> pd_p =3D (pd_entry_t *)DMPDkernphys; >>>>> for (i =3D 0; i < (NPDEPG * nkdmpde); i++) >>>>> pd_p[i] =3D (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | >>>>> - X86_PG_M | X86_PG_A | pg_nx | >>>>> - bootaddr_rwx(i << PDRSHIFT); >>>>> + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; >>>>> for (i =3D 0; i < nkdmpde; i++) >>>>> pdp_p[i] =3D (DMPDkernphys + ptoa(i)) | X86_PG_RW | >>>>> X86_PG_V; >>>>=20 >>>> With this change it boots okay (mptramp_pagetables is 0x1000000, as exp= ected). >>>=20 >>> Can you apply the following on top of the previous debugging patch and s= how >>> me the line printed ? >>>=20 >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>> index 3d70532b7fd..613fa9f2165 100644 >>> --- a/sys/amd64/amd64/pmap.c >>> +++ b/sys/amd64/amd64/pmap.c >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) >>> pmap->pm_pcids[i].pm_gen =3D 1; >>> } >>> pmap_activate_boot(pmap); >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#l= x etext %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (uint= ptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uint= ptr_t)KERNBASE); >>> } >>>=20 >>> void >>=20 >> bootaddr addr 0x1000000 rwx 0 btext 0xffffffff80342000 _end 0xffffffff823= cf840 brwsection #ffffffff81a00000 etext 0xffffffff812041e4 KERNBASE 0xfffff= fff80000000 >>=20 >=20 > Try this, please. Revert all debugging pmap.c patches that I provided > before. >=20 > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c > index 4ca2e07e578..2ee8f862854 100644 > --- a/sys/amd64/amd64/mp_machdep.c > +++ b/sys/amd64/amd64/mp_machdep.c > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); >=20 > #define GiB(v) (v ## ULL << 30) >=20 > +#define AP_BOOTPT_SZ (PAGE_SIZE * 3) > + > extern struct pcpu __pcpu[]; >=20 > /* Temporary variables for init_secondary() */ > @@ -101,45 +103,78 @@ char *dbg_stack; >=20 > static int start_ap(int apic_id); >=20 > +static bool > +is_kernel_paddr(vm_paddr_t pa) > +{ > + > + return (pa >=3D trunc_2mpage(btext - KERNBASE) && > + pa < round_page(_end - KERNBASE)); > +} > + > +static bool > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end) > +{ > + > + return (start + AP_BOOTPT_SZ <=3D GiB(4) && > + end >=3D start + AP_BOOTPT_SZ && atop(end) < Maxmem); > +} > + > /* > * Calculate usable address in base memory for AP trampoline code. > */ > void > mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) > { > + vm_paddr_t start, end; > unsigned int i; > bool allocated; >=20 > alloc_ap_trampoline(physmap, physmap_idx); >=20 > + /* > + * Find a memory region big enough below the 4GB boundary to > + * store the initial page tables. Region must be mapped by > + * the direct map. > + * > + * Note that it needs to be aligned to a page boundary. > + */ > allocated =3D false; > for (i =3D *physmap_idx; i <=3D *physmap_idx; i -=3D 2) { > /* > - * Find a memory region big enough below the 4GB > - * boundary to store the initial page tables. Region > - * must be mapped by the direct map. > - * > - * Note that it needs to be aligned to a page > - * boundary. > + * First, try to chomp at the start of the physmap region. > + * Kernel binary might claim it already. > + */ > + start =3D round_page(physmap[i]); > + end =3D trunc_page(physmap[i + 1]); > + if (is_mpboot_good(start, end) && > + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > + allocated =3D true; > + physmap[i] =3D start + AP_BOOTPT_SZ; > + break; > + } > + > + /* > + * Second, try to chomp at the end. Again, check > + * against kernel. > */ > - if (physmap[i] >=3D GiB(4) || physmap[i + 1] - > - round_page(physmap[i]) < PAGE_SIZE * 3 || > - atop(physmap[i + 1]) > Maxmem) > - continue; > - > - allocated =3D true; > - mptramp_pagetables =3D round_page(physmap[i]); > - physmap[i] =3D round_page(physmap[i]) + (PAGE_SIZE * 3); > + end =3D trunc_page(physmap[i + 1]); > + start =3D end - AP_BOOTPT_SZ; > + if (start >=3D physmap[i] && is_mpboot_good(start, end) && > + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > + allocated =3D true; > + physmap[i + 1] =3D start; > + break; > + } > + } > + if (allocated) { > + mptramp_pagetables =3D start; > if (physmap[i] =3D=3D physmap[i + 1] && *physmap_idx !=3D 0) { > memmove(&physmap[i], &physmap[i + 2], > sizeof(*physmap) * (*physmap_idx - i + 2)); > *physmap_idx -=3D 2; > } > - break; > - } > - > - if (!allocated) { > - mptramp_pagetables =3D trunc_page(boot_address) - (PAGE_SIZE * 3)= ; > + } else { > + mptramp_pagetables =3D trunc_page(boot_address) - AP_BOOTPT_SZ; > if (bootverbose) > printf( > "Cannot find enough space for the initial AP page tables, placing them at %= #x", Reverted back to r337813 and applied the patch. Unfortunately it panics just= like before. Adding back physmap debugging like before shows that it=E2=80=99= s still using pages 0x1000-0x1003 (Stopped at native_start_all_aps+0x92: mov= q %rax,(%rsi)) Best, Michael From owner-freebsd-current@freebsd.org Wed Aug 22 22:39:31 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 33B6B1098335; Wed, 22 Aug 2018 22:39:31 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D665B710C2; Wed, 22 Aug 2018 22:39:30 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 9D62217F85; Wed, 22 Aug 2018 22:39:30 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f172.google.com with SMTP id l7-v6so2769117iok.6; Wed, 22 Aug 2018 15:39:30 -0700 (PDT) X-Gm-Message-State: AOUpUlFDBUy/tgXYwiysgJL5Q3SyB75azOiAknhx2XTrW4CZjHzOLsbj 1QgpyJWNVvO3G8SI8Twm8WCFxwS5FnvqYTCUqqs= X-Google-Smtp-Source: AA+uWPzqbDc7LZoKBasb7hYMlKHLigBcLUGefosuFtCCFKnKyC18ItL9dcz1+QAk9ClC6Mj2xdkRpGPkqKbb6TK9jmE= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr22683138iog.132.1534977570060; Wed, 22 Aug 2018 15:39:30 -0700 (PDT) MIME-Version: 1.0 References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> In-Reply-To: From: Matthew Macy Date: Wed, 22 Aug 2018 15:39:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: tcaputi@datto.com Cc: Sean Fagan , Alan Somers , freebsd-current , freebsd-fs Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 22:39:31 -0000 Hi Thomas, Alan believes that, even with dedup disabled, the ZFS native encryption support is vulnerable to watermarking attacks. I don't have enough exposure to crypto to pass any judgement and was hoping that you'd share your point of view. Thanks in advance. -M On Wed, Aug 22, 2018 at 12:42 PM Alan Somers wrote: > Only encrypting L0 blocks also leaks a lot of information. That means > that, if encryption is set to anything but "off", watermarking attacks will > still be possible based on the size and sparsity of a file. Because I > believe that with any encryption mode, ZFS turns continuous runs of zeros > into holes. And I don't see anything in zio_crypt.c that addresses that. > -Alan > > On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan wrote: > >> On Aug 22, 2018, at 12:20 PM, Alan Somers wrote: >> > ]That doesn't answer the question about what happens when dedup is >> turned off. In that case, is the HMAC still used as the IV? If so, then >> watermarking attacks are still possible. If ZFS switches to a random IV >> when dedup is off, then it would probably be ok. >> >> From the same file: >> >> * Initialization Vector (IV): >> >> * An initialization vector for the encryption algorithms. This is used >> to >> * "tweak" the encryption algorithms so that two blocks of the same data >> are >> * encrypted into different ciphertext outputs, thus obfuscating block >> patterns. >> * The supported encryption modes (AES-GCM and AES-CCM) require that an >> IV is >> * never reused with the same encryption key. This value is stored >> unencrypted >> * and must simply be provided to the decryption function. We use a 96 >> bit IV >> * (as recommended by NIST) for all block encryption. For non-dedup >> blocks we >> * derive the IV randomly. The first 64 bits of the IV are stored in the >> second >> * word of DVA[2] and the remaining 32 bits are stored in the upper 32 >> bits of >> * blk_fill. This is safe because encrypted blocks can't use the upper 32 >> bits >> * of blk_fill. We only encrypt level 0 blocks, which normally have a >> fill count >> * of 1. The only exception is for DMU_OT_DNODE objects, where the fill >> count of >> * level 0 blocks is the number of allocated dnodes in that block. The >> on-disk >> * format supports at most 2^15 slots per L0 dnode block, because the >> maximum >> * block size is 16MB (2^24). In either case, for level 0 blocks this >> number >> * will still be smaller than UINT32_MAX so it is safe to store the IV in >> the >> * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fill >> count >> * for the dnode code. >> >> >> Sean >> >> >> From owner-freebsd-current@freebsd.org Wed Aug 22 23:02: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 20B971098E0C for ; Wed, 22 Aug 2018 23:02:55 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) Received: from sonic305-21.consmr.mail.ir2.yahoo.com (sonic305-21.consmr.mail.ir2.yahoo.com [77.238.177.83]) (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 9AF527246B for ; Wed, 22 Aug 2018 23:02:54 +0000 (UTC) (envelope-from p.gunnarsson@yahoo.com) X-YMail-OSG: aNTRvjkVM1mb5MGne3lPU_JwojXv1POfEvR35OwjicOO8AZ3wS4vGIUudnhKoQK Dcvj2V2v7p72o9mYNso9VfgpqyrYg1J3Gz2t4Xwl0pzARbYb1oBdorNYGokvrySGOpr9a7J_j540 F7zqtvOFXaFKXANGwOSFuTSdjUvpSicg6.c2tI_NIJw0pGai.SQJolLLPtlDDNcEr9EjFy5SI22k DdLpvoCkehx.HErI1EPQN0Pn2RGdbZmpEV3S7Hc.zxHi77dFVkda8pAK6YpmnwyKx_PUpW2aBLmB yrMgJnuNpHxCYzRUVoH_pGUvbI4lfcC1IBgMX47kBIG4zExpKrcKCiLW5lPXaPvmW3182uf1pckT 8Xj3hMCB2H_PFiyvNGl9USHPHp3RX5ojq3jDo4E9XQVS1PSO3i1_8fifeUPk_wVHIAJPPEQkBMvA p045Qvpz_mxdQ1_..DraczgbE34ktR402A.1fAHqdAYqAvVwY9R4sS6fbhT6bLxDDkDWZrGrgn7J tsAYTEaUdqw20e0QoAfDwmS_dwfXC.E.ttZF_XN72vVI4LaYdPDeDMXV0aEhgebK3Vve7bJ7fGwm hM5.xyFk6IDgxrTf9csbiwwr_r1JdUVFcN3K1JOAxHjpCUH4zSaAxRCSM8tclNrL.kjdK_uEBlue mMeE1W0QZJJNgWNf3eRAf9VWPqmxncNCfUJwzc80y.it5cHluaGFX1SQZOnfpbrfwTu5dbgQrfmT SPu1HU4dxG1iAOhc_LDF7nxkcTu.3LRCuLOxZlEcRdv588LBwcybnuDvIbK4pQEesa..dTGxEAdZ Qnqup9SsMmceDb3bEOjBnEBRcphfGhq8LOpxzDtcCuVmi43VU7sXgGI4zRSXG9zAlwmBNxRip8l6 jNJWHzOAQh9N47W5SmjxuTJH31eH_l2miKXMV8t0Ne0wfhxK08XFCoEjOi7m7HnCnKoK.pPyJ4dR cDyY4Yc0gC69tjNWPc._sWtBH2BLjmBmPia2V70C6_1fHKAnzrfGXi7o0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Wed, 22 Aug 2018 23:02:46 +0000 Received: from 108.161.151.160 (EHLO [188.125.73.26]) ([108.161.151.160]) by smtp411.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 32ca76965cf37128d9766a526f61fe29 for ; Wed, 22 Aug 2018 23:02:44 +0000 (UTC) From: Per Gunnarsson Subject: Fatal trap 12 when booting with fuse in /boot/loader.conf To: freebsd-current Message-ID: Date: Thu, 23 Aug 2018 01:02:40 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 23:02:55 -0000 Sorry for possibly mentioning this twice. FreeBSD konjak 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 r338177: Wed Aug 22 08:46:40 CEST 2018     root@konjak:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64 /usr/src Revision: 338177 /usr/ports Revision: 477773 When I try to boot with the fuse module in /boot/loader.conf I get something like this: Fatal trap 12: ... fault virtual address = 0xcd instruction pointer = 0x20:0xffffffff80eec062 stack pointer = 0x20:0xffffffff8420e580 frame pointer = 0x20:0xffffffff8420e670 ... Then there is a prompt: db> or something, but it doesn't respond to keyboard input and I have to reboot. Somehow I managed to unload all modules from the boot prompt and reboot. After that, I rebooted without the fuse module in /boot/loader.conf and things work fine. I have tried to boot again with fuse in /boot/loader.conf, and the first boot I get to a mountroot prompt which I am now reading up on. Maybe this is the same as Michael Gmelin is working on. Regards, Per Gunnarsson From owner-freebsd-current@freebsd.org Wed Aug 22 23:08:57 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 980971098FE3 for ; Wed, 22 Aug 2018 23:08:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 207F272D6D; Wed, 22 Aug 2018 23:08:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (static-71-168-218-4.cmdnnj.fios.verizon.net [71.168.218.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C750F18292; Wed, 22 Aug 2018 23:08:56 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: EFI issues To: Warner Losh , "O. Hartmann" Cc: Roman Bogorodskiy , FreeBSD Current , Toomas Soome , "Rodney W. Grimes" , Allan Jude References: <20180728072938.GA28778@kloomba> <20180729094502.180dabc0@thor.intern.walstatt.dynvpn.de> <20180729080957.GB2216@kloomba> <20180729105550.4ac8711a@thor.intern.walstatt.dynvpn.de> <20180729111751.GC2216@kloomba> <20180729143529.16bad01a@thor.intern.walstatt.dynvpn.de> From: Jung-uk Kim Openpgp: preference=signencrypt Autocrypt: addr=jkim@FreeBSD.org; prefer-encrypt=mutual; keydata= xsBNBFJBztUBCAChqNyGqmFuNo0U7MBzsD+q/G6Cv0l7LGVrOAsgh34M8wIWhD+tztDWMVfn AhxNDd0ceCj2bYOe67sTQxAScEcbt2FfvPOLp9MEXb9qohZj172Gwkk7dnhOhZZKhVGVZKM4 NcsuBDUzgf4f3Vdzj4wg6WlqplnTZo8lPE4hZWvZHoFIyunPTJWenybeV1xnxK7JkUdSvQR0 fA59RfTTECMwTrSEfYGUnxIDBraxJ7Ecs/0hGQ7sljIj8WBvlRDU5fU1xfF35aw56T8POQRq F4E6RVJW3YGuTpSwgtGZOTfygcLRhAiq3dFC3JNLaTVTpM8PjOinJyt9AU6RoITGOKwDABEB AAHNHkp1bmctdWsgS2ltIDxqa2ltQEZyZWVCU0Qub3JnPsLAfQQTAQoAJwUCUkHO1QIbAwUJ E0/POwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRB8n5Ym/NvxRqyzB/wL7QtsIpeGfGIA ZPMtgXMucM3NWzomyQMln2j2efUkDKthzh9jBxgF53TjOr7imwIt0PT2k1bqctPrq5IRqnu9 mGroqaCLE3LG2/E3jEaao4k9PO6efwlioyivUo5NrqIQOQ4k3EAXw7d2y0Dk1VpTgdMrnUAB hj7lGlLqS4ydcrf24DdbCRGdEQwqd9DBeBgbWynxAJMgbZBhYVEyIHuQKkJ8qY0ibIPXXuF0 KYDeH0qUHtWV2K3srNyPtymUkBQD84Pl1GWRYx05XdUHDmnX0JV3lg0BfYJZgZv0ehPQrMfY Fd9abTkf9FHQYz1JtsC8wUuRgqElRd6+YAGf8Tt9zsBNBFJBztUBCADLtSrP44El2VoJmH14 OFrlOgxzZnbn+Y/Gf1k12mJBiR+A+pBeRLD50p7AiTrjHRxO3cHcl9Dh0uf1VSbXgp8Or0ye iP/86fZPd4k5HXNmDTLL0HecPE08SCqGZ0W8vllQrokB1QxxRUB+fFMPJyMCjDAZ7P9fFTOS dTw1bJSTtOD8Sx8MpZUa9ti06bXFlVYDlaqSdgk181SSx+ZbSKkQR8CIMARlHwiLsa3Z9q9O EJr20HPyxe0AlTvwvFndH61hg7ds63eRvglwRnNON28VXO/lvKXq7Br/CiiyhFdKfINIx2Z5 htYq22tgGTW7mBURbIKoECFBTX9Lv6BXz6w9ABEBAAHCwGUEGAEKAA8FAlJBztUCGwwFCRNP zzsACgkQfJ+WJvzb8UZcJQf+IsTCxUEqY7W/pT84sMg5/QD3s6ufTRncvq14fEOxCNq1Rf4Q 9P+tOFa8GZfKDGB2BFGIrW7uT5mlmKdK1vO6ZIA930y5kUsnCmBUEBJkE2ciSQk01aB/1o62 Q3Gk/F6BwtNY9OXiqF7AcAo+K/BMIaqb26QKeh+IIgK1NN9dQiq3ByTbl4zpGZa6MmsnnRTu mzGKt2nkz7vBzH6+hZp1OzGZikgjjhYWVFoJo1dvf/rv4obs0ZJEqFPQs/1Qa1dbkKBv6odB XJpPH0ssOluTY24d1XxTiKTwmWvHeQkOKRAIfD7VTtF4TesoZYkf7hsh3e3VwXhptSLFnEOi WwYofg== Message-ID: Date: Wed, 22 Aug 2018 19:08:50 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 23:08:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU Content-Type: multipart/mixed; boundary="aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV"; protected-headers="v1" From: Jung-uk Kim To: Warner Losh , "O. Hartmann" Cc: Roman Bogorodskiy , FreeBSD Current , Toomas Soome , "Rodney W. Grimes" , Allan Jude Message-ID: Subject: Re: EFI issues References: <20180728072938.GA28778@kloomba> <20180729094502.180dabc0@thor.intern.walstatt.dynvpn.de> <20180729080957.GB2216@kloomba> <20180729105550.4ac8711a@thor.intern.walstatt.dynvpn.de> <20180729111751.GC2216@kloomba> <20180729143529.16bad01a@thor.intern.walstatt.dynvpn.de> In-Reply-To: --aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 18. 8. 3., Warner Losh wrote: > On Sun, Jul 29, 2018 at 6:35 AM, O. Hartmann w= rote: >>>>> 'efibootmgr -v' output: >>>>> >>>>> BootCurrent: 0004 >>>>> Timeout : 1 seconds >>>>> BootOrder : 0001, 0002, 0003, 0004 >>>>> Boot0001* Hard Drive BBS(HD,,0x0) >>>>> Boot0002* Network Card BBS(Network,,0x0) >>>>> Boot0003* UEFI OS >>>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28, >> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI) >>>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null) >>>>> Path(0,0,ae84b11df581724e85442bab0c2cac5c020000020000) +Boot0004* >> UEFI: SanDisk >>>>> PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x4,0x0)/HD( >> 1,MBR,0x90909090,0x1,0x640) >>>>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6, >> 530061006e004400690073006b000000) >> > ... >=20 >>> I've updated BIOS (which alone didn't change anything) and executed >>> commands you suggested, and it helped! Thanks! >>> >>> Now 'efibootmgr -v' output looks like this: >>> >>> BootCurrent: 0000 >>> Timeout : 1 seconds >>> BootOrder : 0000, 0004, 0006, 0003, 0007 >>> +Boot0000* FreeBSD >>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28, >> 0x64000)/File(\efi\boot\BOOTx64.efi) >>> ada0p1:/efi/boot/BOOTx64.efi (null) Boot0004* Hard Drive BBS(HD,,0x0= ) >>> Boot0006* Network Card BBS(Network,,0x0) >>> Boot0003* UEFI OS >>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28, >> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI) >>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null) >>> Path(0,0,ef47642dc93ba041ac194d51d01b4ce65200650061006c00740065006b00= >> 200042006f006f00740020004100670065006e0074000000) >>> Boot0007* UEFI: SanDisk >>> PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/HD(1,MBR,0x90909090,0x1,0x640= ) >>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6, >> 340043003500330031003000300031003500340031003000310035003100 >> 300039003000390035000000) >>> >>> >>> Unreferenced Variables: >>> >>> This is strange, because the only difference I see is that Boot0000 h= as >>> lowercase filenames ('/efi/boot/BOOTx64.efi' vs >>> '/EFI/BOOT/BOOTX64.EFI'). I'm wondering if that's the only reason it >>> wasn't working before? >>> >>>> - -- >>>> O. Hartmann >> [...] >> >>> >>> Roman Bogorodskiy >> >> I'm glad to be of help. But it was a "wild guess", not experience or >> decend knowledge. >> Maybe there is an issue with recent UEFI/boot/stand implementation sin= ce >> this portion of >> FreeBSD is under heavy development or has been under such ... >> >> Ypu shpuld consider contacting Warner Losh or Toomas Soome (on the cur= rent@ >> list, there >> is a thread entitelt "[UEFI] Boot issues on some UEFI implementations"= >> started by myself >> targetting some weird FreeBSD/UEFI issues. Toomas Soome gave me the hi= nt >> with >> efibootmgr(8) and I figured out by learning from the definitions, that= on >> specific UEFI >> implementations, the boot path "/efi/boot/bootx64.efi" is considered t= he >> default for >> changeable media (like USB flash drives) and not necessaryly the defau= lt >> for SATA/SAS >> devices. >=20 >=20 > Case shouldn't matter. If it does, I've done something wrong. Internall= y, > we convert to lower case and the filesystem is case insensitive in this= > case. >=20 > The whole default file thing is something I thought I understood really= , > really well, but it's becoming clear that there's issues that are clear= as > mud. We should be coping with this junk in the installer... I had a similar problem with one of my boxes and the workaround, i.e., adding a duplicate entry with efibootmgr(8), fixed it for me, too. It seems the BIOS adds bogus data at the end. Bad variable added by BIOS: 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009 0000: 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00 0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68 0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29 0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 0070: 7f ff 04 00 aa 55 00 00 Good variable added by efibootmgr: 8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003 0000: 01 00 00 00 5e 00 55 00 45 00 46 00 49 00 20 00 0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68 0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29 0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02 0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 0050: 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00 0060: 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00 0070: 7f ff 04 00 Actually, "efibootmgr -v" hangs or crashes depending on current boot order. My guess is device path printing is not robust enough to ignore the bogus data. Jung-uk Kim --aVeG81pqBcdaTRNuZhjvrC3qRO5KZPFuV-- --IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlt97QcACgkQfJ+WJvzb 8UYyeQf/XIlVJu6nnnvLtndk3qQy4rRi6HGva0KPGtpBk4x9mkdH4FeamevRgkDj 4vcxuJBHg0GvKVXPg/vae8RoPFgsZ44/8T7qjJBOHOhz3XqQdN9hd8nMQFI6AHFp gFYFzzfA/2K8S3IhehoRDejhZog/3FoSB6V8tBftmYVY/AtGhpjJHzpDP4am9rZy fvI+SwGHeotz040hlabwkjKvu6xxTxyV99/XdSFsDTMJyU0k2xLd663olS7Sc89i rmPBVQYreOEasZ+SZ17x/LH26mb8c/ophNLlZvQZDpS4TWH6ujqQ5fy//e3yWpKm Dcn/dcfMz8dmXzPrNp68F6Sx9KLsdA== =zeRv -----END PGP SIGNATURE----- --IM5KIsqwgmx41lsnpLxyiKbh9eiwrVozU-- From owner-freebsd-current@freebsd.org Thu Aug 23 00:59:05 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 CBC1B109B127 for ; Thu, 23 Aug 2018 00:59:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 2C323760E8 for ; Thu, 23 Aug 2018 00:59:05 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 593 invoked by uid 89); 23 Aug 2018 00:59:04 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 23 Aug 2018 00:59:04 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12 when booting with fuse in /boot/loader.conf From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Thu, 23 Aug 2018 02:59:03 +0200 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Per Gunnarsson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 00:59:06 -0000 > On 23. Aug 2018, at 01:02, Per Gunnarsson wrote: >=20 > Sorry for possibly mentioning this twice. >=20 > FreeBSD konjak 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #0 r338177: Wed Aug 22 > 08:46:40 CEST 2018 =20 > root@konjak:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >=20 > /usr/src Revision: 338177 >=20 > /usr/ports Revision: 477773 >=20 > When I try to boot with the fuse module in /boot/loader.conf I get > something like this: >=20 > Fatal trap 12: >=20 > ... >=20 > fault virtual address =3D 0xcd > instruction pointer =3D 0x20:0xffffffff80eec062 > stack pointer =3D 0x20:0xffffffff8420e580 > frame pointer =3D 0x20:0xffffffff8420e670 >=20 > ... >=20 > Then there is a prompt: > db> >=20 > or something, but it doesn't respond to keyboard input and I have to reboo= t. >=20 > Somehow I managed to unload all modules from the boot prompt and reboot. > After that, I rebooted without the fuse module in /boot/loader.conf and > things work fine. >=20 > I have tried to boot again with fuse in /boot/loader.conf, and the first > boot I get to a mountroot > prompt which I am now reading up on. >=20 > Maybe this is the same as Michael Gmelin is working on. Most likely that=E2=80=99s a different problem. Did you try to reinstall the= fuse module from ports (make clean deinstall reinstall)? Can you check /boo= t for additional copies of the fuse module (recursively)? Does kldloading th= e fuse module after boot work? Best, Michael From owner-freebsd-current@freebsd.org Thu Aug 23 03:38:17 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 93F22109FE7A for ; Thu, 23 Aug 2018 03:38:17 +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 0F7757C7FC for ; Thu, 23 Aug 2018 03:38:16 +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 w7N3cRqV089832 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Aug 2018 20:38:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7N3cRMa089831; Wed, 22 Aug 2018 20:38:27 -0700 (PDT) (envelope-from fbsd) Date: Wed, 22 Aug 2018 20:38:27 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD Current , bob prohaska Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <20180823033827.GA89801@www.zefox.net> References: <170C703D-AA75-4EC9-93BA-D2CF3A7D6D5E@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170C703D-AA75-4EC9-93BA-D2CF3A7D6D5E@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 03:38:17 -0000 On Tue, Aug 21, 2018 at 06:47:19PM -0700, Mark Millard wrote: > > I've used a SSD both directly via SATA and via a USB enclosure, > the same partitions/file systems across the uses. Only when it > was SATA-style-use did TRIM work. > This is likely the key to my question. If USB blocks the TRIM service the behavior of the device doesn't matter. As an aside, Sandisk now says: "Please be informed that we have not tested running TRIM commands on USB flash drive and microSD cards therefore we would not be able to comment on it explicitly." Thanks for reading, bob prohaska From owner-freebsd-current@freebsd.org Thu Aug 23 06:52:36 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 C27C01083123; Thu, 23 Aug 2018 06:52:36 +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 792EC83BE9; Thu, 23 Aug 2018 06:52:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (unknown [51.52.172.98]) by mail.baldwin.cx (Postfix) with ESMTPSA id AAAB610A87D; Thu, 23 Aug 2018 02:52:29 -0400 (EDT) Subject: Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs To: Mark Millard , brd@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current References: <023C54F9-8660-40C5-8348-DD05D5C97B25@yahoo.com> From: John Baldwin Message-ID: <40a2a4a7-3e9b-2bba-6369-c9a6a017eca9@FreeBSD.org> Date: Thu, 23 Aug 2018 07:52:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <023C54F9-8660-40C5-8348-DD05D5C97B25@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 23 Aug 2018 02:52:30 -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.27 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, 23 Aug 2018 06:52:37 -0000 On 8/22/18 8:37 PM, Mark Millard wrote: > I'm just using this move as an example for some more > general questions. > > After this change when I look at: > > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html > > I see in the man page: > > FILES > /etc/devfs.conf > /usr/share/examples/etc/devfs.conf > > So . . . > > Roughly when are the "FreeBSD+12-current" man pages going to > track the moves? Once everything has been moved? > > Are the examples also going to be moved/reorganized? Similar > timing question to the above (if yes). The installed location of the files doesn't change, only their location in the source tree. It does seem that share/examples has not been handled to date, as they probably belong in the same package as the thing they are samples of. I really wish that the Makefiles were smart enough to use .PATH or some such to reach over into ${SRCTOP}/etc to find the files without requiring them to actually move in the tree since it's not very intuitive where to find many of these files now. (And the source locations are starting to no longer mimic the layout on the host, such as syslog.d being "flattened".) -- John Baldwin From owner-freebsd-current@freebsd.org Thu Aug 23 07:28: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 2213210842B4 for ; Thu, 23 Aug 2018 07:28:07 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2D8784F00 for ; Thu, 23 Aug 2018 07:28:06 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 724711B521 for ; Thu, 23 Aug 2018 07:28:06 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-pf1-f180.google.com with SMTP id j26-v6so2249163pfi.10 for ; Thu, 23 Aug 2018 00:28:06 -0700 (PDT) X-Gm-Message-State: AOUpUlH5MtfCETT6yse4ATLiFKgA4XzuGdlyIaoiSOjiEJ/NUGcQB/uX +aE576JU7cHloWFHkRLKhYKzzsQHFCfv3zSv2Fs= X-Google-Smtp-Source: AA+uWPw65vv1jmxZ/641rqSrvWQZxNLnu1naNY4wTP9gZSL1Fbzuqs5vzPx+dmnLHkhEXo0pc9WaIuBKqMEwddDCCHk= X-Received: by 2002:a62:45d2:: with SMTP id n79-v6mr61303882pfi.137.1535009285401; Thu, 23 Aug 2018 00:28:05 -0700 (PDT) MIME-Version: 1.0 References: <20180821113051.7d35bc39@x23> In-Reply-To: From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Thu, 23 Aug 2018 09:27:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Loading carp module crash i386 (12-ALPHA2), seems VNET related To: "Bjoern A. Zeeb" Cc: Marko Zec , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 07:28:07 -0000 On Wed, Aug 22, 2018 at 10:38 PM Olivier Cochard-Labb=C3=A9 wrote: > On Tue, Aug 21, 2018 at 3:15 PM Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> On 21 Aug 2018, at 12:31, Olivier Cochard-Labb=C3=A9 wrote: >> >> >> Do you have a last-good revision? >> >> >> Hi, > > > Since VIMAGE was enabled by default on GENERIC > > (r327969). > > So perhaps VIMAGE+carp never works on i386 ? > > My answer was not clear: - last good revision: r327968 - broken since: r327969 ("Enable VIMAGE in i386 GENERIC") From owner-freebsd-current@freebsd.org Thu Aug 23 03:22:05 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 76D30109F694 for ; Thu, 23 Aug 2018 03:22:05 +0000 (UTC) (envelope-from tcaputi@datto.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 064677BF4C for ; Thu, 23 Aug 2018 03:22:04 +0000 (UTC) (envelope-from tcaputi@datto.com) Received: by mail-oi0-x232.google.com with SMTP id q204-v6so6857721oig.9 for ; Wed, 22 Aug 2018 20:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datto-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gChVgyp9EnY8azFfwvDURSLkGC2mG2iBlJVCk2Dtj/o=; b=MeuPsbT8OPmbtxB5kBcElX/KM7m0oa1Bez2fDqtU3pFX00+Q9PeO44scC26aZaBzd1 Te1e0rVaXJDkSTct0oJuk2BlXfH+XlGDt/SlswhWrj9SU1vQ0tHoFXOI4w9icF+8uOwf nijgZMEx7K9RpZq+3TAch2W1r1/jronPdT78Xw5ZTzjEWuneR6Oi4tUj3aGpjUccq7sb KwPj2NyPIYgw327wW9alDAlFV1S7dbjtyv25j8Da4URSp7nL8DLLlZcKdBTkg/zSrqcY AY7Z/XoPsbEoyBb5WRo+QccZwYO+L8W7+LarirboI0TJAXQtyZZKzGJLa0PArQCjaUoe LToQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gChVgyp9EnY8azFfwvDURSLkGC2mG2iBlJVCk2Dtj/o=; b=lMpL3Ll2wlxM51Vq67/jKAY4C7oqgiQYlRRkvoI2XQhKJy4LZ5qchc0UZa1v/TyJ+X +pX+AnIsS9eaXbEoLk6i9W7YuDL9P/DiGZRAnTqCXutkvhKKsqaSpkPGfJ798yGNjFqQ Mku7HpPsjf1VU+COGtjHc4H361bJSknR4fIrPm9AaZGIDvwMfLk4oN+KGfSDZx7sKGcB T+XRwm8iRQlUBSjV1zAZAVeYKMu5rDBIoWFTn5W9QkdWkdCi8Met5/LWmrzV7ttMjlBy zO/gywsImuImVSatQD8iDSMP+6NMXH0zDXAI2CGKg7VKXqZZ7k3liSPFXcoMR/JfDV4f OG3Q== X-Gm-Message-State: APzg51AgumgBvCUr2fqSZjCA7yos9KISXNkigBq0nbowNHHKlXW55qOk 2+b+gXO0vbsZfP5QqLcZGpCmnsJXMk7ylzaskf4nhA== X-Google-Smtp-Source: ANB0VdY7IAlyN3YJmY4Rwt47wPz7ygUaoHjPs/JTS/QP7K5M/EiB/Sc+AH5+1zI04ryur54EBYslEwQI5dtc59kGMYY= X-Received: by 2002:aca:90d:: with SMTP id 13-v6mr6152825oij.300.1534994523936; Wed, 22 Aug 2018 20:22:03 -0700 (PDT) MIME-Version: 1.0 References: <9FDF249A-E320-4652-834E-7EEC5C4FB7CA@ixsystems.com> In-Reply-To: From: Thomas Caputi Date: Wed, 22 Aug 2018 23:21:53 -0400 Message-ID: Subject: Re: Native Encryption for ZFS on FreeBSD CFT To: mmacy@freebsd.org Cc: Sean Fagan , asomers@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 23 Aug 2018 10:42:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 03:22:05 -0000 > That doesn't answer the question about what happens when dedup is turned = off. In that case, is the HMAC still used as the IV? If so, then watermar= king attacks are still possible. Quoting the comment from the code above: "For non-dedup blocks we derive the IV randomly". When dedup is enabled, we do leak this information, but the dedup table already leaks that information anyway. The dedup table needs to be in plaintext so that we can repair it even when keys are not loaded. This is a known and documented trade off of using encryption + dedup. > Only encrypting L0 blocks also leaks a lot of information. That means th= at, if encryption is set to anything but "off", watermarking attacks will s= till be possible based on the size and sparsity of a file. Because I belie= ve that with any encryption mode, ZFS turns continuous runs of zeros into h= oles First of all, with encryption=3Doff, watermarking attacks are really quite easy :). The information that can be gained about a file from ZFS by looking at the raw disk are: 1) The size of the file (rounded up to the nearest sector size): Almost all applications that encrypt data will leak the approximate size of the protected payload. 2) The locations of holes within a file: ZFS does not turn runs of zeros into holes if you have compression off. However, data that is never written is maintained as a hole (ie if you never write any data to block 3 of a file). You are correct that technically this is a small leak of information, but we decided while designing the encryption scheme that the performance and space savings are worth it here. Is this enough information to be an attack vector? I would argue not, but if you are paranoid you could always turn compression off and fill in all the holes of your files with zeros. 3) If dedup is on, you can see which blocks have deduped against other blocks within a clone family. Encrypted dedup only works within applications that share the same master encryption key, which is essentially just snapshots and clones of snapshots. You cannot write data to one encrypted dataset and analyze the dedup tables to see i the data you wrote deduped against another dataset's data. 4) If compression + encryption is on a CRIME attack is possible, but in almost every scenario this attack is impractical. It requires the filesystem to have the key loaded, an application that appends a secret to the data controlled by an attacker, the attacker requires root access to the running system (to read the raw disk without rebooting and unloading the encryption key), and the attacker needs to be able to do many iterations of writing this attacker + secret data to disk and checking the resulting plaintext. During the implementation of native ZFS encryption we evaluated these and came to the conclusion that the security risks here are easily outweighed by the usability and performance benefits. If you have any further questions about the design, feel free to email me again or take a look at the (largely diagram based) docs on the implementation: https://docs.google.com/presentation/d/1km-z3MVNHYwlQLY6yEC3iq-TD05eredH9Ih= 4umGdkJw/edit?usp=3Dsharing On Wed, Aug 22, 2018 at 6:39 PM Matthew Macy wrote: > > Hi Thomas, > > Alan believes that, even with dedup disabled, the ZFS native encryption s= upport is vulnerable to watermarking attacks. I don't have enough exposure = to crypto to pass any judgement and was hoping that you'd share your point = of view. Thanks in advance. > > -M > > > > On Wed, Aug 22, 2018 at 12:42 PM Alan Somers wrote: >> >> Only encrypting L0 blocks also leaks a lot of information. That means t= hat, if encryption is set to anything but "off", watermarking attacks will = still be possible based on the size and sparsity of a file. Because I beli= eve that with any encryption mode, ZFS turns continuous runs of zeros into = holes. And I don't see anything in zio_crypt.c that addresses that. >> -Alan >> >> On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan wrote: >>> >>> On Aug 22, 2018, at 12:20 PM, Alan Somers wrote: >>> > ]That doesn't answer the question about what happens when dedup is tu= rned off. In that case, is the HMAC still used as the IV? If so, then wat= ermarking attacks are still possible. If ZFS switches to a random IV when = dedup is off, then it would probably be ok. >>> >>> From the same file: >>> >>> * Initialization Vector (IV): >>> * An initialization vector for the encryption algorithms. This is used= to >>> * "tweak" the encryption algorithms so that two blocks of the same dat= a are >>> * encrypted into different ciphertext outputs, thus obfuscating block = patterns. >>> * The supported encryption modes (AES-GCM and AES-CCM) require that an= IV is >>> * never reused with the same encryption key. This value is stored unen= crypted >>> * and must simply be provided to the decryption function. We use a 96 = bit IV >>> * (as recommended by NIST) for all block encryption. For non-dedup blo= cks we >>> * derive the IV randomly. The first 64 bits of the IV are stored in th= e second >>> * word of DVA[2] and the remaining 32 bits are stored in the upper 32 = bits of >>> * blk_fill. This is safe because encrypted blocks can't use the upper = 32 bits >>> * of blk_fill. We only encrypt level 0 blocks, which normally have a f= ill count >>> * of 1. The only exception is for DMU_OT_DNODE objects, where the fill= count of >>> * level 0 blocks is the number of allocated dnodes in that block. The = on-disk >>> * format supports at most 2^15 slots per L0 dnode block, because the m= aximum >>> * block size is 16MB (2^24). In either case, for level 0 blocks this n= umber >>> * will still be smaller than UINT32_MAX so it is safe to store the IV = in the >>> * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fil= l count >>> * for the dnode code. >>> >>> Sean >>> >>> From owner-freebsd-current@freebsd.org Thu Aug 23 11:22: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 859B3108A7AC for ; Thu, 23 Aug 2018 11:22:20 +0000 (UTC) (envelope-from me@janh.de) Received: from janh.de (janh.de [46.38.253.31]) (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 283018DE4A for ; Thu, 23 Aug 2018 11:22:20 +0000 (UTC) (envelope-from me@janh.de) Received: from pc1111.math.uni-hamburg.de (pc1111.math.uni-hamburg.de [134.100.220.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by janh.de (Postfix) with ESMTPSA id 2B665121E3C; Thu, 23 Aug 2018 13:12:02 +0200 (CEST) Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems To: bob prohaska , Mark Millard Cc: FreeBSD Current References: <170C703D-AA75-4EC9-93BA-D2CF3A7D6D5E@yahoo.com> <20180823033827.GA89801@www.zefox.net> From: Jan Henrik Sylvester Message-ID: <60ebe062-dfa8-66e2-1e65-de18918eb4a1@janh.de> Date: Thu, 23 Aug 2018 13:11:58 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180823033827.GA89801@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 11:22:20 -0000 On 8/23/18 5:38 AM, bob prohaska wrote: > On Tue, Aug 21, 2018 at 06:47:19PM -0700, Mark Millard wrote: >> >> I've used a SSD both directly via SATA and via a USB enclosure, >> the same partitions/file systems across the uses. Only when it >> was SATA-style-use did TRIM work. >> > This is likely the key to my question. If USB blocks the TRIM service > the behavior of the device doesn't matter. This is kind of off-topic in this thread about UFS, but if you investigate TRIM on USB enclosures: Some of them advertise TRIM support, for example Startech SM21BMU31C3 (based on Asmedia ASM1351 USB 3.1 Gen 2 chipset), but that is not the whole story. Using the UASP protocol, they pass on the ata trim command, which is used by Windows for NTFS trim support, but they do not pass the SCSI UNMAP command, which is used by Linux. Sorry, I have not yet tested this on FreeBSD, but on Linux, security erase of the entire SSD works with the enclosure I have just mentioned, whereas trimming of a filesystem (fstrim) does not work. I have had exactly one enclosure that offered trimming on filesystems on Linux: I have bought it on Ebay directly from China and I think it is based on JMicron JMS567 USB 3.0 chipset. I have not found an mSATA enclosure from any vendor in Europe that has this chipset. Of course, having the right chipset is not enough, either, the firmware also has to support it. Please, correct me if I am wrong, but I think FreeBSD does not implement UASP, yet. Hence, I doubt there will be any kind of trim support for any USB-SATA bridge on FreeBSD and even security erase will probably not be passed on. Cheers, Jan Henrik From owner-freebsd-current@freebsd.org Thu Aug 23 14:34:42 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 772EB108F523; Thu, 23 Aug 2018 14:34:42 +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 D153874B95; Thu, 23 Aug 2018 14:34:41 +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 w7NEYW1x089934; Thu, 23 Aug 2018 07:34:32 -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 w7NEYU3F089933; Thu, 23 Aug 2018 07:34:30 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808231434.w7NEYU3F089933@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs In-Reply-To: <40a2a4a7-3e9b-2bba-6369-c9a6a017eca9@FreeBSD.org> To: John Baldwin Date: Thu, 23 Aug 2018 07:34:30 -0700 (PDT) CC: Mark Millard , brd@freebsd.org, svn-src-head@freebsd.org, FreeBSD Current 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.27 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, 23 Aug 2018 14:34:42 -0000 > On 8/22/18 8:37 PM, Mark Millard wrote: > > I'm just using this move as an example for some more > > general questions. > > > > After this change when I look at: > > > > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html > > > > I see in the man page: > > > > FILES > > /etc/devfs.conf > > /usr/share/examples/etc/devfs.conf > > > > So . . . > > > > Roughly when are the "FreeBSD+12-current" man pages going to > > track the moves? Once everything has been moved? > > > > Are the examples also going to be moved/reorganized? Similar > > timing question to the above (if yes). > > The installed location of the files doesn't change, only their location > in the source tree. It does seem that share/examples has not been > handled to date, as they probably belong in the same package as the thing > they are samples of. > > I really wish that the Makefiles were smart enough to use .PATH or > some such to reach over into ${SRCTOP}/etc to find the files without > requiring them to actually move in the tree since it's not very > intuitive where to find many of these files now. (And the source > locations are starting to no longer mimic the layout on the host, > such as syslog.d being "flattened".) I believe it would of been possible, and not too much work, to leave all of it in ${SRCTOP}/etc by adding CONF-foo: targets that did the write things with variable settings and calling make ${SRCTOP}/etc/Makefile CONF-foo from the respective utilities. I also believe that certain of these files just belong in a pkg called etc, these are the files that are always needed for a functional system, like services (ok, if you remove all networking you do not need that one, but it clearly does not belong with the option services_mkdb that simply makes /var/db/services.db.) Anyway, any files that got moved into libc are always going to be installed, correct? I do not believe you can make a running system without libc, so why move them? Do we support a static link anymore? But when brd was asked what his plans where we got very little feedback, and now, what I feel is a poorly thought out implementation. By paint is blue.. always blue... -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Thu Aug 23 15:45: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 590021090F9B; Thu, 23 Aug 2018 15:45:58 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07B31773EE; Thu, 23 Aug 2018 15:45:58 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: brd/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id BB6651E7F2; Thu, 23 Aug 2018 15:45:57 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 65B8121FC9; Thu, 23 Aug 2018 11:45:57 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Thu, 23 Aug 2018 11:45:57 -0400 X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B24024212; Thu, 23 Aug 2018 11:45:56 -0400 (EDT) Message-Id: <1535039156.1411365.1483920736.1858661C@webmail.messagingengine.com> From: Brad Davis To: "Rodney W. Grimes" , John Baldwin Cc: Mark Millard , svn-src-head@freebsd.org, FreeBSD Current MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a References: <201808231434.w7NEYU3F089933@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201808231434.w7NEYU3F089933@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r338204 - in head: etc etc/defaults sbin/devfs Date: Thu, 23 Aug 2018 09:45:56 -0600 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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, 23 Aug 2018 15:45:58 -0000 On Thu, Aug 23, 2018, at 8:34 AM, Rodney W. Grimes wrote: > > On 8/22/18 8:37 PM, Mark Millard wrote: > > > I'm just using this move as an example for some more > > > general questions. > > > > > > After this change when I look at: > > > > > > https://www.freebsd.org/cgi/man.cgi?query=devfs.conf&apropos=0&sektion=5&manpath=FreeBSD+12-current&arch=default&format=html > > > > > > I see in the man page: > > > > > > FILES > > > /etc/devfs.conf > > > /usr/share/examples/etc/devfs.conf > > > > > > So . . . > > > > > > Roughly when are the "FreeBSD+12-current" man pages going to > > > track the moves? Once everything has been moved? > > > > > > Are the examples also going to be moved/reorganized? Similar > > > timing question to the above (if yes). > > > > The installed location of the files doesn't change, only their location > > in the source tree. It does seem that share/examples has not been > > handled to date, as they probably belong in the same package as the thing > > they are samples of. Yes, that was an oversight on my part that I am looking into. > > I really wish that the Makefiles were smart enough to use .PATH or > > some such to reach over into ${SRCTOP}/etc to find the files without > > requiring them to actually move in the tree since it's not very > > intuitive where to find many of these files now. (And the source > > locations are starting to no longer mimic the layout on the host, > > such as syslog.d being "flattened".) > > I believe it would of been possible, and not too much work, > to leave all of it in ${SRCTOP}/etc by adding CONF-foo: > targets that did the write things with variable settings > and calling make ${SRCTOP}/etc/Makefile CONF-foo from the > respective utilities. But we never had all files in etc/ consistently anyways, so this is kind of a moot point.. > I also believe that certain of these files just belong in > a pkg called etc, these are the files that are always needed > for a functional system, like services (ok, if you remove > all networking you do not need that one, but it clearly > does not belong with the option services_mkdb that simply > makes /var/db/services.db.) Anyway, any files that got > moved into libc are always going to be installed, correct? > I do not believe you can make a running system without > libc, so why move them? Do we support a static link anymore? It makes little sense to have an etc pkg and for people building embedded systems or thousands of jails.. Not to mention the people that will pkg delete FreeBSD-sendmail\* and want to see all the sendmail related configs gone as well. > But when brd was asked what his plans where we got very > little feedback, and now, what I feel is a poorly thought > out implementation. I held a session at BSDCan and in fact at every DevSummit I have been to (AsiaBSDCon, BSDCam, EuroBSDCon, vBSDCon, ..). Later I was asked to post on -arch and I did.. With very little feedback and none from you.. Regards, Brad Davis From owner-freebsd-current@freebsd.org Fri Aug 24 08:05: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 1EF141082EF7 for ; Fri, 24 Aug 2018 08:05:34 +0000 (UTC) (envelope-from johalun0@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 G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C4357C48F for ; Fri, 24 Aug 2018 08:05:33 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id t25-v6so745020wmi.3 for ; Fri, 24 Aug 2018 01:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+gzhCQTJn4Y6Xdac27QLPnIQIHsYM7X2ldpiPuT0pQc=; b=fEFs4BoLXQmAyy4ZWEl+upA+d7VZvMRwtegdZcy7mgTiGU5WrZmRURDx1gQQlTHMu4 ivC3U4pKPoTtGAJSsU43f7ZpdBu0Zk2KXVR94ns2kI1LbrxOnVF8AOMRpOiS+c/JcCWg bdOKUgNBEBVwiYBtagQH9zcFGpzXobizUZ+n0X8k8NKR0ZUeL76VENmfSFJOL+5DCBk7 dYapiSD1E2hWc/L6aw4Op887LrtTv0+7i54AMv1RZIWmafmLrNJnjqwBoEaW/Lp9b5lO Tcd+r+vwa4p0jzyHYKE+r9LKasJUq1dT1NHWVoTHQLwux3TAI4RoRXzIhx3QgawHTNKb SVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+gzhCQTJn4Y6Xdac27QLPnIQIHsYM7X2ldpiPuT0pQc=; b=VcVQfXbZkQg3HMNhadn4TKXPcbck67+XUFMTqAphdO+EvxR/sxk7XtnpTZ3s+V5Mg5 bXnZ1NoPyHBBDkGEaZ1mHeGljyCgmkWUUoZNXamK2wk+m9zzRryQctWePfXn95TbDrpg aeVqqgh7YIfuUbMx2LQOCw84+OzWowh8pLNpg0f0iItrm8jrdxMqi6x+TSkIqlKZbRRK HXV2M+PUSGbT6jRhgcI7uhNZneUkAeVZ9vx2AxvE8fzB9pNew8ptOsAsVHYD7Cx6UErd /vYLEdJO2Mw2NQtpYmYHOf4V0m3fF0XYqHU1/DvkVDdZSbN9ew4AgoC0H7w5/8bT5mOO kRvQ== X-Gm-Message-State: APzg51CBaWolHKvZ2k/HbaMPlQnPHAWW11c0hUplzPxuiXPuX/25DhX2 UY/yhFbMun+axeV+zBi0g3DLIke7SySTc//kR8g6rZTj X-Google-Smtp-Source: ANB0VdbXnuqQ0x2wYYCIzJL/FlRqLKWLtOHCCpYPLPCvnkd/zKjRSl9cXWfQzX85dN+ozrjOrgZ+Ynf/FJsWamxmKDw= X-Received: by 2002:a1c:af53:: with SMTP id y80-v6mr637545wme.55.1535097930911; Fri, 24 Aug 2018 01:05:30 -0700 (PDT) MIME-Version: 1.0 From: Johannes Lundberg Date: Fri, 24 Aug 2018 10:04:54 +0200 Message-ID: Subject: priority of paths to kernel modules? To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 08:05:34 -0000 Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers From owner-freebsd-current@freebsd.org Fri Aug 24 08:12: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 E15F11083342 for ; Fri, 24 Aug 2018 08:12:53 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93E197C9CE for ; Fri, 24 Aug 2018 08:12:53 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 5920724C31 for ; Fri, 24 Aug 2018 08:12:53 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f45.google.com with SMTP id g18-v6so1072546itg.2 for ; Fri, 24 Aug 2018 01:12:53 -0700 (PDT) X-Gm-Message-State: APzg51A8A9iv/hvBmP9s12z4n3EZFpgdhO1CPlMb1Z0If93FCvMxQuWw nkSUPj8j0+Fosi8mYp+PXktNNmHxBErB77H6ueQ= X-Google-Smtp-Source: ANB0Vda6b9W1eFqEoOc5H2ly6gxhwdATvKjFvbFGfSl4ZmwBIyzrI0WBZwrDlxzl3In2CqnDnBBwL0Ye1nRRe2xDrC4= X-Received: by 2002:a24:704f:: with SMTP id f76-v6mr602903itc.30.1535098372799; Fri, 24 Aug 2018 01:12:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Fri, 24 Aug 2018 01:12:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: priority of paths to kernel modules? To: Johannes Lundberg Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 08:12:54 -0000 No we're not. x86 and PPC will be disconnected from the build in a subsequent commit during the freeze. Warner was simply too tired to communicate this adequately and still meet the timeline that RE wanted. And take heart. Even if Warner weren't trying to balance the needs of RE and the graphics team + user base on post-2013 hardware - the graphics doesn't _have_ to support 12.x. it's well within the team's rights to simply declare 12.x as unsupported. The team is welcome to simply say we support 11.x and 13.x. The failing was largely in that "expected" processes are not documented and not well communicated. Warner is acting in good faith. He's just trying to balance many demands in a compressed time period. Cheers. -M On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg wrote: > Hi > > Since we now stuck with drm2 in base for a few more years I have an idea > would make things much smoother for many of us, hugely reduce the amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct this is a > flaw and /boot/ should be inserted last so that any overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > _______________________________________________ > 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 Fri Aug 24 08:22:23 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 A647B10837E3 for ; Fri, 24 Aug 2018 08:22:23 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 236A47CEEE; Fri, 24 Aug 2018 08:22:23 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id b19-v6so776493wme.3; Fri, 24 Aug 2018 01:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NDG/DFm35CGdio7ifVXIe0J/b/b8qSXRAPBe6JYeeNQ=; b=RQg/bgpJ6ZpZO8qiIdahdeD/oLjZa+A7feyf09GLL1YYrc7neMFDW58t2qixY8Fh4e WzAkZWijvs3zmwMntt4WsPSBhIJBX6GqGalloaW53/PlIzLfIkTni2r1D8w2SUzYBpCQ 55Di2WdJO/JByExTjWhLt2PQtCE1ONToaDX5YPnuPS1feduHGj8NyEKMaoIzNmmEpWAr 8BPMEq4NY78AABTUVtZC+SGJG0f6qpw4x1DLU2DMFrUv6UCYPlDpLD0+sT0+vPg0B4yC f9XZyptd+dFkFE/BEPwaN3KMNQ/m+YX0Ox2oXLKECVJTSyjrxVdxd7VG1DzjSLFgHjxg QkAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDG/DFm35CGdio7ifVXIe0J/b/b8qSXRAPBe6JYeeNQ=; b=M3Uh8Ma2AKt06X9mubiVmj1mCD/VFAddJ9RMqYOzZu3lbe6hZEkGqK0RyazsS/ZAuL /c+YWZ3KFb23BkUuQDPBsbWjwziuZiw1oYgPv+2mAT1WjeUoJHW++pntTTHK//rvQpq4 I0N/V8p/LtfBY0xg1lQMBryAxC9q4nJa8zvMyzOW/t9MDC4eryjGyyIyP7exImIPkt51 Wi3x31WcBJFqcMk/ZANyx51lnwsM8X0EcS/swd8hn3Q9VpRemjld6MaiJY5aTy7Le3t9 JMDE/UbMVuIO2+eIaHz0PnNcPSsT0veCxVk2rTmhin8nJoQkknOZO+6l693wL1XcS9eF vVAg== X-Gm-Message-State: APzg51AJ3AEG4JsAcZKkCTMsStlVOAEXAGWYGQuaPjHt917M3crcJoMz HqqTjIGcV0fFj3a/ymOWfbbAl4+gsFaTLpuGuoluXA== X-Google-Smtp-Source: ANB0VdYrAoV1wjIhEcGK+yHpPCP9xYI8B2yWURYAwKIgnZgW+JZpNVayM/9W95SCCR1SXsra4SQoO0jOlsX2SLZx7qA= X-Received: by 2002:a1c:af53:: with SMTP id y80-v6mr673840wme.55.1535098941948; Fri, 24 Aug 2018 01:22:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Johannes Lundberg Date: Fri, 24 Aug 2018 10:21:44 +0200 Message-ID: Subject: Re: priority of paths to kernel modules? To: Matthew Macy Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 08:22:23 -0000 On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > > Warner is acting in good faith. He's just trying to balance many demands > in a compressed time period. > > Cheers. > -M > > OK, thanks for the clarification. That's a good compromise I guess. Still, regardless of drm, aren't modules in overlay folders suppose to have higher priority than those in the kernel folder? > > > > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > >> Hi >> >> Since we now stuck with drm2 in base for a few more years I have an idea >> would make things much smoother for many of us, hugely reduce the amount >> of >> bug reports we get and I think would be beneficial in other ways too. >> >> Current I run with something like this in /boot/loader.conf >> >> >> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" >> >> So I expect modules to be loaded in that order, with /boot/ >> LAST. >> >> However, if you look at this >> sysctl kern.module_path >> kern.module_path: >> >> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays >> >> /boot/kernel is inserted first and probably modules in /boot/kernel have >> the highest priority. This is also proven by everyone wanting to use >> drm*kmods that get drm.ko from base loaded instead of the installed in >> /boot/modules. >> >> Please correct me if I'm wrong but if my understanding is correct this is >> a >> flaw and /boot/ should be inserted last so that any overlays or >> custom modules have higher priority than the default ones. >> >> I can imagine this is also useful when building custom modules and you >> don't want to overwrite or delete the default one in /boot/kernel... >> >> Cheers >> _______________________________________________ >> 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 Fri Aug 24 13:05:21 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 B06F71089A44 for ; Fri, 24 Aug 2018 13:05:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A32B851FC; Fri, 24 Aug 2018 13:05:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id EB623269EB; Fri, 24 Aug 2018 13:05:20 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f180.google.com with SMTP id v26-v6so3026862ljj.3; Fri, 24 Aug 2018 06:05:20 -0700 (PDT) X-Gm-Message-State: APzg51DzDR8CkxlAYugPZBVQf2Kl2yd6JjjX0DlVau79gN1SwnjluLiA Ow5cXj1MGvVnOtU13GYQ/r0GBNtDE4um65DGBGE= X-Google-Smtp-Source: ANB0VdZaIsPfTAID4Czy/3Y6BQFyJl43amOJmMHFkDx6NePwu4Ii/YXcchTFiOCwd1FbTAu3SqeO37j9sheISZrA+CM= X-Received: by 2002:a2e:658a:: with SMTP id e10-v6mr1244120ljf.99.1535115919413; Fri, 24 Aug 2018 06:05:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 24 Aug 2018 08:05:07 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: priority of paths to kernel modules? To: johalun0@gmail.com Cc: Matthew Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 13:05:21 -0000 On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote: > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote: > > > No we're not. x86 and PPC will be disconnected from the build in a > > subsequent commit during the freeze. Warner was simply too tired to > > communicate this adequately and still meet the timeline that RE wanted. > > > > And take heart. Even if Warner weren't trying to balance the needs of RE > > and the graphics team + user base on post-2013 hardware - the graphics > > doesn't _have_ to support 12.x. it's well within the team's rights to > > simply declare 12.x as unsupported. The team is welcome to simply say we > > support 11.x and 13.x. The failing was largely in that "expected" processes > > are not documented and not well communicated. > > > > Warner is acting in good faith. He's just trying to balance many demands > > in a compressed time period. > > > > Cheers. > > -M > > > > > OK, thanks for the clarification. That's a good compromise I guess. > > Still, regardless of drm, aren't modules in overlay folders suppose to have > higher priority than those in the kernel folder? > (Putting on my loader ballcap) I would like to change this after 12 branches to append by default and allow one to add ${kernel_path} to their module_path to override that, since the status quo has been such for 18 years and some may want to go back to that. I've personally been bitten by it a couple too many times to be happy with the current situation. (Takes off loader ballcap) Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Fri Aug 24 14:11:38 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 2D803108AF42 for ; Fri, 24 Aug 2018 14:11:38 +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 8F78B8725B; Fri, 24 Aug 2018 14:11:37 +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 w7OEBX8F095141; Fri, 24 Aug 2018 07:11:33 -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 w7OEBXg8095140; Fri, 24 Aug 2018 07:11:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> Subject: Re: priority of paths to kernel modules? In-Reply-To: To: Kyle Evans Date: Fri, 24 Aug 2018 07:11:33 -0700 (PDT) CC: johalun0@gmail.com, Matthew Macy , FreeBSD Current 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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 14:11:38 -0000 > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote: > > > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote: > > > > > No we're not. x86 and PPC will be disconnected from the build in a > > > subsequent commit during the freeze. Warner was simply too tired to > > > communicate this adequately and still meet the timeline that RE wanted. > > > > > > And take heart. Even if Warner weren't trying to balance the needs of RE > > > and the graphics team + user base on post-2013 hardware - the graphics > > > doesn't _have_ to support 12.x. it's well within the team's rights to > > > simply declare 12.x as unsupported. The team is welcome to simply say we > > > support 11.x and 13.x. The failing was largely in that "expected" processes > > > are not documented and not well communicated. The deprececation policy is documented, though poorly, and I agree in the spirit that much of the processes here in the FreeBSD project are sadly in a similiar situation. Since we are in code freeze we could all go work on those things :-) > > > Warner is acting in good faith. He's just trying to balance many demands > > > in a compressed time period. > > > > > > Cheers. > > > -M > > > > > > > > OK, thanks for the clarification. That's a good compromise I guess. > > > > Still, regardless of drm, aren't modules in overlay folders suppose to have > > higher priority than those in the kernel folder? I agree, but usually do not depend on that to get what I need, but rather resort to any special needs by force loading with /boot/loader.conf modules that are loaded out of order. > (Putting on my loader ballcap) > > I would like to change this after 12 branches to append by default and > allow one to add ${kernel_path} to their module_path to override that, > since the status quo has been such for 18 years and some may want to > go back to that. I've personally been bitten by it a couple too many > times to be happy with the current situation. > > (Takes off loader ballcap) I actually like this solution, it appears to be a win for everyone and would make the road smoother in the future for similiar types of things should they happen. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Fri Aug 24 15:03: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 690A2108C462 for ; Fri, 24 Aug 2018 15:03:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFFCA89DA4 for ; Fri, 24 Aug 2018 15:03:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id q4-v6so7367491iob.8 for ; Fri, 24 Aug 2018 08:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ssRrL8xY+X2dUqXu1iBiJy19bhu8eeXrS84P90nl4SY=; b=mVigOTZ5hoIlN4ze3YaQOJybmp6mY4fjCilJpHppb0Q+St65KL7nnOizXXYkp38Qdx Fs4RmOI5Qwu2ZiQ72/WWw/gs9OHppu3mOWnWkp/wN22Go4wgVlWtdAkULOPQXjHuYlCA tboaIi6XPC6saILUe2/r3tpkxtuLzvJrp3MgADfEgS925U5RyTt+gZdBzrcZPtM0TNrG 0qDRQV2g2/hBr0UmrhzkDJes50pyIj2luCy66K4akPRAIkyG9YpKPxndtsCIqiPlV4Gh LWSbgfE7ND/Q48f1DN5d43kawTyGbGVeWoWShDpDwRAbqPdCr+wiL+yq0LrRoOEtKzlt K5eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ssRrL8xY+X2dUqXu1iBiJy19bhu8eeXrS84P90nl4SY=; b=BMUtw30+l6RFLKgQnNgOHSu+tlVaGtIZxgghkRdaSmi/OF7+ikADlYIwaMwg4NO2Rn FQjDJUG+IacDPTJgiYQdhZYLQrZHFRTR2P078rcUMyoJrdA5Aci+Cj7jgEDuVXYB6wqK WXPc7KAS6hrBraxGHEixPktflmUl9nZWEeW0WhAm/DvtZLmy+ebRdMHFt9qy1eCNnztG Ftmfrx6aXQaBAG0qPJzgLXAL0iepHdzhr8DvRWLMU3XMvYZiVes4VDBW6zuHXmvIiK2e R/cWJljRZ/StyZBFHfpM5kWCqapcV01sfyD2htBjhoL0iRJHcS1kcc0SiPZaDn1i4Cui Frsw== X-Gm-Message-State: APzg51D1zNlf6ygko7uoUgQe/GTfQR7+SzgnIQ4Y5uj2wZXRpiR6jfC+ nbTQsyS57f6RWGiMXtLob97SYT4nwt1jOgcwykr5gH2PQO4= X-Google-Smtp-Source: ANB0VdadVC3rejqnKV17Yns7Gwiw1A34zqaavHmWZTYZWpaY8ulfxnYhOrJZOABIuoOyxiqREZxIm5Oh1DfZWsXJN1I= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr1493668ioa.299.1535122985122; Fri, 24 Aug 2018 08:03:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 09:02:53 -0600 Message-ID: Subject: Re: priority of paths to kernel modules? To: Matt Macy Cc: Johannes Lundberg , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:03:06 -0000 On Fri, Aug 24, 2018 at 2:14 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > We're still trying to figure out that issue. I'd like to do this, but there's a lot of moving parts and objections that I need to plow through before it's a done deal. Expect further incremental steps. We already do not build in the kernel for x86 or powerpc, which gives us a lot more flexibility. The revert was a first step, not a final stop. > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > The graphics team doesn't have to support what's in the tree, at all. One of the things that we absolutely will be doing is putting in big scary notices saying that these drivers are deprecated, that you should be using the ports and to not expect any support and these drivers are present only as a transition. Other ideas that I'm exploring, is the notion of a poison pill for the in-tree drivers. So, we put all the IDs for the *NEW* cards into a driver (maybe the intel/radeon one, maybe a new one: there's pros and cons to each that need to be looked at). All this driver does is return a probe value that's tiny so it usually isn't accepted. But when it is, it prints a message saying "This card isn't supported by the in-tree driver. You must install the port" and fails to attach, which would fail X11 startup. Not completely ideal, but the X11 startup already fails with little clue and this would help. Warner is acting in good faith. He's just trying to balance many demands in > a compressed time period. > Yesterday, hours before Johannes' email went out, I was communicating with the Lua boot loader guy about ways we could change the path the boot loader users for certain modules and other such things to mitigate this problem. Warner > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > > > Hi > > > > Since we now stuck with drm2 in base for a few more years I have an idea > > would make things much smoother for many of us, hugely reduce the amount > of > > bug reports we get and I think would be beneficial in other ways too. > > > > Current I run with something like this in /boot/loader.conf > > > > > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > > > However, if you look at this > > sysctl kern.module_path > > kern.module_path: > > > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > > > /boot/kernel is inserted first and probably modules in /boot/kernel have > > the highest priority. This is also proven by everyone wanting to use > > drm*kmods that get drm.ko from base loaded instead of the installed in > > /boot/modules. > > > > Please correct me if I'm wrong but if my understanding is correct this > is a > > flaw and /boot/ should be inserted last so that any overlays or > > custom modules have higher priority than the default ones. > > > > I can imagine this is also useful when building custom modules and you > > don't want to overwrite or delete the default one in /boot/kernel... > > > > Cheers > > _______________________________________________ > > 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" > > > _______________________________________________ > 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 Fri Aug 24 15:20: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 25162108CA77 for ; Fri, 24 Aug 2018 15:20:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD67E8A5A8 for ; Fri, 24 Aug 2018 15:20:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id g18-v6so2586598itg.2 for ; Fri, 24 Aug 2018 08:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=30bAW4tDlD4GrEOfWKaPYh4PJQ35TYzLn3mwBlmfd+s=; b=DRXw9xCB2ecVK71A9fvaR7+Cjj9GUDfm366nnNpQlU6gjvkYrOTX5sc4YWJrbpp6aV 3Tqx0f6U7++19Bxaq7dMYybhDRgwYLUpfmaFinygp+OJT5RdZvDKGtpe1R7fdMQd4/K8 l6TEZPJjqcj6Uu91KOpcGdtr9Wz9vPMSUQx41pKgNpbIRsTlflC6TwR87xlr84bx1q52 v47iYAKfY/SROwwi2+Sa/4TIlHfJwDdWQDbzLHtWkTlVdoLWVjct9XuNZ8Id7bBqbn01 W3omayBrhemP09V1iua1gKEacFWxyHiRwYbYmPpb1IW4oGH4jAq8NERRRk+mR0/MVEk6 oYWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=30bAW4tDlD4GrEOfWKaPYh4PJQ35TYzLn3mwBlmfd+s=; b=kqRJ5bo1EpFsRYZ61+oVnphNNlnnpDeQcXpylQyfaD2ZZ+6lVE9pN2uGmK0zJnmiAX Zr3qNuqpwMwBm9/2zNDmyN2XgkXgELvw2KFAVktuiVB4sfanFkkZE6HWX4TehcHBAjgX QmmcI/CCv7hB6k/c14lFkBHAH7NCUimhHT/O3+evZwKV7KMI0gcd27+1673Iq6yoQ9Zt e1j5MyQcpSGMc5gOEek9t0y3tIxizS0Zqs2FUZ6k04CESt3kyCqziyJttbmBgoi783jn GfkeSDT6d7MWsMQNK2t4JcSg/AO3CyHRYl71A9UcCyMW+JxRWbCQ5a6puJ521/VD2vtk heig== X-Gm-Message-State: APzg51CheAnjnDKRYTljt1YBzqpPsw634L9sp28Ky5upSaJ2RIqs7h5E kDoHBNOrMM2VfV/gw2HYB7TQVfixO4kNKY4aX7eKqA== X-Google-Smtp-Source: ANB0Vdb4GHQC8RbJBqyFHAdAfnTIk7h18SJCvDXnsZalwtXuh/63PyzegOKIWFDBOk7No/1brEtg32gORH/PVhwUKUs= X-Received: by 2002:a24:d2:: with SMTP id 201-v6mr1790106ita.60.1535124023942; Fri, 24 Aug 2018 08:20:23 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Fri, 24 Aug 2018 09:20:12 -0600 Message-ID: Subject: Re: priority of paths to kernel modules? To: "Rodney W. Grimes" Cc: Kyle Evans , Johannes Lundberg , Matt Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:20:25 -0000 On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg > wrote: > > > > > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy > wrote: > > > > > > > No we're not. x86 and PPC will be disconnected from the build in a > > > > subsequent commit during the freeze. Warner was simply too tired to > > > > communicate this adequately and still meet the timeline that RE > wanted. > > > > > > > > And take heart. Even if Warner weren't trying to balance the needs > of RE > > > > and the graphics team + user base on post-2013 hardware - the > graphics > > > > doesn't _have_ to support 12.x. it's well within the team's rights to > > > > simply declare 12.x as unsupported. The team is welcome to simply > say we > > > > support 11.x and 13.x. The failing was largely in that "expected" > processes > > > > are not documented and not well communicated. > > The deprececation policy is documented, though poorly, and I agree in > the spirit that much of the processes here in the FreeBSD project are > sadly in a similiar situation. > To say this is a learning situation for all those involved is not an understatement. > Since we are in code freeze we could all go work on those things :-) > Yes. That's why I wanted all removals to wait until after the freeze so that I could get the deprecation policy hammered out better, including a common set of guidelines to know when to remove, when to disable, and how to ease things out of the tree in as a non-disruptive way as possible. > > > > Warner is acting in good faith. He's just trying to balance many > demands > > > > in a compressed time period. > > > > > > > > Cheers. > > > > -M > > > > > > > > > > > OK, thanks for the clarification. That's a good compromise I guess. > > > > > > Still, regardless of drm, aren't modules in overlay folders suppose to > have > > > higher priority than those in the kernel folder? > > I agree, but usually do not depend on that to get what I need, > but rather resort to any special needs by force loading with > /boot/loader.conf modules that are loaded out of order. > There's some tricks we can do here. First, I talked to Kyle yesterday about augmenting the Lua loader to have a X_loadflag option. Some background. We look at a lot of X_xxxx flags for loading modules. X_load=yes being the most familiar. One way to avoid POLA would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that by default, we'd run load -K i915kms instead of load i915kms. We'd augment the built-in load command so it knew that -K means 'add the kernel to the path last rather than first'. This would solve one of the POLA violations in a very targeted way: people that put i915kms_load=YES in their loader.conf wouldn't be surprised by this transition. It would be at the cost of 2 entires in loader.conf, I believe, and it shuts down one vector of hassle for our users. People do this, btw, to get more lines / columns in the BIOS boot environment for their console, so it's not an unreasonable path to attend to. We could also have a sysctl that we could set to override specific modules locations. This would allow the graphics port to have a rc script that sets this up so when X11 goes to automatically load the module, the right one gets loaded. This would solve the issue for the people that 'do nothing' except install the port. While it's a small bit of programming for the kernel, it's a general mechanism that's laser-focused on exceptions to the rule w/o wholesale changes. This would solve the other main vector and motivator for the 'kill it with fire' calls that doesn't leave behind a scorched earth. The people that do nothing, not even install a graphics port, we might be able to 'poison pill' the drivers such that we fail the load hard enough X11 doesn't start, but with a clear error message about next steps. This is a bonus of leaving them in the tree: we would just have a silent failure otherwise as X11 tries to load i915kms.ko only to have no driver attach. > (Putting on my loader ballcap) > > > > I would like to change this after 12 branches to append by default and > > allow one to add ${kernel_path} to their module_path to override that, > > since the status quo has been such for 18 years and some may want to > > go back to that. I've personally been bitten by it a couple too many > > times to be happy with the current situation. > > > > (Takes off loader ballcap) > > I actually like this solution, it appears to be a win for everyone > and would make the road smoother in the future for similiar types > of things should they happen. > Generally, things don't conflict. I like this notion for a number of reasons. It lets me have a 'driver disk' which can be placed first in the load for install and not have to worry about naming. It also gives us more flexibility for things in the future. The time to propose it, however, was May so we could shake things out, so it's too late for this release I'm thinking. But if we do this after the freeze, then we're in good shape for having it in 13, or knowing why it's a bad idea. Warner From owner-freebsd-current@freebsd.org Fri Aug 24 15:27: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 8D77A108CCF5 for ; Fri, 24 Aug 2018 15:27:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A6C38AA5C; Fri, 24 Aug 2018 15:27:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id C796E277FD; Fri, 24 Aug 2018 15:27:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id e23-v6so6957519lfc.13; Fri, 24 Aug 2018 08:27:09 -0700 (PDT) X-Gm-Message-State: APzg51CLnFbf9/3UDxOYt/kGK2y6Nl1Aoa2rAMW2cF6SSD4GeoWWs0bK kR+nD67r1Bg9ttF93SkDj2PAwF3/gx91icX1ttc= X-Google-Smtp-Source: ANB0VdY9k6Bazzrf+3MzkYryH5HnSlGLNrZAlgkaiBEwwJxIuVh0neSCRB/HJdv9bOZd0ZJc9o8a3nR0XOdi5KMuBXg= X-Received: by 2002:a19:5154:: with SMTP id f81-v6mr1735569lfb.55.1535124428349; Fri, 24 Aug 2018 08:27:08 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Kyle Evans Date: Fri, 24 Aug 2018 10:26:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: priority of paths to kernel modules? To: Warner Losh Cc: "Rodney W. Grimes" , Kyle Evans , johalun0@gmail.com, Matthew Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:27:10 -0000 On Fri, Aug 24, 2018 at 10:20 AM Warner Losh wrote: > > > > On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes wrote: >> >> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg = wrote: >> > > >> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wr= ote: >> > > >> > > > No we're not. x86 and PPC will be disconnected from the build in a >> > > > subsequent commit during the freeze. Warner was simply too tired t= o >> > > > communicate this adequately and still meet the timeline that RE wa= nted. >> > > > >> > > > And take heart. Even if Warner weren't trying to balance the needs= of RE >> > > > and the graphics team + user base on post-2013 hardware - the grap= hics >> > > > doesn't _have_ to support 12.x. it's well within the team's rights= to >> > > > simply declare 12.x as unsupported. The team is welcome to simply = say we >> > > > support 11.x and 13.x. The failing was largely in that "expected" = processes >> > > > are not documented and not well communicated. >> >> The deprececation policy is documented, though poorly, and I agree in >> the spirit that much of the processes here in the FreeBSD project are >> sadly in a similiar situation. > > > To say this is a learning situation for all those involved is not an unde= rstatement. > >> >> Since we are in code freeze we could all go work on those things :-) > > > Yes. That's why I wanted all removals to wait until after the freeze so t= hat I could get the deprecation policy hammered out better, including a com= mon set of guidelines to know when to remove, when to disable, and how to e= ase things out of the tree in as a non-disruptive way as possible. > >> >> > > > Warner is acting in good faith. He's just trying to balance many d= emands >> > > > in a compressed time period. >> > > > >> > > > Cheers. >> > > > -M >> > > > >> > > > >> > > OK, thanks for the clarification. That's a good compromise I guess. >> > > >> > > Still, regardless of drm, aren't modules in overlay folders suppose = to have >> > > higher priority than those in the kernel folder? >> >> I agree, but usually do not depend on that to get what I need, >> but rather resort to any special needs by force loading with >> /boot/loader.conf modules that are loaded out of order. > > > There's some tricks we can do here. > > First, I talked to Kyle yesterday about augmenting the Lua loader to have= a X_loadflag option. Some background. We look at a lot of X_xxxx flags for= loading modules. X_load=3Dyes being the most familiar. One way to avoid PO= LA would be to have in boot/defaults/loader.conf a i915kms_loadflag=3D-K so= that by default, we'd run load -K i915kms instead of load i915kms. We'd au= gment the built-in load command so it knew that -K means 'add the kernel to= the path last rather than first'. This would solve one of the POLA violati= ons in a very targeted way: people that put i915kms_load=3DYES in their loa= der.conf wouldn't be surprised by this transition. It would be at the cost = of 2 entires in loader.conf, I believe, and it shuts down one vector of has= sle for our users. People do this, btw, to get more lines / columns in the = BIOS boot environment for their console, so it's not an unreasonable path t= o attend to. > > We could also have a sysctl that we could set to override specific module= s locations. This would allow the graphics port to have a rc script that se= ts this up so when X11 goes to automatically load the module, the right one= gets loaded. This would solve the issue for the people that 'do nothing' e= xcept install the port. While it's a small bit of programming for the kerne= l, it's a general mechanism that's laser-focused on exceptions to the rule = w/o wholesale changes. This would solve the other main vector and motivator= for the 'kill it with fire' calls that doesn't leave behind a scorched ear= th. > > The people that do nothing, not even install a graphics port, we might be= able to 'poison pill' the drivers such that we fail the load hard enough X= 11 doesn't start, but with a clear error message about next steps. This is = a bonus of leaving them in the tree: we would just have a silent failure ot= herwise as X11 tries to load i915kms.ko only to have no driver attach. > >> > (Putting on my loader ballcap) >> > >> > I would like to change this after 12 branches to append by default and >> > allow one to add ${kernel_path} to their module_path to override that, >> > since the status quo has been such for 18 years and some may want to >> > go back to that. I've personally been bitten by it a couple too many >> > times to be happy with the current situation. >> > >> > (Takes off loader ballcap) >> >> I actually like this solution, it appears to be a win for everyone >> and would make the road smoother in the future for similiar types >> of things should they happen. > > > Generally, things don't conflict. I like this notion for a number of reas= ons. It lets me have a 'driver disk' which can be placed first in the load = for install and not have to worry about naming. It also gives us more flexi= bility for things in the future. The time to propose it, however, was May s= o we could shake things out, so it's too late for this release I'm thinking= . But if we do this after the freeze, then we're in good shape for having i= t in 13, or knowing why it's a bad idea. > I should probably have mentioned- the _loadflags solution is one I feel comfortable with this late in the release cycle, but I would very strongly prefer not to touch module_path in a stable branch (or soon-to-be-stable branch) so that we have time to sort out the ramifications for the odd-balls that depend on the current ordering given its history. The ${kernel_path} override could allow something like my described module_path change to happen in a stable branch, but not for the upcoming release and any backport would most likely involve changing the default to prepending ${kernel_path} so that we're not surprising the aforementioned "odd-balls". Thanks, Kyle Evans From owner-freebsd-current@freebsd.org Fri Aug 24 15:27: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 8C676108CD23 for ; Fri, 24 Aug 2018 15:27:45 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05C8A8AAC9; Fri, 24 Aug 2018 15:27:45 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id m199-v6so4546458wma.1; Fri, 24 Aug 2018 08:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sfh6O/V/hEaAA1A0yT4J4CuPJV/2hx6kvRuFFwdqY7g=; b=FfS2SDXIclMuXWMbGl0K38SsrnV8YEiDvVkSijsh7mgBkwmDves031Ho/IHJgtF5Cr W9Xm9IJTaleCvKx/gzsEk4540cXMhfqCcdCIpiqADdSXKHtUbVtfZVINltKrywuAhPnv HxfYWtjdbMv7t0cCPsyILFftw35zhFgLhi+lHRvtTB+rpi/mCFY6v25E6FKyMfWkzdwc ank3EBuHrHvmR+nuAuOebBWIH4VfEN+d+ucgOCTWywTWxkHemAJIRevgIy4SJAZuF3ru Sk4XBtzpBGEgMUEQu9+5YZf03M0dTzOTk7t6jQj931gPAo5MkpVCWSxfezKKo08MztlZ AMJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sfh6O/V/hEaAA1A0yT4J4CuPJV/2hx6kvRuFFwdqY7g=; b=p2saDa2V7HajjF4H47iIx2mH7Ge2yjBq+ejpxGBA/UTtwy7z8B2/dnrxHFR5bxnCC9 Yai6Hr+hEiXE/CZTP/k4j4JpdzO3GXaSW7EnxXNOa+eh8pOcIDgYYRiuCRL2tPtqfQeR GIYjpxY9SGK24BtmbBA9yMYvqjkmRALP8Og7RIK84XlLQYpJGwYOV3YFf4HhfFCAnC/z wZdBohjEgaKtFJVDfKflpk7BY8L7Cq0t3kgvtBCOLnhPgLG12Kvl/8411yZ9rtDjmfko V3QQjX7U4LgJZD67KGe0gPjPprlK93jWbXGBP/Obw6JMm8bUQgHQ5Ej+DEZo8klbOy9w nFjg== X-Gm-Message-State: APzg51DQFoVvBETTFKVWARP+3mFeL/MVyfk4gL5wJW88/LiqGhRC7L88 k1IGaooVEI9vPkzIKqHNUzSDZDaOFyB4CXpMppKHtQ== X-Google-Smtp-Source: ANB0VdZa3QauAgi/IvTWIL+dM3M3j723/XSc3pXmQoPb1SkmRYuRX4OnVrk6Q7LDqFbHWNi+7AW4CDHT10iNYt4GGRA= X-Received: by 2002:a1c:55c2:: with SMTP id j185-v6mr1745002wmb.104.1535124463867; Fri, 24 Aug 2018 08:27:43 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Johannes Lundberg Date: Fri, 24 Aug 2018 17:27:06 +0200 Message-ID: Subject: Re: priority of paths to kernel modules? To: Warner Losh Cc: freebsd-rwg@pdx.rh.cn85.dnsmgr.net, kevans@freebsd.org, Matthew Macy , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:27:45 -0000 On Fri, Aug 24, 2018 at 5:20 PM Warner Losh wrote: > > > On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg >> wrote: >> > > >> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy >> wrote: >> > > >> > > > No we're not. x86 and PPC will be disconnected from the build in a >> > > > subsequent commit during the freeze. Warner was simply too tired to >> > > > communicate this adequately and still meet the timeline that RE >> wanted. >> > > > >> > > > And take heart. Even if Warner weren't trying to balance the needs >> of RE >> > > > and the graphics team + user base on post-2013 hardware - the >> graphics >> > > > doesn't _have_ to support 12.x. it's well within the team's rights >> to >> > > > simply declare 12.x as unsupported. The team is welcome to simply >> say we >> > > > support 11.x and 13.x. The failing was largely in that "expected" >> processes >> > > > are not documented and not well communicated. >> >> The deprececation policy is documented, though poorly, and I agree in >> the spirit that much of the processes here in the FreeBSD project are >> sadly in a similiar situation. >> > > To say this is a learning situation for all those involved is not an > understatement. > > >> Since we are in code freeze we could all go work on those things :-) >> > > Yes. That's why I wanted all removals to wait until after the freeze so > that I could get the deprecation policy hammered out better, including a > common set of guidelines to know when to remove, when to disable, and how > to ease things out of the tree in as a non-disruptive way as possible. > > >> > > > Warner is acting in good faith. He's just trying to balance many >> demands >> > > > in a compressed time period. >> > > > >> > > > Cheers. >> > > > -M >> > > > >> > > > >> > > OK, thanks for the clarification. That's a good compromise I guess. >> > > >> > > Still, regardless of drm, aren't modules in overlay folders suppose >> to have >> > > higher priority than those in the kernel folder? >> >> I agree, but usually do not depend on that to get what I need, >> but rather resort to any special needs by force loading with >> /boot/loader.conf modules that are loaded out of order. >> > > There's some tricks we can do here. > > First, I talked to Kyle yesterday about augmenting the Lua loader to have > a X_loadflag option. Some background. We look at a lot of X_xxxx flags for > loading modules. X_load=yes being the most familiar. One way to avoid POLA > would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that > by default, we'd run load -K i915kms instead of load i915kms. We'd augment > the built-in load command so it knew that -K means 'add the kernel to the > path last rather than first'. This would solve one of the POLA violations > in a very targeted way: people that put i915kms_load=YES in their > loader.conf wouldn't be surprised by this transition. It would be at the > cost of 2 entires in loader.conf, I believe, and it shuts down one vector > of hassle for our users. People do this, btw, to get more lines / columns > in the BIOS boot environment for their console, so it's not an unreasonable > path to attend to. > > We could also have a sysctl that we could set to override specific modules > locations. This would allow the graphics port to have a rc script that sets > this up so when X11 goes to automatically load the module, the right one > gets loaded. This would solve the issue for the people that 'do nothing' > except install the port. While it's a small bit of programming for the > kernel, it's a general mechanism that's laser-focused on exceptions to the > rule w/o wholesale changes. This would solve the other main vector and > motivator for the 'kill it with fire' calls that doesn't leave behind a > scorched earth. > Just a small note here. With the modesetting driver (which is replacing the deprecated xf86-video-intel and is built into Xorg), X will not load the drm driver for you. It has to be done by putting kld_list="i915kms" in your rc.conf (I don't think loading drm next modules from /boot/loader.conf works). > The people that do nothing, not even install a graphics port, we might be > able to 'poison pill' the drivers such that we fail the load hard enough > X11 doesn't start, but with a clear error message about next steps. This is > a bonus of leaving them in the tree: we would just have a silent failure > otherwise as X11 tries to load i915kms.ko only to have no driver attach. > > > (Putting on my loader ballcap) >> > >> > I would like to change this after 12 branches to append by default and >> > allow one to add ${kernel_path} to their module_path to override that, >> > since the status quo has been such for 18 years and some may want to >> > go back to that. I've personally been bitten by it a couple too many >> > times to be happy with the current situation. >> > >> > (Takes off loader ballcap) >> >> I actually like this solution, it appears to be a win for everyone >> and would make the road smoother in the future for similiar types >> of things should they happen. >> > > Generally, things don't conflict. I like this notion for a number of > reasons. It lets me have a 'driver disk' which can be placed first in the > load for install and not have to worry about naming. It also gives us more > flexibility for things in the future. The time to propose it, however, was > May so we could shake things out, so it's too late for this release I'm > thinking. But if we do this after the freeze, then we're in good shape for > having it in 13, or knowing why it's a bad idea. > > Warner > From owner-freebsd-current@freebsd.org Fri Aug 24 15:35:46 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 84EB2108D14A for ; Fri, 24 Aug 2018 15:35:46 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CA808B181 for ; Fri, 24 Aug 2018 15:35:45 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id tE7cfJlo1p5A1tE7df9rxR; Fri, 24 Aug 2018 09:35:38 -0600 X-Authority-Analysis: v=2.3 cv=JLKPTPCb c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=dapMudl6Dx4A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=wsZfp5TuC2fQMTtNrFUA:9 a=tQDfnbZa2xO3dZ6N:21 a=C4jdSgan2ysAnDZg:21 a=CjuIK1q_8ugA:10 a=zMT18xs1K6lMPxkNFxgA:9 a=Y9SQvLAZjWY3RlKJ:21 a=1Er7mbh9Rhh6Z6ep:21 a=c0-Hm2Pbd6uH3fTM:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.170.45.27] (S0106788a207e2972.gv.shawcable.net [70.66.154.233]) by spqr.komquats.com (Postfix) with ESMTPSA id 7F83C1AC; Fri, 24 Aug 2018 08:36:11 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: priority of paths to kernel modules? Date: Fri, 24 Aug 2018 08:35:38 -0700 To: Johannes Lundberg , freebsd-current Message-Id: <20180824153611.7F83C1AC@spqr.komquats.com> X-CMAE-Envelope: MS4wfJ4IvJT3D5Nl7Q+BSqzt1bzs/DYF0uGu35dALxyUJjFMFvomnkN2ZakU4fuE62GTJGajrVzUyAAXdyk0pfLrrlgApQ6Zc/4KrywhL0tw4N5/8eXmYQbI O5fGXNlOPrkPZ5PhvEGvP5zBmRZV3QiUiyckWanHUvkDtdLZ1ekzbgDxvtsz0trZRr+lHw39YANDeTnIF1oTNJifWEh4e6Ff0T4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:35:46 -0000 My idea, which I implemented locally and should probably create a phab revi= ew, was to ifdef DRM in modules/Makefile. We could do this too. Default not= to build/install. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Johannes Lundberg Sent: 24/08/2018 01:08 To: freebsd-current Subject: priority of paths to kernel modules? Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path=3D"/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overla= ys" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers _______________________________________________ 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 Fri Aug 24 15:43:38 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 417CE108D40B for ; Fri, 24 Aug 2018 15:43:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C38488B622 for ; Fri, 24 Aug 2018 15:43:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id q5-v6so4264668iop.3 for ; Fri, 24 Aug 2018 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u5wQ7ogtliM4Am2zWnn5wOFsyY7EL9cZ2Dda3eDu7GU=; b=y8eDcs6gfcM2oM5ebzUT1MPhgi2mh3r+2IhiOZeiADF21J4FisWOP+Vda9OrG++glF E38NdW2IiGLlqNWcI2gfe+VkmfJrEZrozEk/xFxQNDvmS+krNP1RY+BFz0D8b4qDplp9 UEXsMw7+X3jOXQVYTFUa9/gGs+rsL0Jclpoka7F4Oihwt4OCwAiYuePkSRxHrP5bijDI 5fLfPI9HcUlv3iEyRMFmmaVpMo0IzWR8UXVotWPNbsMDllDL6xVd1XyI+GucnarZQN0i KChOCXaureYku+0pcRj6rd6HDeJhYFKaxlY2Sd6zBVHsn/ZCVP2LjBmugtwuCj5U0zpo i9CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u5wQ7ogtliM4Am2zWnn5wOFsyY7EL9cZ2Dda3eDu7GU=; b=Lt7Ub4ToNhkxCKlAzjwgj7yCriH/6kFZPnFG0JAaem8WArZcIaij7cYsyct3lTxqER LwcUg/75ErZQYmqf2LZ9O5weRp4SJhqEv8gZuvtj0c05LrX6rG7HUK+KI+bfbIN4tkDt /nb3vP+TD5WBCTvOaSUMQ/L1xa5nwNWEKQHCUInV8oyPLWsc7qb5wSAqjPMCaBv9FLWq OBGt337J0fXFlPXzcfrwkM80W+wPfGE7kKoLhcgwPwmgObsybye+x4nBkI0+wM+3xXwS Ql9nUD9TmUwrtQ+WlWh0j3fFfz7fR/t3NgB/KTBjhsksXxJaXaAlHFmdbfFKXtTnFl3w rELQ== X-Gm-Message-State: APzg51BfWrWf9uKbz7v3HWo67nhD1OYCPZOH5/Pa7nT0DtHKyh6LNFnN CtQ7hoyluKsgxPAlYk+YELgq4EB1ps/Hqkys5d5wqA== X-Google-Smtp-Source: ANB0VdbSmCw65DL1kkikrjCApF9TMpx9l9GMGTfL9JKEQwCughroMjxi4HZZumky0ogkaA/hxj+uvjL+GFxwTmUsGMY= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr1630966ioa.299.1535125417004; Fri, 24 Aug 2018 08:43:37 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 09:43:25 -0600 Message-ID: Subject: Re: priority of paths to kernel modules? To: Johannes Lundberg Cc: "Rodney W. Grimes" , Kyle Evans , Matt Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:43:38 -0000 On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg wrote: > There's some tricks we can do here. >> >> First, I talked to Kyle yesterday about augmenting the Lua loader to have >> a X_loadflag option. Some background. We look at a lot of X_xxxx flags for >> loading modules. X_load=yes being the most familiar. One way to avoid POLA >> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that >> by default, we'd run load -K i915kms instead of load i915kms. We'd augment >> the built-in load command so it knew that -K means 'add the kernel to the >> path last rather than first'. This would solve one of the POLA violations >> in a very targeted way: people that put i915kms_load=YES in their >> loader.conf wouldn't be surprised by this transition. It would be at the >> cost of 2 entires in loader.conf, I believe, and it shuts down one vector >> of hassle for our users. People do this, btw, to get more lines / columns >> in the BIOS boot environment for their console, so it's not an unreasonable >> path to attend to. >> >> We could also have a sysctl that we could set to override specific >> modules locations. This would allow the graphics port to have a rc script >> that sets this up so when X11 goes to automatically load the module, the >> right one gets loaded. This would solve the issue for the people that 'do >> nothing' except install the port. While it's a small bit of programming for >> the kernel, it's a general mechanism that's laser-focused on exceptions to >> the rule w/o wholesale changes. This would solve the other main vector and >> motivator for the 'kill it with fire' calls that doesn't leave behind a >> scorched earth. >> > > > Just a small note here. With the modesetting driver (which is replacing > the deprecated xf86-video-intel and is built into Xorg), X will not load > the drm driver for you. It has to be done by putting kld_list="i915kms" in > your rc.conf (I don't think loading drm next modules from /boot/loader.conf > works). > I have done this in the past, but I had to jump through a number of hoops to do it. I'll have to buy a laptop and see if I can do it with modern gear and modern software. But if X isn't loading the module for you, that makes the problem much, much easier. Warner From owner-freebsd-current@freebsd.org Fri Aug 24 16:16: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 112CD108E2F2 for ; Fri, 24 Aug 2018 16:16:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 93DF78CAAB for ; Fri, 24 Aug 2018 16:16:39 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 10998061-a7b9-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 10998061-a7b9-11e8-aff6-0b9b8210da61; Fri, 24 Aug 2018 16:16:34 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7OGGVXK000911; Fri, 24 Aug 2018 10:16:31 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535127391.1488.23.camel@freebsd.org> Subject: Re: priority of paths to kernel modules? From: Ian Lepore To: Cy Schubert , Johannes Lundberg , freebsd-current Date: Fri, 24 Aug 2018 10:16:31 -0600 In-Reply-To: <20180824153611.7F83C1AC@spqr.komquats.com> References: <20180824153611.7F83C1AC@spqr.komquats.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 16:16:40 -0000 On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > My idea, which I implemented locally and should probably create a > phab review, was to ifdef DRM in modules/Makefile. We could do this > too. Default not to build/install. > This seems like the obvious fix. I thought the whole point of all this is that we support drm2 on some platforms, but not x86 anymore. So to me that implies not building the modules by default on x86. -- Ian > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -----Original Message----- > From: Johannes Lundberg > Sent: 24/08/2018 01:08 > To: freebsd-current > Subject: priority of paths to kernel modules? > > Hi > > Since we now stuck with drm2 in base for a few more years I have an > idea > would make things much smoother for many of us, hugely reduce the > amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > module_path="/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel > have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed > in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct > this is a > flaw and /boot/ should be inserted last so that any > overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and > you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > _______________________________________________ > 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" > > _______________________________________________ > 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 Fri Aug 24 16:45: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 6EE7A108E97A for ; Fri, 24 Aug 2018 16:45:02 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D87FB8D785; Fri, 24 Aug 2018 16:45:01 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id q8-v6so2251346wmq.4; Fri, 24 Aug 2018 09:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/LV4my5RRargcD9f2SXZUx0k8nC6BybLAj3x+cVY4JM=; b=GPLxQCA3h5id+W3FrfbarR9LDNtgmLbcR60WwSx+GU1SOEbqIkScDfgn+IUHVreOS+ RkI6uW5WDvkfCTriY6TX6YTbbI6ISr1hCKbyvlY22xUR6AxuUP+IwhOTekogGpLKqBKK 1I81Ra3yhFTclqXZQP0FFvPRyYcBGQMQ/YxR1sDqXtt1eLjVte2E29nfHPMmLYZE4/pm yRTBxOKPq6p5SKDzFZHQTKO6cQrL5t9k95hD40s10eim2VjrSIwy2j88nab2Ms6lgx8R YXtnJ9uYIaO19vRisVgYQJGkqBMjqn4buIkvsFDEtn6/OUMZORXcs/2FDfxkykjfcIP+ R4rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/LV4my5RRargcD9f2SXZUx0k8nC6BybLAj3x+cVY4JM=; b=QR/2zRuyFNJthuPhLcqZ8mjnxyM5HK7i4ruPRtLK8tgb4vPuqieIGOF5v5mfdukWLp gLNAQ82El8sKhiOfNJvI1dOBYj5OpR6lo6JddnBi3U9YlNqXEJH/wxAFNj88jVxFLRFd a1hAgSbIBri7bvk5Zw79pYJpAm1IGe9MkWT1PjcYazgiFROS8kFlXcdQYgZ1s4TR9ErC FvObPGNtOEmyjO15D0J0+xY1DV6IgrGhr591vsS3yo73vYYDNOQrpia3DromzMUrTNS0 F+RLqU1egdf+NxdhovVfjrYBDlE4f5QE3vxpz+vBFvf5iwE/E/0pJ4WiNSSht1b/zloQ qj+w== X-Gm-Message-State: APzg51Cx3KmatPfzGZY6xJ6GDU/QTZ99M1C15bsXrTauDhSAE4VFniMR uUGcX4GpsnqnNgndka55pAoC1hM+EYfHsDmYLsE= X-Google-Smtp-Source: ANB0VdYRa5Bjbb5L1mBQaNHBEbBAlf9ujv51axRK0H6LCbReMlPNDi894eccBbvmWPNSODBle+gircT3SWpW54A5cZQ= X-Received: by 2002:a1c:f03:: with SMTP id 3-v6mr1890685wmp.129.1535129100654; Fri, 24 Aug 2018 09:45:00 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Johannes Lundberg Date: Fri, 24 Aug 2018 18:44:23 +0200 Message-ID: Subject: Re: priority of paths to kernel modules? To: Warner Losh Cc: freebsd-rwg@pdx.rh.cn85.dnsmgr.net, kevans@freebsd.org, Matthew Macy , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 16:45:02 -0000 On Fri, Aug 24, 2018 at 5:43 PM Warner Losh wrote: > > > On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg > wrote: > >> There's some tricks we can do here. >>> >>> First, I talked to Kyle yesterday about augmenting the Lua loader to >>> have a X_loadflag option. Some background. We look at a lot of X_xxxx flags >>> for loading modules. X_load=yes being the most familiar. One way to avoid >>> POLA would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so >>> that by default, we'd run load -K i915kms instead of load i915kms. We'd >>> augment the built-in load command so it knew that -K means 'add the kernel >>> to the path last rather than first'. This would solve one of the POLA >>> violations in a very targeted way: people that put i915kms_load=YES in >>> their loader.conf wouldn't be surprised by this transition. It would be at >>> the cost of 2 entires in loader.conf, I believe, and it shuts down one >>> vector of hassle for our users. People do this, btw, to get more lines / >>> columns in the BIOS boot environment for their console, so it's not an >>> unreasonable path to attend to. >>> >>> We could also have a sysctl that we could set to override specific >>> modules locations. This would allow the graphics port to have a rc script >>> that sets this up so when X11 goes to automatically load the module, the >>> right one gets loaded. This would solve the issue for the people that 'do >>> nothing' except install the port. While it's a small bit of programming for >>> the kernel, it's a general mechanism that's laser-focused on exceptions to >>> the rule w/o wholesale changes. This would solve the other main vector and >>> motivator for the 'kill it with fire' calls that doesn't leave behind a >>> scorched earth. >>> >> >> >> Just a small note here. With the modesetting driver (which is replacing >> the deprecated xf86-video-intel and is built into Xorg), X will not load >> the drm driver for you. It has to be done by putting kld_list="i915kms" in >> your rc.conf (I don't think loading drm next modules from /boot/loader.conf >> works). >> > > I have done this in the past, but I had to jump through a number of hoops > to do it. I'll have to buy a laptop and see if I can do it with modern gear > and modern software. > > But if X isn't loading the module for you, that makes the problem much, > much easier. > Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon, X might still do it. Need to test to confirm. However, there's nothing stopping you from loading it in rc.conf before starting X (which is probably better anyway). > Warner > From owner-freebsd-current@freebsd.org Fri Aug 24 18:32:23 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 C426310912E7 for ; Fri, 24 Aug 2018 18:32:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 494DF71AE2; Fri, 24 Aug 2018 18:32:23 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id tGq1fJuIXWppDtGq2ffrsf; Fri, 24 Aug 2018 12:29:40 -0600 X-Authority-Analysis: v=2.3 cv=YIcrNiOx c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=dapMudl6Dx4A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=8SmM-VJUJX5Xg7LfDU4A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTPS id A0C702E7; Fri, 24 Aug 2018 11:30:12 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w7OITKHD030020; Fri, 24 Aug 2018 11:29:20 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w7OITKON030017; Fri, 24 Aug 2018 11:29:20 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201808241829.w7OITKON030017@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Ian Lepore cc: Cy Schubert , Johannes Lundberg , freebsd-current Subject: Re: priority of paths to kernel modules? In-Reply-To: Message from Ian Lepore of "Fri, 24 Aug 2018 10:16:31 -0600." <1535127391.1488.23.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Aug 2018 11:29:20 -0700 X-CMAE-Envelope: MS4wfNeG0s/SZAWMgqvsuA9ftK3puypUgwczYGVhHoeIRp/OPshU/LHhUQEgZrV5oJuyMCbjND7JCfYkl28XcfFdDKKG588dLdBudB1tOLmqbUFM+iOx8/VI 39hNN7ROCWRxg4TSuGDwO/U1KdlvY1Yqm5KNOirjTtJ+8AFEPYm1EelLtxZLpn7+G9iV16dl+V/V18uvNrltaRcbItkBz/y9skpjgdNOOS55rQMN89rrGuF1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 18:32:23 -0000 In message <1535127391.1488.23.camel@freebsd.org>, Ian Lepore writes: > On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > > My idea, which I implemented locally and should probably create a > > phab review, was to ifdef DRM in modules/Makefile. We could do this > > too. Default not to build/install. > > > > This seems like the obvious fix. I thought the whole point of all this > is that we support drm2 on some platforms, but not x86 anymore. So to > me that implies not building the modules by default on x86. Then we limit it knob to only those platforms we wish to remove it from now. I suggested default off however in a private email I received it was intimated to me that default on for the first while would be better. Personally, I don't care about the minutia but I do care that we have some kind of migration roadmap. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Aug 24 19:59: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 CC63B10929E3 for ; Fri, 24 Aug 2018 19:59:59 +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 569CF745C2; Fri, 24 Aug 2018 19:59:59 +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 w7OJxm2K084140 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Aug 2018 22:59:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7OJxm2K084140 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7OJxlO4084139; Fri, 24 Aug 2018 22:59:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Aug 2018 22:59:47 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180824195947.GG2340@kib.kiev.ua> References: <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> <20180822211528.GB2340@kib.kiev.ua> <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:00:00 -0000 On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote: > > > > On 22. Aug 2018, at 23:15, Konstantin Belousov wrote: > > > >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote: > >> > >> > >>>> On 22. Aug 2018, at 17:46, Konstantin Belousov wrote: > >>>> > >>>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: > >>>> > >>>> > >>>>>> On 20. Aug 2018, at 17:09, Konstantin Belousov wrote: > >>>>>> > >>>>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: > >>>>>> > >>>>>> See here for a screenshot (also including the output of "show pte > >>>>>> 0xfffff80001000000"): > >>>>>> > >>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png > >>>>> It is too early for ddb routines to register. > >>>>> Ok can you try the following debugging patch, to verify my guess ? > >>>>> > >>>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > >>>>> index 18777d23f09..cd05fdb763f 100644 > >>>>> --- a/sys/amd64/amd64/pmap.c > >>>>> +++ b/sys/amd64/amd64/pmap.c > >>>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) > >>>>> pd_p = (pd_entry_t *)DMPDkernphys; > >>>>> for (i = 0; i < (NPDEPG * nkdmpde); i++) > >>>>> pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | > >>>>> - X86_PG_M | X86_PG_A | pg_nx | > >>>>> - bootaddr_rwx(i << PDRSHIFT); > >>>>> + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; > >>>>> for (i = 0; i < nkdmpde; i++) > >>>>> pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW | > >>>>> X86_PG_V; > >>>> > >>>> With this change it boots okay (mptramp_pagetables is 0x1000000, as expected). > >>> > >>> Can you apply the following on top of the previous debugging patch and show > >>> me the line printed ? > >>> > >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > >>> index 3d70532b7fd..613fa9f2165 100644 > >>> --- a/sys/amd64/amd64/pmap.c > >>> +++ b/sys/amd64/amd64/pmap.c > >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) > >>> pmap->pm_pcids[i].pm_gen = 1; > >>> } > >>> pmap_activate_boot(pmap); > >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx etext %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uintptr_t)KERNBASE); > >>> } > >>> > >>> void > >> > >> bootaddr addr 0x1000000 rwx 0 btext 0xffffffff80342000 _end 0xffffffff823cf840 brwsection #ffffffff81a00000 etext 0xffffffff812041e4 KERNBASE 0xffffffff80000000 > >> > > > > Try this, please. Revert all debugging pmap.c patches that I provided > > before. > > > > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c > > index 4ca2e07e578..2ee8f862854 100644 > > --- a/sys/amd64/amd64/mp_machdep.c > > +++ b/sys/amd64/amd64/mp_machdep.c > > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); > > > > #define GiB(v) (v ## ULL << 30) > > > > +#define AP_BOOTPT_SZ (PAGE_SIZE * 3) > > + > > extern struct pcpu __pcpu[]; > > > > /* Temporary variables for init_secondary() */ > > @@ -101,45 +103,78 @@ char *dbg_stack; > > > > static int start_ap(int apic_id); > > > > +static bool > > +is_kernel_paddr(vm_paddr_t pa) > > +{ > > + > > + return (pa >= trunc_2mpage(btext - KERNBASE) && > > + pa < round_page(_end - KERNBASE)); > > +} > > + > > +static bool > > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end) > > +{ > > + > > + return (start + AP_BOOTPT_SZ <= GiB(4) && > > + end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem); > > +} > > + > > /* > > * Calculate usable address in base memory for AP trampoline code. > > */ > > void > > mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) > > { > > + vm_paddr_t start, end; > > unsigned int i; > > bool allocated; > > > > alloc_ap_trampoline(physmap, physmap_idx); > > > > + /* > > + * Find a memory region big enough below the 4GB boundary to > > + * store the initial page tables. Region must be mapped by > > + * the direct map. > > + * > > + * Note that it needs to be aligned to a page boundary. > > + */ > > allocated = false; > > for (i = *physmap_idx; i <= *physmap_idx; i -= 2) { > > /* > > - * Find a memory region big enough below the 4GB > > - * boundary to store the initial page tables. Region > > - * must be mapped by the direct map. > > - * > > - * Note that it needs to be aligned to a page > > - * boundary. > > + * First, try to chomp at the start of the physmap region. > > + * Kernel binary might claim it already. > > + */ > > + start = round_page(physmap[i]); > > + end = trunc_page(physmap[i + 1]); > > + if (is_mpboot_good(start, end) && > > + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > > + allocated = true; > > + physmap[i] = start + AP_BOOTPT_SZ; > > + break; > > + } > > + > > + /* > > + * Second, try to chomp at the end. Again, check > > + * against kernel. > > */ > > - if (physmap[i] >= GiB(4) || physmap[i + 1] - > > - round_page(physmap[i]) < PAGE_SIZE * 3 || > > - atop(physmap[i + 1]) > Maxmem) > > - continue; > > - > > - allocated = true; > > - mptramp_pagetables = round_page(physmap[i]); > > - physmap[i] = round_page(physmap[i]) + (PAGE_SIZE * 3); > > + end = trunc_page(physmap[i + 1]); > > + start = end - AP_BOOTPT_SZ; > > + if (start >= physmap[i] && is_mpboot_good(start, end) && > > + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > > + allocated = true; > > + physmap[i + 1] = start; > > + break; > > + } > > + } > > + if (allocated) { > > + mptramp_pagetables = start; > > if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) { > > memmove(&physmap[i], &physmap[i + 2], > > sizeof(*physmap) * (*physmap_idx - i + 2)); > > *physmap_idx -= 2; > > } > > - break; > > - } > > - > > - if (!allocated) { > > - mptramp_pagetables = trunc_page(boot_address) - (PAGE_SIZE * 3); > > + } else { > > + mptramp_pagetables = trunc_page(boot_address) - AP_BOOTPT_SZ; > > if (bootverbose) > > printf( > > "Cannot find enough space for the initial AP page tables, placing them at %#x", > > Reverted back to r337813 and applied the patch. Unfortunately it panics just like before. Adding back physmap debugging like before shows that it???s still using pages 0x1000-0x1003 (Stopped at native_start_all_aps+0x92: movq %rax,(%rsi)) > Please apply the following debugging patch on top of the previous 'fix'. You need debug.late_console=0. diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c index 2ee8f862854..1a14b1800b1 100644 --- a/sys/amd64/amd64/mp_machdep.c +++ b/sys/amd64/amd64/mp_machdep.c @@ -130,7 +130,7 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) bool allocated; alloc_ap_trampoline(physmap, physmap_idx); - +printf("btext %#lx _end %#lx brwsection %#lx etext %#lx KERNBASE %#lx\n", (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (uintptr_t)KERNBASE); /* * Find a memory region big enough below the 4GB boundary to * store the initial page tables. Region must be mapped by @@ -146,10 +146,13 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) */ start = round_page(physmap[i]); end = trunc_page(physmap[i + 1]); +printf("physmap[%d] %#lx physmap[%d] %#lx\n", i, physmap[i], i + 1, physmap[i + 1]); +printf("start %#lx end %#lx is_mpboot_good %d is_kernel_paddr(start) %d is_kernel_paddr(end - 1) %d\n", start, end, is_mpboot_good(start, end), is_kernel_paddr(start), is_kernel_paddr(end - 1)); if (is_mpboot_good(start, end) && !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { allocated = true; physmap[i] = start + AP_BOOTPT_SZ; +printf("allocated\n"); break; } @@ -159,10 +162,12 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) */ end = trunc_page(physmap[i + 1]); start = end - AP_BOOTPT_SZ; +printf("start %#lx end %#lx is_mpboot_good %d is_kernel_paddr(start) %d is_kernel_paddr(end - 1) %d\n", start, end, is_mpboot_good(start, end), is_kernel_paddr(start), is_kernel_paddr(end - 1)); if (start >= physmap[i] && is_mpboot_good(start, end) && !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { allocated = true; physmap[i + 1] = start; +printf("allocated\n"); break; } } From owner-freebsd-current@freebsd.org Fri Aug 24 20:32:17 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 47ADE10932A3 for ; Fri, 24 Aug 2018 20:32:17 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id B809275684 for ; Fri, 24 Aug 2018 20:32:16 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 64687 invoked by uid 89); 24 Aug 2018 20:32:08 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 24 Aug 2018 20:32:08 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180824195947.GG2340@kib.kiev.ua> Date: Fri, 24 Aug 2018 22:32:06 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: <32F22868-92ED-4223-84B5-77E72C7DCF50@grem.de> References: <8726bc32-6023-bfe1-7600-5b2c706236f8@FreeBSD.org> <20180819165951.274d61b0@bsd64.grem.de> <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> <20180822211528.GB2340@kib.kiev.ua> <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> <20180824195947.GG2340@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:32:17 -0000 > On 24. Aug 2018, at 21:59, Konstantin Belousov wrote= : >=20 >> On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote: >>=20 >>=20 >>>> On 22. Aug 2018, at 23:15, Konstantin Belousov wr= ote: >>>>=20 >>>> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote: >>>>=20 >>>>=20 >>>>>> On 22. Aug 2018, at 17:46, Konstantin Belousov w= rote: >>>>>>=20 >>>>>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote: >>>>>>=20 >>>>>>=20 >>>>>>>> On 20. Aug 2018, at 17:09, Konstantin Belousov wrote: >>>>>>>>=20 >>>>>>>> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote: >>>>>>>>=20 >>>>>>>> See here for a screenshot (also including the output of "show pte >>>>>>>> 0xfffff80001000000"): >>>>>>>>=20 >>>>>>>> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#fil= e-ddb1-png >>>>>>> It is too early for ddb routines to register. >>>>>>> Ok can you try the following debugging patch, to verify my guess ? >>>>>>>=20 >>>>>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>>>>>> index 18777d23f09..cd05fdb763f 100644 >>>>>>> --- a/sys/amd64/amd64/pmap.c >>>>>>> +++ b/sys/amd64/amd64/pmap.c >>>>>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr) >>>>>>> pd_p =3D (pd_entry_t *)DMPDkernphys; >>>>>>> for (i =3D 0; i < (NPDEPG * nkdmpde); i++) >>>>>>> pd_p[i] =3D (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g | >>>>>>> - X86_PG_M | X86_PG_A | pg_nx | >>>>>>> - bootaddr_rwx(i << PDRSHIFT); >>>>>>> + X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW; >>>>>>> for (i =3D 0; i < nkdmpde; i++) >>>>>>> pdp_p[i] =3D (DMPDkernphys + ptoa(i)) | X86_PG_RW | >>>>>>> X86_PG_V; >>>>>>=20 >>>>>> With this change it boots okay (mptramp_pagetables is 0x1000000, as e= xpected). >>>>>=20 >>>>> Can you apply the following on top of the previous debugging patch and= show >>>>> me the line printed ? >>>>>=20 >>>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c >>>>> index 3d70532b7fd..613fa9f2165 100644 >>>>> --- a/sys/amd64/amd64/pmap.c >>>>> +++ b/sys/amd64/amd64/pmap.c >>>>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap) >>>>> pmap->pm_pcids[i].pm_gen =3D 1; >>>>> } >>>>> pmap_activate_boot(pmap); >>>>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %= #lx etext %#lx KERNBASE %#lx\n", 0x1000000UL, bootaddr_rwx(0x1000000UL), (ui= ntptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext, (ui= ntptr_t)KERNBASE); >>>>> } >>>>>=20 >>>>> void >>>>=20 >>>> bootaddr addr 0x1000000 rwx 0 btext 0xffffffff80342000 _end 0xffffffff8= 23cf840 brwsection #ffffffff81a00000 etext 0xffffffff812041e4 KERNBASE 0xfff= fffff80000000 >>>>=20 >>>=20 >>> Try this, please. Revert all debugging pmap.c patches that I provided >>> before. >>>=20 >>> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c= >>> index 4ca2e07e578..2ee8f862854 100644 >>> --- a/sys/amd64/amd64/mp_machdep.c >>> +++ b/sys/amd64/amd64/mp_machdep.c >>> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$"); >>>=20 >>> #define GiB(v) (v ## ULL << 30) >>>=20 >>> +#define AP_BOOTPT_SZ (PAGE_SIZE * 3) >>> + >>> extern struct pcpu __pcpu[]; >>>=20 >>> /* Temporary variables for init_secondary() */ >>> @@ -101,45 +103,78 @@ char *dbg_stack; >>>=20 >>> static int start_ap(int apic_id); >>>=20 >>> +static bool >>> +is_kernel_paddr(vm_paddr_t pa) >>> +{ >>> + >>> + return (pa >=3D trunc_2mpage(btext - KERNBASE) && >>> + pa < round_page(_end - KERNBASE)); >>> +} >>> + >>> +static bool >>> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end) >>> +{ >>> + >>> + return (start + AP_BOOTPT_SZ <=3D GiB(4) && >>> + end >=3D start + AP_BOOTPT_SZ && atop(end) < Maxmem); >>> +} >>> + >>> /* >>> * Calculate usable address in base memory for AP trampoline code. >>> */ >>> void >>> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) >>> { >>> + vm_paddr_t start, end; >>> unsigned int i; >>> bool allocated; >>>=20 >>> alloc_ap_trampoline(physmap, physmap_idx); >>>=20 >>> + /* >>> + * Find a memory region big enough below the 4GB boundary to >>> + * store the initial page tables. Region must be mapped by >>> + * the direct map. >>> + * >>> + * Note that it needs to be aligned to a page boundary. >>> + */ >>> allocated =3D false; >>> for (i =3D *physmap_idx; i <=3D *physmap_idx; i -=3D 2) { >>> /* >>> - * Find a memory region big enough below the 4GB >>> - * boundary to store the initial page tables. Region >>> - * must be mapped by the direct map. >>> - * >>> - * Note that it needs to be aligned to a page >>> - * boundary. >>> + * First, try to chomp at the start of the physmap region. >>> + * Kernel binary might claim it already. >>> + */ >>> + start =3D round_page(physmap[i]); >>> + end =3D trunc_page(physmap[i + 1]); >>> + if (is_mpboot_good(start, end) && >>> + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { >>> + allocated =3D true; >>> + physmap[i] =3D start + AP_BOOTPT_SZ; >>> + break; >>> + } >>> + >>> + /* >>> + * Second, try to chomp at the end. Again, check >>> + * against kernel. >>> */ >>> - if (physmap[i] >=3D GiB(4) || physmap[i + 1] - >>> - round_page(physmap[i]) < PAGE_SIZE * 3 || >>> - atop(physmap[i + 1]) > Maxmem) >>> - continue; >>> - >>> - allocated =3D true; >>> - mptramp_pagetables =3D round_page(physmap[i]); >>> - physmap[i] =3D round_page(physmap[i]) + (PAGE_SIZE * 3); >>> + end =3D trunc_page(physmap[i + 1]); >>> + start =3D end - AP_BOOTPT_SZ; >>> + if (start >=3D physmap[i] && is_mpboot_good(start, end) && >>> + !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { >>> + allocated =3D true; >>> + physmap[i + 1] =3D start; >>> + break; >>> + } >>> + } >>> + if (allocated) { >>> + mptramp_pagetables =3D start; >>> if (physmap[i] =3D=3D physmap[i + 1] && *physmap_idx !=3D 0) { >>> memmove(&physmap[i], &physmap[i + 2], >>> sizeof(*physmap) * (*physmap_idx - i + 2)); >>> *physmap_idx -=3D 2; >>> } >>> - break; >>> - } >>> - >>> - if (!allocated) { >>> - mptramp_pagetables =3D trunc_page(boot_address) - (PAGE_SIZE * 3= ); >>> + } else { >>> + mptramp_pagetables =3D trunc_page(boot_address) - AP_BOOTPT_SZ;= >>> if (bootverbose) >>> printf( >>> "Cannot find enough space for the initial AP page tables, placing them a= t %#x", >>=20 >> Reverted back to r337813 and applied the patch. Unfortunately it panics j= ust like before. Adding back physmap debugging like before shows that it???s= still using pages 0x1000-0x1003 (Stopped at native_start_all_aps+0x92: movq= %rax,(%rsi)) >>=20 >=20 > Please apply the following debugging patch on top of the previous 'fix'. > You need debug.late_console=3D0. Unfortunately debug.late_console=3D0 doesn=E2=80=99t work on this machine (n= o more output on the console), I tried that earlier in this thread - hence t= he slightly complicated debugging code I had to add to see the contents of p= hysmap. I could run this code after boot (feeding it an identical physmap) to get de= bug output, would this make sense? Best, Michael >=20 > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c > index 2ee8f862854..1a14b1800b1 100644 > --- a/sys/amd64/amd64/mp_machdep.c > +++ b/sys/amd64/amd64/mp_machdep.c > @@ -130,7 +130,7 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *phys= map_idx) > bool allocated; >=20 > alloc_ap_trampoline(physmap, physmap_idx); > - > +printf("btext %#lx _end %#lx brwsection %#lx etext %#lx KERNBASE %#lx\n",= (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection, (uintptr_t)etext,= (uintptr_t)KERNBASE); > /* > * Find a memory region big enough below the 4GB boundary to > * store the initial page tables. Region must be mapped by > @@ -146,10 +146,13 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *ph= ysmap_idx) > */ > start =3D round_page(physmap[i]); > end =3D trunc_page(physmap[i + 1]); > +printf("physmap[%d] %#lx physmap[%d] %#lx\n", i, physmap[i], i + 1, physm= ap[i + 1]); > +printf("start %#lx end %#lx is_mpboot_good %d is_kernel_paddr(start) %d i= s_kernel_paddr(end - 1) %d\n", start, end, is_mpboot_good(start, end), is_ke= rnel_paddr(start), is_kernel_paddr(end - 1)); > if (is_mpboot_good(start, end) && > !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > allocated =3D true; > physmap[i] =3D start + AP_BOOTPT_SZ; > +printf("allocated\n"); > break; > } >=20 > @@ -159,10 +162,12 @@ mp_bootaddress(vm_paddr_t *physmap, unsigned int *ph= ysmap_idx) > */ > end =3D trunc_page(physmap[i + 1]); > start =3D end - AP_BOOTPT_SZ; > +printf("start %#lx end %#lx is_mpboot_good %d is_kernel_paddr(start) %d i= s_kernel_paddr(end - 1) %d\n", start, end, is_mpboot_good(start, end), is_ke= rnel_paddr(start), is_kernel_paddr(end - 1)); > if (start >=3D physmap[i] && is_mpboot_good(start, end) && > !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { > allocated =3D true; > physmap[i + 1] =3D start; > +printf("allocated\n"); > break; > } > } From owner-freebsd-current@freebsd.org Fri Aug 24 20:39: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 96F501093439 for ; Fri, 24 Aug 2018 20:39:18 +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 13689758EF; Fri, 24 Aug 2018 20:39:17 +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 w7OKd3Ja093295 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Aug 2018 23:39:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w7OKd3Ja093295 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w7OKd3ho093294; Fri, 24 Aug 2018 23:39:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 24 Aug 2018 23:39:03 +0300 From: Konstantin Belousov To: Michael Gmelin Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) Message-ID: <20180824203903.GJ2340@kib.kiev.ua> References: <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> <20180822211528.GB2340@kib.kiev.ua> <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> <20180824195947.GG2340@kib.kiev.ua> <32F22868-92ED-4223-84B5-77E72C7DCF50@grem.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32F22868-92ED-4223-84B5-77E72C7DCF50@grem.de> User-Agent: Mutt/1.10.1 (2018-07-13) 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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 20:39:18 -0000 On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote: > > > > On 24. Aug 2018, at 21:59, Konstantin Belousov wrote: > > Please apply the following debugging patch on top of the previous 'fix'. > > You need debug.late_console=0. > > Unfortunately debug.late_console=0 doesn???t work on this machine (no more output on the console), I tried that earlier in this thread - hence the slightly complicated debugging code I had to add to see the contents of physmap. > > I could run this code after boot (feeding it an identical physmap) to get debug output, would this make sense? > Yes, with exactly the same physmap[]. Really, I do not need exactly the output from my patch, but just make it clear why is_kernel_paddr() did not triggered selection from different location. From owner-freebsd-current@freebsd.org Fri Aug 24 21:53: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 CC3501094ABD; Fri, 24 Aug 2018 21:53:06 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 387B977FFA; Fri, 24 Aug 2018 21:53:06 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id n2-v6so8542912wrw.7; Fri, 24 Aug 2018 14:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ytAhTE1wNoJLS7qlLpanApV03J7UxSnyPtJWmU3FepM=; b=NWJpgy+EcjXLn3YEPfnYD4pvm4pXQDQhb5TmWHC0KpXOauQ4wp4CdTUjvPY8ke+Qci 5j/v5VvwFes2VeWDKJvohoM0HrZRITb5MC9Ow+ST8XnMIHH31xJ70A/3JyrutKwClzYe g2squOxEQQ3kQXDFNfAD/eV3egt3MRu+o7OfenTCwPxh/m3nnYJ0AnT9lOSKF8IesZ6b PJDAOdr49szksDLu0c+y4MHPrEhWlWOgyC0bgTthW14ZgQIqcQuVtZqYL8AByVARP6Xz iB5EAe7ps+xdgm5z7L3YlNxiIZ3nvLvpknGVhLDbIcmUqcr1vAoq9wbrEmITSN2coZQW 6yoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ytAhTE1wNoJLS7qlLpanApV03J7UxSnyPtJWmU3FepM=; b=K3r2Aju+GLhh1Ba/5RoWJjp3ocybEyy0O2XyZMr8C7+HltNHYISMDsI3gmlueTBJFX nBfWvB4o6FDshyqzcZeijI2I3r5O071XxoM9XkXUZ0Yf2jXcH8PTqqZ9ipPti6v5CR4B scbdtZQpYtvw6WX8wFuRIuA4jE1Gccs0Nu9O2yFhQQcAofqcQXGUcE8egY1IAmVzkZd0 n6TkPlCht7eXYrhjCWAG1aqK+Ig2IwpCDJ67LcNf+KY+BpSeH6qfl3JGCm/zL3vXSkFB f/Jthyje678NxhO3r5to5D5utE2dTT0EvgZF7eopoLuUVoPMJcNu4wvmihCrlhRbonyk 6LLw== X-Gm-Message-State: APzg51D9xzZvHG7A3vW6DPTnERQJ46IR5WMmqru6Pb6iwh9FiW/qKr5b kvldCcHiM7nTJuCsOHhsfalHPdhe X-Google-Smtp-Source: ANB0VdZTFCK5/exeuahrLNTev/IlM2odpNTqJzCjoCT32VwGTKAatHLtLB4+sBeFDp2VDLnL5AqKrg== X-Received: by 2002:adf:e648:: with SMTP id b8-v6mr2411265wrn.254.1535147584866; Fri, 24 Aug 2018 14:53:04 -0700 (PDT) Received: from freebsd480.station (net-2-39-246-29.cust.vodafonedsl.it. [2.39.246.29]) by smtp.gmail.com with ESMTPSA id h75-v6sm6443308wma.46.2018.08.24.14.53.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 14:53:04 -0700 (PDT) From: Ali X-Google-Original-From: Ali Date: Fri, 24 Aug 2018 23:53:02 +0200 To: Matthew Macy Cc: freebsd-current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 Message-ID: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 21:53:07 -0000 On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: > > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install the > graphics/drm-legacy-kmod. All other users should be able to use > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. > Note that this applies only to 12. I see that The removal of drm and drm2 has been reverted on svn. Could you please kindly share the reasons behind the re-inclusion? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Fri Aug 24 22:19:35 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 D500310954F9; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D6DE794E8; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 3A7C5A213; Fri, 24 Aug 2018 22:19:34 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f52.google.com with SMTP id t69-v6so3804068itb.4; Fri, 24 Aug 2018 15:19:34 -0700 (PDT) X-Gm-Message-State: APzg51AtpHvTriTCNZYHjYDnyDFJwex6mBsG1qYcHkNSZpWAp0v5vnt7 tKPdZWKM07Fz4X9WhQG25CCKgiGE4Ecf4KhQ6ZE= X-Google-Smtp-Source: ANB0Vdb82xCipaPvmswTEK+Rz4RPivDeBWpQpIbzyGTWFY8jxZvcTBsEiEkTuC7XXrbRA8kErWg7ZzQBQWLwRocRuOk= X-Received: by 2002:a02:88ad:: with SMTP id n42-v6mr2785567jaj.38.1535149173394; Fri, 24 Aug 2018 15:19:33 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Matthew Macy Date: Fri, 24 Aug 2018 15:19:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: drm / drm2 removal in 12 To: Ali Cc: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:19:35 -0000 On Fri, Aug 24, 2018 at 14:53 Ali wrote: > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > Just in case anyone misses the change to UPDATING: > > > > 20180821: > > drm and drm2 have been removed. Users on powerpc, 32-bit > hardware, > > or with GPUs predating Radeon and i915 will need to install the > > graphics/drm-legacy-kmod. All other users should be able to use > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > Note that this applies only to 12. > > I see that The removal of drm and drm2 has been reverted on svn. Could > you please kindly share the reasons behind the re-inclusion? > I can=E2=80=99t really give the blow by blow of internal project drama, but= the gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet actu= ally documented anywhere that I=E2=80=99ve seen) were not followed with regards to the depr= ecation process. Warner and others believe that we can address the objectives of the drm removal (improving the user experience and communicating that drm/drm2 are _completely_ unsupported apart from continuing to compile) through less disruptive means. I am only acting as a lightning rod and representative of the graphics team and so have done an inadequate job of tracking their activities with respect to project timelines. As a result of this misunderstanding Johannes Lundberg will be sponsored for a bit and will be able to be involved in internal discussions that impact his work. Our only continued frustration is that we were never given any guidance by RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion was= taking place in May and then those groups behaved as if this were a surprise when the removal happened. I=E2=80=99m cautiously optimistic that this well expedite improving communications on those matters. Cheers. -M From owner-freebsd-current@freebsd.org Fri Aug 24 22:20: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 AA64B1095554 for ; Fri, 24 Aug 2018 22:20:29 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6E279562; Fri, 24 Aug 2018 22:20:29 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 41xwhW558wzDhgL; Fri, 24 Aug 2018 22:20:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id tvGafZ66e9sQ; Fri, 24 Aug 2018 22:20:27 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:9eda:3eff:fe70:24c0]) by mail.daemonic.se (Postfix) with ESMTPSA id 41xwhV3SSGzDhFd; Fri, 24 Aug 2018 22:20:26 +0000 (UTC) Subject: Re: priority of paths to kernel modules? To: Warner Losh , "Rodney W. Grimes" Cc: Kyle Evans , Johannes Lundberg , Matt Macy , FreeBSD Current References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> From: Niclas Zeising Message-ID: Date: Sat, 25 Aug 2018 00:20:26 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: 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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:20:29 -0000 On 08/24/18 17:20, Warner Losh wrote: > This would allow the graphics port to have a rc script that sets > this up so when X11 goes to automatically load the module, the right one > gets loaded. > I just want to point out that X11 doesn't load the graphics kernel driver by default when using the drm-*-kmod ports, and I'm not sure the hack to have the intel ddx (xf86-video-intel) load the drm2 driver is still around. It doesn't really matter though, since upstream is moving away from having X load the driver, and I'd like us to follow suit by using devmatch (this is one of the reasons we wanted to get rid of the base drivers, as I've stated before). X can't always know which driver to load (when using modesetting for instance), and in my opinion, it should be the kernel/loader that decides which drivers to load. Regards -- Niclas Zeising From owner-freebsd-current@freebsd.org Fri Aug 24 22:20: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 3AEFB109557D for ; Fri, 24 Aug 2018 22:20:51 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BF88795C6 for ; Fri, 24 Aug 2018 22:20:50 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-ed1-x52b.google.com with SMTP id h9-v6so6767243edr.0 for ; Fri, 24 Aug 2018 15:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=wTGH+FuzhilHklixZ/2pOIaGVobmyczibCXP5roJRXg=; b=dTJCvVOY24Efs+69FOkqXWsgg2g46Vv00/TxKGnqLCqV52DXyfPcA21kdb/rN2nf6r n4HmrjNl7uKDkKOYDfTLyfQ2vqqacLMVNGKvGo+UIatDaqFUotKTVSvA67gFyVinkBEh zwRZ33KRCm+9B3bu9nHlTDropqw2nP2XdfQYHr+tDY+80KDQtS8C3Dsj2G5vHecWb5M9 VgB0e4n0gqP6ESjhZGOleXKej0jfYqK/W4H/lgXCr0AyQAfQY3b52iMghsRvGtE73oSh bhQDKk68GP0rHWYPaziAYOZBNJ8wegTtOEFD4HAyAkLE9uRBTtw/qMYMdvbzS2AP6y1u CGSA== 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=wTGH+FuzhilHklixZ/2pOIaGVobmyczibCXP5roJRXg=; b=lPCjm6yn7Ht2Ac1O7SIz1ravK+p4ab06WoKwIoz4e4p+IyNGkyUKbFna+hGWjO1NVP zZqUzWiIlRoFWjK89NzNd0ca03Aux/OLFtgJUDhR8W/kmrF+VSqefs22WzA7p6VmiVdW vzAL7Ex6RigevOelemOsHVQMiHcJktC2y7J0jI5Gn6G1ymgd2kSsRxE8i/Wam0XeqnKT ajkPD7lpyA9ZhFeUz55bhlhvdAom5FGdbEWr9lPL/vVKYBSpesDJCtP78XoREzVJEJj3 I4ph8nTBJ+XPYfnehk4EdSwtv/gIArc4kmMZjwf8kMkx+DIJT1389p2G5QOtZg/MWFjN nHZw== X-Gm-Message-State: APzg51DzzZS2pqgdP9nqnZN8nX9oN/fK2F3ApauSgqnPHmk2gWkIpNGf Gxfqtg+S9mxfsa0/yLZ87nLd9jUlCgL3uBN/PpTmbHrFHWjZWAs4Zb2I++XCuNZWDKAhO3fMN5F gZXklwSiJiAngjPB8Z8z88QAyp9Bxz0OpfRTFulLwQo8eyYhVvBxO3tmTF1fO85Bu1783aw74Dl zHg1k6kA/1zQ== X-Google-Smtp-Source: ANB0VdZ9QQ1RnyBVsN3YfDn49ub7PMpbR/kmS6VXqKdumqq1CKVfCpkLT6varAr8lfgsCuZm8eanhg== X-Received: by 2002:aa7:d5ca:: with SMTP id d10-v6mr373596eds.161.1535149248354; Fri, 24 Aug 2018 15:20:48 -0700 (PDT) Received: from mutt-hbsd ([185.220.102.6]) by smtp.gmail.com with ESMTPSA id f19-v6sm4361480eda.49.2018.08.24.15.20.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 15:20:47 -0700 (PDT) Date: Fri, 24 Aug 2018 18:19:55 -0400 From: Shawn Webb To: freebsd-current@freebsd.org Subject: ifnet use after free Message-ID: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="saevydtzne433viv" Content-Disposition: inline X-Operating-System: FreeBSD mutt-hbsd 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20180622 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:20:52 -0000 --saevydtzne433viv Content-Type: multipart/mixed; boundary="edrtylun6ewzve3i" Content-Disposition: inline --edrtylun6ewzve3i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey All, Somewhere in the last month or so, a use after free was introduced. I don't have the time right now to bisect the commits and figure out which commit introduced the breakage. Attached is the core.txt (which seems nonsensical because the dump is reporting on a different thread). If the core.txt gets scrubbed, I've posted it here: https://gist.github.com/796ea88cec19a1fd2a85f4913482286a I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a. FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT 2018 shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --edrtylun6ewzve3i Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="core.txt" Content-Transfer-Encoding: quoted-printable hbsd-dev-laptop dumped core - see /var/crash/vmcore.2 Thu Aug 23 20:01:43 EDT 2018 FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4 6091fec317a(har= dened/current/master)-dirty: Thu Aug 23 18:37:45 EDT 2018 shawn@hbsd-de= v-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 panic: Most recently used by ifnet GNU gdb (GDB) 8.1.1 [GDB v8.1.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/de= bug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: [249] Memory modified after free 0xfffff80039c89800(2040) val=3D0 @ 0xfffff= 80039c89b98 [249] panic: Most recently used by ifnet [249]=20 [249] cpuid =3D 3 [249] time =3D 1535066565 [249] __HardenedBSD_version =3D 1200058 __FreeBSD_version =3D 1200081 [249] version =3D FreeBSD 12.0-ALPHA2 #4 6091fec317a(hardened/current/mast= er)-dirty: Thu Aug 23 18:37:45 EDT 2018 [249] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC [249] KDB: stack backtrace: [249] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 00041b6b0 [249] vpanic() at vpanic+0x1a8/frame 0xfffffe000041b710 [249] panic() at panic+0x43/frame 0xfffffe000041b770 [249] mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe000041b790 [249] uma_zalloc_arg() at uma_zalloc_arg+0x718/frame 0xfffffe000041b800 [249] malloc() at malloc+0x78/frame 0xfffffe000041b850 [249] xpt_run_allocq() at xpt_run_allocq+0xca/frame 0xfffffe000041b890 [249] adastrategy() at adastrategy+0x70/frame 0xfffffe000041b8c0 [249] g_disk_start() at g_disk_start+0x333/frame 0xfffffe000041b920 [249] g_io_schedule_down() at g_io_schedule_down+0x10b/frame 0xfffffe000041= b960 [249] g_down_procbody() at g_down_procbody+0x6d/frame 0xfffffe000041b970 [249] fork_exit() at fork_exit+0x89/frame 0xfffffe000041b9b0 [249] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000041b9b0 [249] --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- [249] Uptime: 4m9s [249] Dumping 3665 out of 65350 MB:..1%..11%..21%..31%..41%..51%..61%..71%.= =2E81%..91% __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=3D1) at /usr/src/sys/kern/kern_shutdown.c:368 #2 0xffffffff80ae7da6 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff80ae81f8 in vpanic (fmt=3D, ap=3D0xfffffe00004= 1b750) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0xffffffff80ae7f53 in panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:801 #5 0xffffffff80e1b131 in mtrash_ctor (mem=3D0xfffff80039c89800,=20 size=3D, arg=3D, flags=3D) at /usr/src/sys/vm/uma_dbg.c:162 #6 0xffffffff80e16368 in uma_zalloc_arg (zone=3D0xfffff8000301b3a0, udata= =3D0x0,=20 flags=3D) at /usr/src/sys/vm/uma_core.c:2438 #7 0xffffffff80ac3a28 in uma_zalloc (zone=3D0xfffff8000301b3a0,=20 flags=3D) at /usr/src/sys/vm/uma.h:362 #8 malloc (size=3D1248, mtp=3D0xffffffff8184a490 , flags=3D1) at /usr/src/sys/kern/kern_malloc.c:575 #9 0xffffffff8034299a in xpt_get_ccb_nowait (periph=3D) at /usr/src/sys/cam/cam_xpt.c:4738 #10 xpt_run_allocq (periph=3D0xfffff80003710100, sleep=3D0) at /usr/src/sys/cam/cam_xpt.c:3396 #11 0xffffffff8036cc20 in adaschedule (periph=3D) at /usr/src/sys/cam/ata/ata_da.c:998 #12 adastrategy (bp=3D0xfffff80039317300) at /usr/src/sys/cam/ata/ata_da.c:= 1044 #13 0xffffffff80a2f593 in g_disk_start (bp=3D) at /usr/src/sys/geom/geom_disk.c:478 #14 0xffffffff80a3346b in g_io_schedule_down (tp=3D) at /usr/src/sys/geom/geom_io.c:893 #15 0xffffffff80a33c6d in g_down_procbody (arg=3D) at /usr/src/sys/geom/geom_kern.c:111 #16 0xffffffff80aa9b69 in fork_exit ( callout=3D0xffffffff80a33c00 , arg=3D0x0,=20 frame=3D0xfffffe000041b9c0) at /usr/src/sys/kern/kern_fork.c:1074 #17 (kgdb)=20 ------------------------------------------------------------------------ ps -axlww UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -16 0 0 0 swapin DLs - 0:06.63 [kerne= l] 0 1 0 0 40 0 10036 1208 wait DLs - 0:00.18 [init] 0 2 0 0 -16 0 0 0 crypto_w DL - 0:00.00 [crypt= o] 0 3 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypt= o returns 0] 0 4 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypt= o returns 1] 0 5 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypt= o returns 2] 0 6 0 0 -16 0 0 0 crypto_r DL - 0:00.00 [crypt= o returns 3] 0 7 0 0 -16 0 0 0 - RL - 0:00.00 [cam] 0 8 0 0 -8 0 0 0 arc_recl DL - 0:00.52 [zfske= rn] 0 9 0 0 -16 0 0 0 - DL - 0:00.00 [soaio= d1] 0 10 0 0 -16 0 0 0 audit_wo DL - 0:00.00 [audit] 0 11 0 0 155 0 0 0 - RL - 13:51.22 [idle] 0 12 0 0 -52 0 0 0 - WL - 0:00.80 [intr] 0 13 0 0 -8 0 0 0 - DL - 0:00.75 [geom] 0 14 0 0 -68 0 0 0 - DL - 0:00.06 [usb] 0 15 0 0 -16 0 0 0 - DL - 0:00.00 [soaio= d2] 0 16 0 0 -16 0 0 0 - DL - 0:00.00 [soaio= d3] 0 17 0 0 -16 0 0 0 - DL - 0:00.00 [soaio= d4] 0 18 0 0 -16 0 0 0 waiting_ DL - 0:00.00 [sctp_= iterator] 0 19 0 0 -16 0 0 0 tzpoll DL - 0:00.02 [acpi_= thermal] 0 20 0 0 -16 0 0 0 - DL - 0:00.21 [rand_= harvestq] 0 21 0 0 -16 0 0 0 idle DL - 0:00.00 [enc_d= aemon0] 0 22 0 0 20 0 0 0 geli:w DL - 0:00.33 [g_eli= [0] ada0p3] 0 23 0 0 20 0 0 0 geli:w DL - 0:00.32 [g_eli= [1] ada0p3] 0 24 0 0 20 0 0 0 geli:w DL - 0:00.30 [g_eli= [2] ada0p3] 0 25 0 0 20 0 0 0 geli:w DL - 0:00.29 [g_eli= [3] ada0p3] 0 1886 49233 0 52 0 15480 4980 kqread D - 0:02.14 [hald-= addon-mouse-s] 0 2325 1 0 20 0 1062904 3360 select Ds - 0:00.00 [syslo= gd] 0 2393 63922 0 52 0 1063108 3352 kqread D+ - 0:00.00 [jail] 0 4880 0 0 -16 0 0 0 psleep DL - 0:00.02 [paged= aemon] 0 4936 1 0 52 0 1075884 7952 select Ds - 0:00.00 [sshd] 0 7228 0 0 -16 0 0 0 pftm DL - 0:00.80 [pf pu= rge] 1001 8122 77405 0 20 0 71228 26272 select Ds+ - 0:00.64 [pytho= n2.7] 0 8562 1 0 52 0 1069968 3820 wait Ds+ - 0:00.04 [sh] 970 9162 1 0 43 0 31288 13432 select D - 0:00.13 [color= d] 0 9173 0 0 -16 0 0 0 vlruwt DL - 0:00.00 [vnlru] 0 12983 49233 0 20 0 12188 3452 select D - 0:02.17 [hald-= addon-storage] 0 15057 1 0 20 0 1069048 3376 select Ds - 0:00.00 [syslo= gd] 0 17941 1 0 52 0 1063240 3424 select Ds - 0:00.00 [dhcli= ent] 560 21902 1 0 20 0 22696 9816 select Ds - 0:00.21 [hald] 0 24466 1 0 20 0 1064092 4044 pause D - 0:00.04 [zsh] 0 27080 0 0 20 0 0 0 geli:w DL - 0:00.00 [g_eli= [3] ada0p2] 0 28077 1 0 20 0 1062908 3224 nanslp Ds - 0:00.00 [cron] 136 28282 1 0 20 0 1075596 8200 select Ds - 0:00.00 [dhcpd] 65 28545 1 0 20 0 1063488 3552 select DCs - 0:00.00 [dhcli= ent] 0 30912 1 0 52 0 1062960 3316 select Ds - 0:00.00 [dhcli= ent] 0 33269 1 0 52 0 1062416 2916 select Ds - 0:00.00 [mouse= d] 0 33395 1 0 52 0 1075864 8060 select Ds - 0:00.00 [sshd] 25 34691 1 0 21 0 15820 6376 pause Ds - 0:00.00 [sendm= ail] 0 37813 0 0 20 0 0 0 geli:w DL - 0:00.00 [g_eli= [0] ada0p2] 59 39378 1 0 52 0 27804 11980 kqread Ds - 0:00.01 [unbou= nd] 0 42696 8562 0 52 0 1070268 3892 wait D+ - 0:00.00 [sh] 0 42723 1 0 20 0 1069052 3368 select Ds - 0:00.04 [syslo= gd] 0 44349 1 0 20 0 1062896 3232 nanslp Ds - 0:00.01 [cron] 0 45591 0 0 -16 0 0 0 psleep DL - 0:00.00 [vmdae= mon] 0 46609 1 0 21 0 1068836 3080 select Ds - 0:00.00 [ping] 0 49233 21902 0 52 0 19824 6920 select D - 0:02.18 [hald-= runner] 25 50148 1 0 52 0 15492 6028 pause Ds - 0:00.00 [sendm= ail] 0 52193 8562 0 34 0 1069856 3752 wait D+ - 0:00.00 [sh] 0 52369 1 0 20 0 1074184 7240 select Ds - 0:00.02 [openv= pn] 0 52996 1 0 52 0 1069720 8076 select Ds - 0:00.00 [sshd] 0 54664 1 0 20 0 1062956 3420 select Ds - 0:00.00 [syslo= gd] 0 56075 1 0 20 0 1062908 3232 nanslp Ds - 0:00.00 [cron] 0 58237 1 0 20 0 1062908 3228 nanslp Ds - 0:00.00 [cron] 0 59787 1 0 20 0 16216 6464 select Ds - 0:00.01 [sendm= ail] 0 61940 1 0 20 0 152336 8672 kqread Ds - 0:00.03 [cupsd] 0 62337 1 0 20 0 1062908 3228 nanslp Ds - 0:00.00 [cron] 0 63922 42696 0 52 0 1070268 3892 wait D+ - 0:00.00 [sh] 0 64471 1 0 52 0 1075864 8080 select Ds - 0:00.00 [sshd] 0 64483 1 0 52 0 1062380 2864 pause Ds - 0:00.00 [adjke= rntz] 0 67573 1 0 52 0 1075460 7784 select Ds - 0:00.00 [sshd] 0 70948 1 0 20 0 10668 1548 select Ds - 0:00.01 [devd] 0 71150 0 0 -16 0 0 0 qsleep DL - 0:00.01 [bufda= emon] 0 73197 1 0 20 0 1062956 3420 select Ds - 0:00.00 [syslo= gd] 0 74083 1 0 20 0 51712 8304 select D - 0:00.02 [conso= le-kit-daemon] 0 74375 1 0 52 0 1069720 8080 select Ds - 0:00.00 [sshd] 0 76410 1 0 20 0 1062908 3224 nanslp Ds - 0:00.00 [cron] 0 77161 0 0 20 0 0 0 geli:w DL - 0:00.00 [g_eli= [1] ada0p2] 1001 77405 1 0 20 0 1067112 7012 select Ds - 0:00.01 [tmux] 0 79483 49233 0 20 0 15840 5328 select D - 0:02.23 [hald-= addon-mouse-s] 0 82183 0 0 20 0 0 0 geli:w DL - 0:00.00 [g_eli= [2] ada0p2] 0 85036 1 0 20 0 16212 6552 select Ds - 0:00.01 [sendm= ail] 0 85171 1 0 20 0 1062908 3224 nanslp Ds - 0:00.00 [cron] 0 86699 1 0 20 0 15780 6304 select Ds - 0:00.00 [sendm= ail] 284 86810 1 0 20 0 1062832 3080 nanslp Ds - 0:02.16 [vnsta= td] 0 88272 0 0 16 0 0 0 syncer DL - 0:00.03 [synce= r] 0 88728 2393 0 52 0 1062260 2800 tx->tx_s D+ - 0:00.00 [umoun= t] 25 88932 1 0 52 0 15952 6156 pause Ds - 0:00.00 [sendm= ail] 0 93248 24466 0 21 0 1068860 3100 select DC - 0:00.01 [ping] 0 94651 1 0 20 0 1062956 3420 select Ds - 0:00.00 [syslo= gd] 0 96116 1 0 20 0 1062956 3416 select Ds - 0:00.00 [syslo= gd] 0 98208 1 0 20 0 1068564 2924 select Ds - 0:00.07 [power= d] 556 98685 1 0 20 0 13060 3888 select Ds - 0:00.01 [dbus-= daemon] 0 98909 52193 0 33 0 1062252 2800 nanslp DC+ - 0:00.00 [sleep] ------------------------------------------------------------------------ vmstat -s 1540659 cpu context switches 115226 device interrupts 7218 software interrupts 1672384 traps 89169090 system calls 35 kernel threads created 5340 fork() calls 1584 vfork() calls 76 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 14361 vnode pager pageins 164114 vnode pager pages paged in 161 vnode pager pageouts 5082 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 0 clean page reclamation shortfalls 0 pages reactivated by the page daemon 566422 copy-on-write faults 684 copy-on-write optimized faults 727765 zero fill pages zeroed 0 zero fill pages prezeroed 369 intransit blocking page faults 1407014 total VM faults taken 13542 page faults requiring I/O 0 pages affected by kernel thread creation 3326198 pages affected by fork() 1071137 pages affected by vfork() 49038 pages affected by rfork() 1763074 pages freed 0 pages freed by daemon 0 pages freed by exiting processes 0 pages active 0 pages inactive 0 pages in the laundry queue 0 pages wired down 0 pages free 0 bytes per page 0 total name lookups cache hits (0% pos + 0% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM I/O Scheduler 2 1K - 2 128 CAM queue 14 5K - 34 16,32,512 USB 77 139K - 87 16,32,64,128,256,512,1024,2048= ,4096,8192,16384 USBdev 90 29K - 341 32,64,128,256,512,1024,4096 CAM dev queue 6 1K - 6 64 vtbuf 24 1968K - 46 4096 vt 11 6K - 11 512 scsi_da 0 0K - 70 32,256 DEVFS2 166 11K - 190 32,64 DEVFS3 1546 387K - 1548 256 DEVFS1 166 83K - 207 512 DEVFS_RULE 65 30K - 70 64,512 DEVFS 162 4K - 163 16,128 DEVFSP 4 1K - 256 64 NFSD V4client 1 1K - 1 256 NFSD lckfile 1 1K - 1 256 NFSD session 1 1K - 1 1024 pfs_nodes 20 5K - 20 256 eli data 250 367K - 67343 64,256,512,1024,2048,4096,8192= ,16384,32768,65536 GEOM 133 39K - 845 16,32,64,128,256,512,1024,2048= ,4096,8192,16384 raid_data 0 0K - 96 32,128,256 SCSI ENC 23 100K - 61 16,64,256,2048,32768 ddb_capture 1 64K - 1 65536 evdev 8 8K - 8 1024 acpiintr 1 1K - 1 64 pax_segvguard 2 34K - 2 2048,32768 acpica 16589 1664K - 395702 16,32,64,128,256,512,1024,2048= ,4096 acpitask 1 64K - 1 65536 kbdmux 9 22K - 9 16,512,1024,2048,16384 LED 12 1K - 12 16,128 isadev 7 1K - 7 128 cdev 5 2K - 5 256 filedesc 12 48K - 45 16,4096,8192 sigio 0 0K - 1 64 filecaps 4 1K - 590 16,32,64 kdtrace 568 125K - 14551 64,256 kenv 125 13K - 128 16,32,64,128,8192 kqueue 112 22K - 7064 64,256,512,2048 proc-args 88 5K - 3959 16,32,64,128,256 hhook 91 23K - 104 256 ithread 227 46K - 228 32,128,256 prison 16 25K - 17 16,32,4096 KTRACE 100 13K - 100 128 linker 424 510K - 516 16,32,64,128,256,512,1024,2048= ,4096,8192,16384,32768,65536 lockf 133 15K - 1380 64,128 loginclass 2 1K - 2 64 cache 1 1K - 1 32 devbuf 26705 49695K - 26963 16,32,64,128,256,512,1024,2048= ,4096,8192,32768,65536 temp 203 39K - 24526 16,32,64,128,256,512,1024,2048= ,4096,8192,16384,65536 module 526 66K - 527 128 mtx_pool 2 16K - 2 8192 osd 7 1K - 45 16,32,64,128,256 pmchooks 1 1K - 1 128 pmc 1 1K - 1 64 pgrp 46 6K - 195 128 session 46 6K - 113 128 proc 2 256K - 2 =20 subproc 239 449K - 7181 512,4096 cred 97 25K - 976 256 acpisem 123 16K - 123 128 plimit 41 11K - 1034 256 uidinfo 11 34K - 110 128,32768 dumper 1 1K - 1 512 sysctl 0 0K - 18 64 sysctloid 6314 323K - 6446 16,32,64,128,256 sysctltmp 0 0K - 2576 16,32,256,1024 acpidev 112 7K - 112 64 tidhash 1 256K - 1 =20 callout 5 2184K - 5 =20 umtx 1116 140K - 1116 128 p1003.1b 1 1K - 1 16 SWAP 1 2188K - 1 =20 bus 1393 130K - 24465 16,32,64,128,256,512,1024,4096 bus-sc 94 2324K - 5697 16,32,64,128,256,512,1024,2048= ,4096,8192,16384,32768,65536 CAM SIM 6 2K - 6 256 devstat 8 17K - 8 32,4096 epoch 4 1K - 4 128 eventhandler 157 13K - 157 64,128 gtaskqueue 34 35K - 34 16,32,256,8192 kobj 356 1424K - 536 4096 Per-cpu 1 1K - 1 32 rman 260 30K - 717 32,128 sbuf 0 0K - 1969 16,32,64,128,256,512,1024,2048= ,4096,8192,16384,32768 toponodes 18 3K - 18 128 taskqueue 150 18K - 165 16,32,64,128,256 terminal 11 3K - 11 256 Unitno 70 5K - 2034 32,64 vmem 2 528K - 7 2048,4096,8192,16384 ioctlops 0 0K - 1668 256,512,1024,2048,4096 select 112 14K - 112 128 iov 0 0K - 130249 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096,8192,16384 sem 4 106K - 4 2048,4096 shm 1 32K - 1 32768 tty 13 13K - 13 1024 pts 1 1K - 1 256 mbuf_tag 0 0K - 131 32 shmfd 1 8K - 1 8192 soname 32 3K - 20189 16,32,64,128 pcb 152 87097K - 351 16,32,64,128,1024,2048,8192 acl 0 0K - 5 4096 vfscache 4 16433K - 4 256,16384,32768 vfs_hash 1 8192K - 1 =20 vnodes 1 1K - 1 256 mount 515 19K - 1438 16,32,64,128,256,1024 statfs 0 0K - 24620 4096 nvd 2 1K - 2 32,256 vnodemarker 0 0K - 339 512 chacha20random 1 1K - 1 1024 BPF 46 31K - 48 128,512,4096 ifnet 40 67K - 45 128,256,2048 ifaddr 374 113K - 432 16,32,64,128,256,512,2048,4096 ether_multi 279 22K - 301 16,32,64,128 clone 47 6K - 53 128 ipsec 7 2K - 8 256 lltable 152 43K - 193 256,512 tun 1 1K - 1 256 iflib 14 82K - 18 16,64,128,1024,4096,8192,16384= ,32768 routetbl 235 40K - 323 32,64,128,256,512 vnet 7 1K - 8 64 vnet_data 7 1512K - 8 =20 vnet_data_free 1 1K - 1 32 80211node 0 0K - 15 16 80211scan 1 16K - 1 16384 igmp 33 5K - 43 128 ipid 14 168K - 16 8192,16384 in_multi 17 5K - 20 256 encap_export_host 8 1K - 8 64 sctp_a_it 0 0K - 32 16 sctp_vrf 7 1K - 8 64 sctp_ifa 36 5K - 40 128 sctp_ifn 21 3K - 23 128 sctp_iter 0 0K - 32 256 hostcache 7 224K - 8 32768 LRO 2 40K - 2 8192,32768 tcpfunc 1 1K - 1 64 syncache 7 476K - 8 =20 in6_multi 175 21K - 190 32,256 ip6opt 1 1K - 27 256 mld 34 5K - 43 128 ip6ndp 48 6K - 65 64,256 inpcbpolicy 49 2K - 900 32 secasvar 7 7K - 8 1024 sahead 7 7K - 8 1024 ipsecpolicy 14 9K - 16 256,1024 ipsec-saq 14 14K - 16 1024 crypto 10 10K - 132 128,512,1024 xform 0 0K - 507 16,32,128 rpc 2 8K - 2 4096 audit_evclass 230 8K - 285 32 ufs_quota 1 8192K - 1 =20 vm_pgdata 1 1K - 1 128 UMAHash 31 1290K - 98 512,1024,2048,4096,8192,16384,= 32768,65536 nvme 530 73K - 530 128,1024,2048 fpukern_ctx 4 8K - 4 2048 memdesc 1 4K - 1 4096 aesni_data 2 1K - 2 32,256 pci_link 16 2K - 16 64,128 atkbddev 2 1K - 2 64 cpuctl 2 101K - 5 32 CAM XPT 38 3K - 135 16,32,64,128,256,512,1024,2048= ,65536 entropy 1 1K - 199 32,4096 CAM DEV 8 16K - 14 2048 CAM CCB 0 0K - 70135 2048 CAM path 11 1K - 57 32 CAM periph 8 2K - 27 16,32,64,128,256 apmdev 1 1K - 1 128 madt_table 0 0K - 2 64,4096 acpi_perf 4 2K - 4 512 hdaa 9 45K - 9 1024,2048,4096,16384 hdac 2 3K - 2 1024,2048 hdacc 2 1K - 2 32 io_apic 1 16K - 1 16384 local_apic 1 8K - 1 8192 MCA 15 3K - 15 32,128,256 cpus 2 1K - 2 32 msi 20 3K - 20 128 nexusdev 6 1K - 6 16 feeder 25 3K - 33 32,128 mixer 6 24K - 6 4096 tap 10 3K - 10 256 solaris 386954 297538K - 5069539 16,32,64,128,256,512,1024,20= 48,4096,8192,16384,32768 kstat_data 8 1K - 8 64 sfs_nodes 64 32K - 64 512 acpivideo 2 1K - 2 128 fdesc_mount 1 1K - 1 16 pf_hash 21 80640K - 24 =20 pf_ifnet 80 32K - 166 128,256,2048 pf_osfp 1191 123K - 1191 64,128 pf_rule 15 11K - 15 128,1024 pf_table 9 18K - 17 2048 epair 12 2K - 14 128 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 435, 41, 465, 0, 0 UMA Zones: 904, 0, 437, 31, 467, 0, 0 UMA Slabs: 112, 0, 292360, 30, 294363, 0, 0 UMA Hash: 256, 0, 79, 26, 111, 0, 0 4 Bucket: 32, 0, 1420, 1184, 42294, 0, 0 6 Bucket: 48, 0, 677, 1149, 5188, 0, 0 8 Bucket: 64, 0, 276, 1274, 17532, 17, 0 12 Bucket: 96, 0, 154, 748, 6786, 0, 0 16 Bucket: 128, 0, 447, 452, 17944, 1, 0 32 Bucket: 256, 0, 2045, 280, 41355, 160, 0 64 Bucket: 512, 0, 555, 96, 13810, 526, 0 128 Bucket: 1024, 0, 321, 183, 5810, 1, 0 256 Bucket: 2048, 0, 923, 29, 6016, 53, 0 vmem: 1792, 0, 3, 1, 3, 0, 0 vmem btag: 56, 0, 40047, 636, 40047, 287, 0 VM OBJECT: 256, 0, 18381, 534, 184460, 0, 0 RADIX NODE: 144, 0, 46102, 1229, 357241, 0, 0 MAP: 232, 0, 3, 65, 3, 0, 0 KMAP ENTRY: 120, 0, 17, 379, 17, 0, 0 MAP ENTRY: 120, 0, 4001, 2005, 596038, 0, 0 VMSPACE: 2552, 0, 59, 34, 7001, 0, 0 fakepg: 104, 0, 0, 152, 18, 0, 0 64 pcpu: 8, 0, 19515, 3269, 22462, 0, 0 mt_zone: 16400, 0, 454, 0, 454, 0, 0 16: 16, 0, 22309, 599, 457870, 0, 0 32: 32, 0, 40832, 25632, 502922, 0, 0 64: 64, 0, 212208, 118376, 1076218, 0, 0 128: 128, 0, 22153, 6553, 534943, 0, 0 256: 256, 0, 119029, 24521, 681130, 0, 0 512: 512, 0, 7616, 5971, 887738, 0, 0 1024: 1024, 0, 1587, 2321, 69651, 0, 0 2048: 2048, 0, 476, 70, 1569821, 0, 0 4096: 4096, 0, 13882, 17, 110896, 0, 0 8192: 8192, 0, 92, 12, 10239, 0, 0 16384: 16384, 0, 31, 24, 9761, 0, 0 32768: 32768, 0, 30, 11, 2569, 0, 0 65536: 65536, 0, 15, 8, 2235, 0, 0 SLEEPQUEUE: 88, 0, 559, 216, 559, 0, 0 Files: 80, 0, 445, 584, 139370, 0, 0 filedesc0: 1104, 0, 94, 68, 7036, 0, 0 rl_entry: 40, 0, 122, 967, 122, 0, 0 TURNSTILE: 136, 0, 559, 121, 559, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 umtx_shm: 88, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1368, 0, 93, 51, 7035, 0, 0 THREAD: 1392, 0, 524, 34, 623, 0, 0 cpuset: 104, 0, 21, 537, 38, 0, 0 domainset: 40, 0, 0, 806, 16, 0, 0 audit_record: 1280, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 26079300, 0, 759, 1173, 0, 0 mbuf: 256, 26079300, 1323, 1713, 89087, 0, 0 mbuf_cluster: 2048, 4074888, 1782, 38, 55804, 0, 0 mbuf_jumbo_page: 4096, 2037444, 256, 4, 263, 0, 0 mbuf_jumbo_9k: 9216, 1811061, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 1358296, 0, 0, 0, 0, 0 epoch_record pcpu: 256, 0, 4, 60, 4, 0, 0 g_bio: 384, 0, 5, 535, 306050, 0, 0 DMAR_MAP_ENTRY: 120, 0, 0, 0, 0, 0, 0 FPU_save_area: 1088, 0, 0, 0, 0, 0, 0 ttyinq: 160, 0, 30, 234, 450, 0, 0 ttyoutq: 256, 0, 16, 239, 240, 0, 0 nvme_request: 128, 0, 4, 399, 52, 0, 0 cryptop: 128, 0, 0, 0, 0, 0, 0 cryptodesc: 120, 0, 0, 0, 0, 0, 0 crypto_session: 24, 0, 8, 1154, 129, 0, 0 vtnet_tx_hdr: 24, 0, 0, 0, 0, 0, 0 taskq_zone: 48, 0, 0, 1079, 3129, 0, 0 VNODE: 480, 0, 193734, 74, 197506, 0, 0 VNODEPOLL: 120, 0, 37, 491, 37, 0, 0 BUF TRIE: 144, 0, 0, 105948, 0, 0, 0 S VFS Cache: 108, 0, 168711, 9929, 206627, 0, 0 STS VFS Cache: 148, 0, 0, 0, 0, 0, 0 L VFS Cache: 328, 0, 5100, 876, 10702, 0, 0 LTS VFS Cache: 368, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 68, 601315, 0, 0 rentr: 24, 0, 0, 0, 0, 0, 0 NCLNODE: 592, 0, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 0, 0, 0, 0, 0 Mountpoints: 2744, 0, 41, 4, 41, 0, 0 reference_cache: 40, 0, 98, 1684, 49810, 0, 0 reference_history_cache: 8, 0, 24, 1221, 49736, 0, 0 range_seg_cache: 72, 0, 147797, 8018, 208384, 0, 0 metaslab_alloc_trace_cache: 72, 0, 142, 903, 25498, 0,= 0 zio_cache: 1048, 0, 120, 3669, 714577, 0, 0 zio_link_cache: 48, 0, 143, 4422, 424955, 0, 0 zio_buf_512: 512, 0, 194650, 19893, 593187, 0, 0 zio_data_buf_512: 512, 0, 169, 1371, 8659, 0, 0 zio_buf_1024: 1024, 0, 1288, 768, 3814, 0, 0 zio_data_buf_1024: 1024, 0, 119, 937, 1205, 0, 0 zio_buf_1536: 1536, 0, 583, 173, 1088, 0, 0 zio_data_buf_1536: 1536, 0, 56, 322, 450, 0, 0 zio_buf_2048: 2048, 0, 376, 50, 1714, 0, 0 zio_data_buf_2048: 2048, 0, 64, 282, 429, 0, 0 zio_buf_2560: 2560, 0, 185, 31, 335, 0, 0 zio_data_buf_2560: 2560, 0, 61, 137, 264, 0, 0 zio_buf_3072: 3072, 0, 135, 21, 219, 0, 0 zio_data_buf_3072: 3072, 0, 41, 112, 208, 0, 0 zio_buf_3584: 3584, 0, 100, 13, 179, 0, 0 zio_data_buf_3584: 3584, 0, 59, 30, 147, 0, 0 zio_buf_4096: 4096, 0, 102, 459, 65706, 0, 0 zio_data_buf_4096: 4096, 0, 24, 438, 4801, 0, 0 zio_buf_5120: 5120, 0, 116, 19, 246, 0, 0 zio_data_buf_5120: 5120, 0, 65, 47, 190, 0, 0 zio_buf_6144: 6144, 0, 77, 10, 181, 0, 0 zio_data_buf_6144: 6144, 0, 43, 17, 103, 0, 0 zio_buf_7168: 7168, 0, 62, 10, 109, 0, 0 zio_data_buf_7168: 7168, 0, 24, 22, 85, 0, 0 zio_buf_8192: 8192, 0, 34, 14, 4364, 0, 0 zio_data_buf_8192: 8192, 0, 24, 16, 112, 0, 0 zio_buf_10240: 10240, 0, 44, 8, 116, 0, 0 zio_data_buf_10240: 10240, 0, 36, 34, 126, 0, 0 zio_buf_12288: 12288, 0, 24, 9, 1778, 0, 0 zio_data_buf_12288: 12288, 0, 30, 30, 111, 0, 0 zio_buf_14336: 14336, 0, 19, 9, 88, 0, 0 zio_data_buf_14336: 14336, 0, 29, 27, 98, 0, 0 zio_buf_16384: 16384, 0, 14539, 949, 25410, 0, 0 zio_data_buf_16384: 16384, 0, 19, 51, 174, 0, 0 zio_buf_20480: 20480, 0, 26, 12, 789, 0, 0 zio_data_buf_20480: 20480, 0, 32, 40, 133, 0, 0 zio_buf_24576: 24576, 0, 7, 9, 597, 0, 0 zio_data_buf_24576: 24576, 0, 15, 69, 125, 0, 0 zio_buf_28672: 28672, 0, 6, 5, 430, 0, 0 zio_data_buf_28672: 28672, 0, 8, 36, 78, 0, 0 zio_buf_32768: 32768, 0, 3, 13, 426, 0, 0 zio_data_buf_32768: 32768, 0, 21, 29, 145, 0, 0 zio_buf_40960: 40960, 0, 7, 10, 623, 0, 0 zio_data_buf_40960: 40960, 0, 31, 33, 152, 0, 0 zio_buf_49152: 49152, 0, 7, 12, 606, 0, 0 zio_data_buf_49152: 49152, 0, 10, 38, 105, 0, 0 zio_buf_57344: 57344, 0, 3, 9, 603, 0, 0 zio_data_buf_57344: 57344, 0, 10, 25, 70, 0, 0 zio_buf_65536: 65536, 0, 1, 8, 952, 0, 0 zio_data_buf_65536: 65536, 0, 3, 28, 117, 0, 0 zio_buf_81920: 81920, 0, 4, 10, 2092, 0, 0 zio_data_buf_81920: 81920, 0, 3, 33, 106, 0, 0 zio_buf_98304: 98304, 0, 2, 8, 1768, 0, 0 zio_data_buf_98304: 98304, 0, 4, 57, 130, 0, 0 zio_buf_114688: 114688, 0, 0, 10, 301, 0, 0 zio_data_buf_114688: 114688, 0, 12, 197, 260, 0, 0 zio_buf_131072: 131072, 0, 1271, 402, 8746, 0, 0 zio_data_buf_131072: 131072, 0, 4473, 1630, 13624, 0, 0 zio_buf_163840: 163840, 0, 0, 8, 86, 0, 0 zio_data_buf_163840: 163840, 0, 0, 0, 0, 0, 0 zio_buf_196608: 196608, 0, 0, 7, 58, 0, 0 zio_data_buf_196608: 196608, 0, 0, 0, 0, 0, 0 zio_buf_229376: 229376, 0, 0, 6, 41, 0, 0 zio_data_buf_229376: 229376, 0, 0, 0, 0, 0, 0 zio_buf_262144: 262144, 0, 0, 7, 96, 0, 0 zio_data_buf_262144: 262144, 0, 0, 0, 0, 0, 0 zio_buf_327680: 327680, 0, 1, 6, 40, 0, 0 zio_data_buf_327680: 327680, 0, 0, 0, 0, 0, 0 zio_buf_393216: 393216, 0, 0, 5, 62, 0, 0 zio_data_buf_393216: 393216, 0, 0, 0, 0, 0, 0 zio_buf_458752: 458752, 0, 0, 5, 22, 0, 0 zio_data_buf_458752: 458752, 0, 0, 0, 0, 0, 0 zio_buf_524288: 524288, 0, 0, 6, 39, 0, 0 zio_data_buf_524288: 524288, 0, 0, 0, 0, 0, 0 zio_buf_655360: 655360, 0, 0, 6, 35, 0, 0 zio_data_buf_655360: 655360, 0, 0, 0, 0, 0, 0 zio_buf_786432: 786432, 0, 0, 5, 17, 0, 0 zio_data_buf_786432: 786432, 0, 0, 0, 0, 0, 0 zio_buf_917504: 917504, 0, 0, 5, 14, 0, 0 zio_data_buf_917504: 917504, 0, 0, 0, 0, 0, 0 zio_buf_1048576: 1048576, 0, 0, 8, 76, 0, 0 zio_data_buf_1048576: 1048576, 0, 0, 0, 0, 0, 0 zio_buf_1310720: 1310720, 0, 0, 0, 0, 0, 0 zio_data_buf_1310720: 1310720, 0, 0, 0, 0, 0, 0 zio_buf_1572864: 1572864, 0, 0, 0, 0, 0, 0 zio_data_buf_1572864: 1572864, 0, 0, 0, 0, 0, 0 zio_buf_1835008: 1835008, 0, 0, 0, 0, 0, 0 zio_data_buf_1835008: 1835008, 0, 0, 0, 0, 0, 0 zio_buf_2097152: 2097152, 0, 0, 0, 0, 0, 0 zio_data_buf_2097152: 2097152, 0, 0, 0, 0, 0, 0 zio_buf_2621440: 2621440, 0, 0, 0, 0, 0, 0 zio_data_buf_2621440: 2621440, 0, 0, 0, 0, 0, 0 zio_buf_3145728: 3145728, 0, 0, 0, 0, 0, 0 zio_data_buf_3145728: 3145728, 0, 0, 0, 0, 0, 0 zio_buf_3670016: 3670016, 0, 0, 0, 0, 0, 0 zio_data_buf_3670016: 3670016, 0, 0, 0, 0, 0, 0 zio_buf_4194304: 4194304, 0, 0, 0, 0, 0, 0 zio_data_buf_4194304: 4194304, 0, 0, 0, 0, 0, 0 zio_buf_5242880: 5242880, 0, 0, 0, 0, 0, 0 zio_data_buf_5242880: 5242880, 0, 0, 0, 0, 0, 0 zio_buf_6291456: 6291456, 0, 0, 0, 0, 0, 0 zio_data_buf_6291456: 6291456, 0, 0, 0, 0, 0, 0 zio_buf_7340032: 7340032, 0, 0, 0, 0, 0, 0 zio_data_buf_7340032: 7340032, 0, 0, 0, 0, 0, 0 zio_buf_8388608: 8388608, 0, 0, 0, 0, 0, 0 zio_data_buf_8388608: 8388608, 0, 0, 0, 0, 0, 0 zio_buf_10485760: 10485760, 0, 0, 0, 0, 0, 0 zio_data_buf_10485760: 10485760, 0, 0, 0, 0, 0, 0 zio_buf_12582912: 12582912, 0, 0, 0, 0, 0, 0 zio_data_buf_12582912: 12582912, 0, 0, 0, 0, 0, 0 zio_buf_14680064: 14680064, 0, 0, 0, 0, 0, 0 zio_data_buf_14680064: 14680064, 0, 0, 0, 0, 0, 0 zio_buf_16777216: 16777216, 0, 0, 0, 0, 0, 0 zio_data_buf_16777216: 16777216, 0, 0, 0, 0, 0, 0 lz4_ctx: 16384, 0, 0, 7, 19920, 0, 0 abd_chunk: 4096, 0, 237217, 11099, 781349, 0, 0 sa_cache: 152, 0, 193557, 143, 197322, 0, 0 dnode_t: 952, 0, 197869, 19, 200089, 0, 0 arc_buf_hdr_t_full: 376, 0, 61683, 87, 164561, 0, 0 arc_buf_hdr_t_l2only: 96, 0, 0, 0, 0, 0, 0 arc_buf_t: 64, 0, 25184, 25222, 161130, 0, 0 dmu_buf_impl_t: 352, 0, 219046, 24505, 360599, 0, 0 zil_lwb_cache: 320, 0, 7, 173, 214, 0, 0 zil_zcw_cache: 80, 0, 1, 391, 156, 0, 0 sio_cache: 128, 0, 0, 0, 0, 0, 0 zfs_znode_cache: 272, 0, 193557, 77, 197321, 0, 0 AIO: 208, 0, 0, 0, 0, 0, 0 AIOP: 32, 0, 0, 0, 0, 0, 0 AIOCB: 752, 0, 0, 0, 0, 0, 0 AIOLIO: 280, 0, 0, 0, 0, 0, 0 pipe: 760, 0, 59, 71, 3388, 0, 0 procdesc: 136, 0, 2, 259, 76, 0, 0 ksiginfo: 112, 0, 127, 923, 382, 0, 0 itimer: 352, 0, 0, 0, 0, 0, 0 KNOTE: 160, 0, 58, 206, 266, 0, 0 socket: 872, 2091208, 118, 66, 4666, 0, 0 unpcb: 256, 2091210, 68, 187, 3705, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 7, 113, 554, 0, 0 udpcb: 32, 2091260, 7, 1109, 554, 0, 0 tcp_inpcb: 488, 2091208, 11, 77, 14, 0, 0 tcpcb: 976, 2091208, 11, 29, 14, 0, 0 tcptw: 88, 27810, 0, 135, 1, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 1, 163, 1, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 tcpreass: 48, 254727, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 1079, 11, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 4, 84, 76, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 32, 215, 35, 0, 0 selfd: 64, 0, 195, 859, 29481, 0, 0 swpctrie: 144, 8149788, 0, 0, 0, 0, 0 swblk: 136, 8149783, 0, 0, 0, 0, 0 bridge_rtnode: 64, 0, 6, 1048, 7, 0, 0 pf mtags: 48, 0, 0, 0, 0, 0, 0 pf states: 296, 100009, 14, 168, 171, 0, 0 pf state keys: 88, 0, 17, 523, 188, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 200016, 7, 137, 7, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 86, 28, 0, 0 udpcb: 32, 2091260, 2, 866, 28, 0, 0 tcp_inpcb: 488, 2091208, 2, 30, 2, 0, 0 tcpcb: 976, 2091208, 2, 14, 2, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 11, 236, 13, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 118, 28, 0, 0 udpcb: 32, 2091260, 2, 1114, 28, 0, 0 tcp_inpcb: 488, 2091208, 2, 30, 2, 0, 0 tcpcb: 976, 2091208, 2, 14, 2, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 11, 236, 13, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 118, 37, 0, 0 udpcb: 32, 2091260, 2, 1114, 37, 0, 0 tcp_inpcb: 488, 2091208, 5, 83, 6, 0, 0 tcpcb: 976, 2091208, 5, 35, 6, 0, 0 tcptw: 88, 27810, 0, 135, 1, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 1, 163, 1, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 11, 236, 13, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 118, 39, 0, 0 udpcb: 32, 2091260, 2, 1114, 39, 0, 0 tcp_inpcb: 488, 2091208, 3, 61, 5, 0, 0 tcpcb: 976, 2091208, 3, 25, 5, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 11, 236, 13, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 86, 28, 0, 0 udpcb: 32, 2091260, 2, 866, 28, 0, 0 tcp_inpcb: 488, 2091208, 2, 30, 2, 0, 0 tcpcb: 976, 2091208, 2, 14, 2, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 11, 179, 13, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ipq: 56, 51262, 0, 0, 0, 0, 0 udp_inpcb: 488, 2091208, 2, 118, 46, 0, 0 udpcb: 32, 2091260, 2, 1114, 46, 0, 0 tcp_inpcb: 488, 2091208, 1, 87, 3, 0, 0 tcpcb: 976, 2091208, 1, 39, 3, 0, 0 tcptw: 88, 27810, 0, 0, 0, 0, 0 syncache: 168, 15364, 0, 0, 0, 0, 0 hostcache: 96, 15375, 0, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1280, 2091210, 0, 0, 0, 0, 0 sctp_asoc: 2408, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80012, 0, 581, 3, 0, 0 sctp_raddr: 736, 80000, 0, 0, 0, 0, 0 sctp_chunk: 152, 400010, 0, 0, 0, 0, 0 sctp_readq: 152, 400010, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400015, 0, 0, 0, 0, 0 sctp_asconf: 40, 400059, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400060, 0, 0, 0, 0, 0 udplite_inpcb: 488, 2091208, 0, 0, 0, 0, 0 ripcb: 488, 2091208, 0, 0, 0, 0, 0 IPsec SA lft_c: 16, 0, 0, 0, 0, 0, 0 rtentry: 208, 0, 10, 237, 12, 0, 0 pf states: 296, 100009, 0, 0, 0, 0, 0 pf state keys: 88, 0, 0, 0, 0, 0, 0 pf source nodes: 136, 10005, 0, 0, 0, 0, 0 pf table entries: 160, 0, 0, 0, 0, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 5049, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 10 0 irq9: acpi0 196 1 cpu0:timer 68174 485 cpu2:timer 65213 464 cpu1:timer 58390 415 cpu3:timer 62032 441 irq264: hdac0 3 0 irq265: xhci0 5190 37 irq266: ahci0 69388 494 irq268: nvme0 14 0 irq270: nvme0 2 0 irq271: nvme0 1 0 irq272: nvme0 31 0 irq273: hdac1 43 0 irq274: em0:irq0 40320 287 irq275: iwm0 28 0 Total 369035 2625 ------------------------------------------------------------------------ pstat -T 445/2091208 files 0M/0M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity ------------------------------------------------------------------------ iostat tty nvd0 ada0 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 1464 17.66 0 0.00 18.28 311 5.56 1.83 1 0.00 8 0 9 0 84 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP = CBYTES QNUM QBYTES LSPI= D LRPID STIME RTIME CTIME =20 Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NATTCH SEGSZ CPID LPID ATIME DTIME CTIM= E =20 Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP = NSEMS OTIME CTIME =20 ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 536870912 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 131072 (max amount of shared memory in pages) seminfo: semmni: 50 (# of semaphore identifiers) semmns: 340 (# of semaphores in system) semmnu: 150 (# of undo structures in system) semmsl: 340 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 50 (max # of undo entries per process) semusz: 632 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Rpc Counts: Getattr Setattr Lookup Readlink Read Wr= ite Create Remove 0 0 0 0 0 = 0 0 0 Rename Link Symlink Mkdir Rmdir Read= dir RdirPlus Access 0 0 0 0 0 = 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Attr Misses Lkup Hits Lkup Misses BioR Hits BioR Mis= ses BioW Hits BioW Misses 0 0 0 0 0 = 0 0 0 BioRL Hits BioRL Misses BioD Hits BioD Misses DirE Hits DirE Mis= ses Accs Hits Accs Misses 0 0 0 0 0 = 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Wr= ite Create Remove 0 0 0 0 0 = 0 0 0 Rename Link Symlink Mkdir Rmdir Read= dir RdirPlus Access 0 0 0 0 0 = 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Re-Failed: 128914559182368 Server Faults: 128914559182368 Server Write=20 WriteOps WriteRPC Opsaved 0 0 0 Server Cache=20 Inprog Idem Non-Idem Misses 0 0 0 0 ------------------------------------------------------------------------ netstat -s tcp: 27726 packets sent 102 data packets (13825 bytes) 7 data packets (217 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 27612 ack-only packets (32 delayed) 0 URG only packets 0 window probe packets 0 window update packets 5 control packets 55281 packets received 98 acks (for 13795 bytes) 0 duplicate acks 0 acks for unsent data 55223 packets (67718430 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 0 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 3 connection requests 0 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 3 connections established (including accepts) 0 times used RTT from hostcache 0 times used RTT variance from hostcache 0 times used slow-start threshold from hostcache 3 connections closed (including 0 drops) 1 connection updated cached RTT on close 1 connection updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 98 segments updated rtt (of 98 attempts) 7 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 47 correct ACK header predictions 55178 correct data packet header predictions 0 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 0 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 1 hostcache entry added 0 bucket overflow 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window 0 packets with matching signature received 0 packets with bad signature received 0 times failed to make signature due to no SA 0 times unexpected signature received 0 times no signature provided by segment 0 Path MTU discovery black hole detection activations 0 Path MTU discovery black hole detection min MSS activations 0 Path MTU discovery black hole detection failures TCP connection count by state: 0 connections in CLOSED state 9 connections in LISTEN state 0 connections in SYN_SENT state 0 connections in SYN_RCVD state 1 connection in ESTABLISHED state 0 connections in CLOSE_WAIT state 0 connections in FIN_WAIT_1 state 0 connections in CLOSING state 1 connection in LAST_ACK state 0 connections in FIN_WAIT_2 state 0 connections in TIME_WAIT state udp: 87 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 9 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 78 delivered 80 datagrams output 0 times multicast source filter matched ip: 55720 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 55368 packets for this host 0 packets for unknown/unsupported protocol 349 packets forwarded (0 packets fast forwarded) 2 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 27844 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 0 calls to icmp_error 0 errors not generated in response to an icmp message 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored 0 message responses generated 0 invalid return addresses 0 no return routes ipsec: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 spd cache hits 0 spd cache misses 0 clusters copied during clone 0 mbufs inserted during makespace ah: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets dropped; bad authentication detected 0 packets dropped; bad authentication length 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures esp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 packets dropped; bad ilen 0 replay counter wraps 0 packets dropped; bad encryption detected 0 packets dropped; bad authentication detected 0 possible replay packets detected 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 tunnel sanity check failures ipcomp: 0 packets shorter than header shows 0 packets dropped; protocol family not supported 0 packets dropped; no TDB 0 packets dropped; bad KCR 0 packets dropped; queue full 0 packets dropped; no transform 0 replay counter wraps 0 packets in 0 packets out 0 packets dropped; invalid TDB 0 bytes in 0 bytes out 0 packets dropped; larger than IP_MAXPACKET 0 packets blocked due to policy 0 crypto processing failures 0 packets sent uncompressed; size < compr. algo. threshold 0 packets sent uncompressed; compression was useless arp: 4 ARP requests sent 2 ARP replies sent 20 ARP requests received 1 ARP reply received 21 ARP packets received 0 total packets dropped due to no ARP entry 0 ARP entrys timed out 0 Duplicate IPs seen ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 32 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 26 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not contiguous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation Output histogram: neighbor solicitation: 7 MLDv2 listener report: 25 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes ipsec6: 0 inbound packets violated process security policy 0 inbound packets failed due to insufficient memory 0 invalid inbound packets 0 outbound packets violated process security policy 0 outbound packets with no SA available 0 outbound packets failed due to insufficient memory 0 outbound packets with no route available 0 invalid outbound packets 0 outbound packets with bundled SAs 0 spd cache hits 0 spd cache misses 0 clusters copied during clone 0 mbufs inserted during makespace rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output pfkey: 0 requests sent from userland 0 bytes sent from userland 0 messages with invalid length field 0 messages with invalid version field 0 messages with invalid message type field 0 messages too short 0 messages with memory allocation failure 0 messages with duplicate extension 0 messages with invalid extension type 0 messages with invalid sa type 0 messages with invalid address extension 0 requests sent to userland 0 bytes sent to userland 0 messages toward single socket 0 messages toward all sockets 0 messages toward registered sockets 0 messages with memory allocation failure ------------------------------------------------------------------------ netstat -m 1323/2472/3795 mbufs in use (current/cache/total) 1023/797/1820/4074888 mbuf clusters in use (current/cache/total/max) 0/759 mbuf+clusters out of packet secondary zone in use (current/cache) 256/4/260/2037444 4k (page size) jumbo clusters in use (current/cache/total= /max) 0/0/0/1811061 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1358296 16k jumbo clusters in use (current/cache/total/max) 3400K/2228K/5628K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 sendfile syscalls 0 sendfile syscalls completed without I/O request 0 requests for I/O initiated by sendfile 0 pages read by sendfile as part of a request 0 pages were valid at time of a sendfile request 0 pages were valid and substituted to bogus page 0 pages were requested for read ahead by applications 0 pages were read ahead by sendfile 0 times sendfile encountered an already busy page 0 requests for sfbufs denied 0 requests for sfbufs delayed ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address = (state) =20 fffff800282777a0 udp4 0 0 *.514 *.* = =20 fffff80028277988 udp6 0 0 *.514 *.* = =20 Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn = Refs Nextref Addr fffff80039c8fe00 stream 0 0 0 0 = 0 0 fffff80039d6d900 stream 0 0 0 0 = 0 0 fffff80039c47200 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d6e100 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d6ec00 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039d6e000 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039d6e800 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039c47600 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039c47a00 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039c47b00 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039c90000 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c90100 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d6f000 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-G7EqLvcLpq fffff80039c1c700 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-G7EqLvcLpq fffff80039c90400 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-G7EqLvcLpq fffff80039c63400 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d6f100 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c47e00 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c1c000 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c1c100 stream 0 0 0 0 = 0 0 /var/run/hald/dbus-E605F27Aop fffff80039c1c200 stream 0 0 0 0 = 0 0 /tmp/tmux-1001/default fffff80039c91100 stream 0 0 0 0 = 0 0 /var/run/cups/cups.sock fffff80039d6f900 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d6fa00 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c91200 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c90900 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c90c00 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c90b00 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d6fc00 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d6fb00 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c1cd00 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c1ce00 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d70200 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c63e00 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039d70300 stream 0 0 0 0 = 0 0 /var/run/dbus/system_bus_socket fffff80039c1d100 stream 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c1c300 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c63500 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c1c600 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c63600 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c90500 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c90600 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d6f300 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d6f400 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039d6f500 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c63700 dgram 0 0 0 0 = 0 0 /var/run/devd.pipe fffff80039c63d00 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039d6f800 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c63800 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039c63900 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039d6f600 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039d6f700 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c63a00 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039c1cb00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c1c400 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039c63c00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c63b00 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039c90700 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c90d00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c90e00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c1cc00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c90800 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039d6fd00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c90a00 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c91000 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039d6fe00 dgram 0 0 0 0 = 0 0 /var/run/logpriv fffff80039d70000 dgram 0 0 0 0 = 0 0 /var/run/log fffff80039c1d000 seqpac 0 0 0 0 = 0 0 /var/run/devd.seqpacket.pipe ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address =20 unix 0/0/30 /var/run/hald/dbus-G7EqLvcLpq unix 0/0/30 /var/run/hald/dbus-E605F27Aop unix 0/0/128 /tmp/tmux-1001/default unix 0/0/5 /var/run/cups/cups.sock unix 0/0/30 /var/run/dbus/system_bus_socket unix 0/0/4 /var/run/devd.pipe unix 0/0/4 /var/run/devd.seqpacket.pipe ------------------------------------------------------------------------ fstat fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x200000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20000000008800d fstat: can't read file 2 at 0x4000000000000a0 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x200000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0xa00000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x400000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read file 22 at 0x780000ffff fstat: can't read file 23 at 0x1d200000001 fstat: can't read file 25 at 0x20007ffffffffff fstat: can't read file 26 at 0x4000000001fffff fstat: can't read file 28 at 0x780000ffff fstat: can't read file 29 at 0x1ba00000001 fstat: can't read file 31 at 0x20007ffffffffff fstat: can't read file 32 at 0x4000000001fffff fstat: can't read file 34 at 0x780000ffff fstat: can't read file 35 at 0x9600000001 fstat: can't read file 37 at 0x20007ffffffffff fstat: can't read file 38 at 0x4000000001fffff fstat: can't read file 40 at 0x780000ffff fstat: can't read file 41 at 0xa00000001 fstat: can't read file 43 at 0x20007ffffffffff fstat: can't read file 44 at 0x4000000001fffff fstat: can't read file 46 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x400000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read file 22 at 0x780000ffff fstat: can't read file 23 at 0x18200000001 fstat: can't read file 25 at 0x20007ffffffffff fstat: can't read file 26 at 0x4000000001fffff fstat: can't read file 28 at 0x780000ffff fstat: can't read file 29 at 0x1b200000001 fstat: can't read file 35 at 0x11400000000 fstat: can't read file 41 at 0x400000000 fstat: can't read file 43 at 0x20007ffffffffff fstat: can't read file 44 at 0x4000000001fffff fstat: can't read file 46 at 0x780000ffff fstat: can't read file 47 at 0xa00000000 fstat: can't read file 49 at 0x20007ffffffffff fstat: can't read file 50 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0xa00000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read file 22 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x600000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x600000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read file 22 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x200000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x600000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x400000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read file 11 at 0x400000000 fstat: can't read file 13 at 0x20007ffffffffff fstat: can't read file 14 at 0x4000000001fffff fstat: can't read file 16 at 0x780000ffff fstat: can't read file 17 at 0x400000000 fstat: can't read file 19 at 0x20007ffffffffff fstat: can't read file 20 at 0x4000000001fffff fstat: can't read file 22 at 0x780000ffff fstat: can't read file 23 at 0x4600000001 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x200000000000000 fstat: can't read file 2 at 0x400000000000000 fstat: can't read file 5 at 0x800000000 fstat: can't read file 7 at 0x200000000000002 fstat: can't read file 8 at 0x400000000000000 fstat: can't read file 11 at 0x400000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read file 7 at 0x20007ffffffffff fstat: can't read file 8 at 0x4000000001fffff fstat: can't read file 10 at 0x780000ffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read file 4 at 0x780000ffff fstat: can't read file 5 at 0x800000000 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read file 1 at 0x20007ffffffffff fstat: can't read file 2 at 0x4000000001fffff fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 fstat: can't read znode_phys at 0x1 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root umount 88728 root - - error - root umount 88728 wd - - error - root umount 88728 text - - error - root umount 88728 ctty /dev 10 crw------- console rw root umount 88728 0* pipe fffff8063f07c000 <-> fffff8063f07c168 = 64 rw root jail 2393 root - - error - root jail 2393 wd - - error - root jail 2393 text - - error - root jail 2393 ctty /dev 10 crw------- console rw root jail 2393 0* pipe fffff8063f07c000 <-> fffff8063f07c168 = 64 rw root jail 2393 6 - - error - root sh 63922 root - - error - root sh 63922 wd - - error - root sh 63922 text - - error - root sh 63922 ctty /dev 10 crw------- console rw root sh 63922 0* pipe fffff8063f07c000 <-> fffff8063f07c168 = 64 rw root sh 42696 root - - error - root sh 42696 wd - - error - root sh 42696 text - - error - root sh 42696 ctty /dev 10 crw------- console rw root sh 42696 0 /dev 10 crw------- console rw root sh 42696 6 /dev 10 crw------- console rw root sleep 98909 root - - error - root sleep 98909 wd - - error - root sleep 98909 text - - error - root sleep 98909 ctty /dev 10 crw------- console rw root sleep 98909 0 /dev 36 crw-rw-rw- null r root sh 52193 root - - error - root sh 52193 wd - - error - root sh 52193 text - - error - root sh 52193 ctty /dev 10 crw------- console rw root sh 52193 0 /dev 36 crw-rw-rw- null r root sh 8562 root - - error - root sh 8562 wd - - error - root sh 8562 text - - error - root sh 8562 ctty /dev 10 crw------- console rw root sh 8562 0 /dev 10 crw------- console rw root sh 8562 6 /dev 10 crw------- console rw root ping 46609 root - - error - root ping 46609 wd - - error - root ping 46609 text - - error - root ping 46609 0 /dev 36 crw-rw-rw- null rw root ping 46609 6 /dev 36 crw-rw-rw- null rw root ping 93248 root - - error - root ping 93248 wd - - error - root ping 93248 text - - error - root ping 93248 0 /dev 36 crw-rw-rw- null r root ping 93248 6 /dev 36 crw-rw-rw- null w root hald-addon-storage 12983 root - - error - root hald-addon-storage 12983 wd - - error - root hald-addon-storage 12983 text - - error - root hald-addon-storage 12983 0 /dev 36 crw-rw-rw- null r root hald-addon-mouse-s 1886 root - - error - root hald-addon-mouse-s 1886 wd - - error - root hald-addon-mouse-s 1886 text - - error - root hald-addon-mouse-s 1886 0 /dev 36 crw-rw-rw- null r root hald-addon-mouse-s 79483 root - - error - root hald-addon-mouse-s 79483 wd - - error - root hald-addon-mouse-s 79483 text - - error - root hald-addon-mouse-s 79483 0 /dev 36 crw-rw-rw- null r root hald-runner 49233 root - - error - root hald-runner 49233 wd - - error - root hald-runner 49233 text - - error - root hald-runner 49233 0 /dev 36 crw-rw-rw- null r root hald-runner 49233 6 /dev 36 crw-rw-rw- null rw root hald-runner 49233 12 /dev 36 crw-rw-rw- null rw root hald-runner 49233 18* local stream fffff80039c1c700 <-> fffff800= 39d6f000 root hald-runner 49233 24* pipe fffff8002b8605f0 <-> fffff8002b860758= 0 rw root hald-runner 49233 30* pipe fffff8002b860758 <-> fffff8002b8605f0= 0 rw root hald-runner 49233 36* pipe fffff8002b8f3000 <-> fffff8002b8f3168= 0 rw root hald-runner 49233 42* pipe fffff8002b8f3168 <-> fffff8002b8f3000= 0 rw root console-kit-daemon 74083 root - - error - root console-kit-daemon 74083 wd - - error - root console-kit-daemon 74083 text - - error - root console-kit-daemon 74083 0 /dev 36 crw-rw-rw- null rw root console-kit-daemon 74083 6 /dev 36 crw-rw-rw- null rw root console-kit-daemon 74083 12 /dev 36 crw-rw-rw- null rw haldaemo hald 21902 root - - error - haldaemo hald 21902 wd - - error - haldaemo hald 21902 text - - error - haldaemo hald 21902 0 /dev 36 crw-rw-rw- null rw haldaemo hald 21902 6 /dev 36 crw-rw-rw- null rw haldaemo hald 21902 12 /dev 36 crw-rw-rw- null rw haldaemo hald 21902 18* pipe fffff8002b860be0 <-> fffff8002b860d48 = 0 rw haldaemo hald 21902 24* pipe fffff8002b860d48 <-> fffff8002b860be0 = 0 rw haldaemo hald 21902 42* pipe fffff8002b8f22f8 <-> fffff8002b8f2460 = 0 rw haldaemo hald 21902 48* pipe fffff8002b8f2460 <-> fffff8002b8f22f8 = 0 rw shawn python2.7 8122 root - - error - shawn python2.7 8122 wd - - error - shawn python2.7 8122 jail - - error - shawn python2.7 8122 text - - error - shawn python2.7 8122 ctty /jails/mail/mutt-opnsense/dev 222 crw--w-= --- pts/0 rw shawn python2.7 8122 0 /jails/mail/mutt-opnsense/dev 222 crw--w-= --- pts/0 rw shawn python2.7 8122 6 /jails/mail/mutt-opnsense/dev 222 crw--w-= --- pts/0 rw shawn tmux 77405 root - - error - shawn tmux 77405 wd - - error - shawn tmux 77405 jail - - error - shawn tmux 77405 text - - error - shawn tmux 77405 0 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw shawn tmux 77405 6 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root cron 62337 root - - error - root cron 62337 wd - - error - root cron 62337 jail - - error - root cron 62337 text - - error - root cron 62337 0 /jails/sdr-01/dev 36 crw-rw-rw- null = rw smmsp sendmail 50148 root - - error - smmsp sendmail 50148 wd - - error - smmsp sendmail 50148 jail - - error - smmsp sendmail 50148 text - - error - smmsp sendmail 50148 0 /jails/sdr-01/dev 36 crw-rw-rw- null = r root sendmail 86699 root - - error - root sendmail 86699 wd - - error - root sendmail 86699 jail - - error - root sendmail 86699 text - - error - root sendmail 86699 0 /jails/sdr-01/dev 36 crw-rw-rw- null = r root cron 76410 root - - error - root cron 76410 wd - - error - root cron 76410 jail - - error - root cron 76410 text - - error - root cron 76410 0 /jails/mail/mutt-hbsd/dev 36 crw-rw-rw- = null rw root sshd 64471 root - - error - root sshd 64471 wd - - error - root sshd 64471 jail - - error - root sshd 64471 text - - error - root sshd 64471 0 /jails/mail/mutt-hbsd/dev 36 crw-rw-rw- = null rw root cron 28077 root - - error - root cron 28077 wd - - error - root cron 28077 jail - - error - root cron 28077 text - - error - root cron 28077 0 /jails/mail/mutt-tormail/dev 36 crw-rw-r= w- null rw root sshd 74375 root - - error - root sshd 74375 wd - - error - root sshd 74375 jail - - error - root sshd 74375 text - - error - root sshd 74375 0 /jails/mail/mutt-tormail/dev 36 crw-rw-r= w- null rw root sshd 67573 root - - error - root sshd 67573 wd - - error - root sshd 67573 jail - - error - root sshd 67573 text - - error - root sshd 67573 0 /jails/sdr-01/dev 36 crw-rw-rw- null = rw root cron 58237 root - - error - root cron 58237 wd - - error - root cron 58237 jail - - error - root cron 58237 text - - error - root cron 58237 0 /jails/mail/mutt-gmail/dev 36 crw-rw-rw-= null rw root sshd 52996 root - - error - root sshd 52996 wd - - error - root sshd 52996 jail - - error - root sshd 52996 text - - error - root sshd 52996 0 /jails/mail/mutt-gmail/dev 36 crw-rw-rw-= null rw root cron 56075 root - - error - root cron 56075 wd - - error - root cron 56075 jail - - error - root cron 56075 text - - error - root cron 56075 0 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root sshd 33395 root - - error - root sshd 33395 wd - - error - root sshd 33395 jail - - error - root sshd 33395 text - - error - root sshd 33395 0 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root cron 85171 root - - error - root cron 85171 wd - - error - root cron 85171 jail - - error - root cron 85171 text - - error - root cron 85171 0 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l rw smmsp sendmail 88932 root - - error - smmsp sendmail 88932 wd - - error - smmsp sendmail 88932 jail - - error - smmsp sendmail 88932 text - - error - smmsp sendmail 88932 0 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l r root sendmail 85036 root - - error - root sendmail 85036 wd - - error - root sendmail 85036 jail - - error - root sendmail 85036 text - - error - root sendmail 85036 0 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l r root syslogd 54664 root - - error - root syslogd 54664 wd - - error - root syslogd 54664 jail - - error - root syslogd 54664 text - - error - root syslogd 54664 0 /jails/mail/mutt-gmail/dev 36 crw-rw-rw-= null rw root syslogd 54664 6 /jails/mail/mutt-gmail/dev 36 crw-rw-rw-= null rw root syslogd 54664 12 /jails/mail/mutt-gmail/dev 36 crw-rw-rw-= null rw root syslogd 54664 18* pipe fffff80039ae6be0 <-> fffff80039ae6d48 = 0 rw root syslogd 96116 root - - error - root syslogd 96116 wd - - error - root syslogd 96116 jail - - error - root syslogd 96116 text - - error - root syslogd 96116 0 /jails/mail/mutt-hbsd/dev 36 crw-rw-rw- = null rw root syslogd 96116 6 /jails/mail/mutt-hbsd/dev 36 crw-rw-rw- = null rw root syslogd 96116 12 /jails/mail/mutt-hbsd/dev 36 crw-rw-rw- = null rw root syslogd 96116 18* pipe fffff804468f1be0 <-> fffff804468f1d48 = 0 rw root syslogd 94651 root - - error - root syslogd 94651 wd - - error - root syslogd 94651 jail - - error - root syslogd 94651 text - - error - root syslogd 94651 0 /jails/mail/mutt-tormail/dev 36 crw-rw-r= w- null rw root syslogd 94651 6 /jails/mail/mutt-tormail/dev 36 crw-rw-r= w- null rw root syslogd 94651 12 /jails/mail/mutt-tormail/dev 36 crw-rw-r= w- null rw root syslogd 94651 18* pipe fffff8002b879000 <-> fffff8002b879168 = 0 rw root syslogd 73197 root - - error - root syslogd 73197 wd - - error - root syslogd 73197 jail - - error - root syslogd 73197 text - - error - root syslogd 73197 0 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root syslogd 73197 6 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root syslogd 73197 12 /jails/mail/mutt-opnsense/dev 36 crw-rw-= rw- null rw root syslogd 73197 18* pipe fffff80039ae5000 <-> fffff80039ae5168 = 0 rw root syslogd 15057 root - - error - root syslogd 15057 wd - - error - root syslogd 15057 jail - - error - root syslogd 15057 text - - error - root syslogd 15057 0 /jails/sdr-01/dev 36 crw-rw-rw- null = rw root syslogd 15057 6 /jails/sdr-01/dev 36 crw-rw-rw- null = rw root syslogd 15057 12 /jails/sdr-01/dev 36 crw-rw-rw- null = rw root syslogd 15057 18* pipe fffff80039ae62f8 <-> fffff80039ae6460 = 0 rw root syslogd 2325 root - - error - root syslogd 2325 wd - - error - root syslogd 2325 jail - - error - root syslogd 2325 text - - error - root syslogd 2325 0 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l rw root syslogd 2325 6 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l rw root syslogd 2325 12 /jails/bhyve-01/dev 36 crw-rw-rw- nul= l rw root syslogd 2325 18* pipe fffff8002b8f3be0 <-> fffff8002b8f3d48 = 0 rw root cron 44349 root - - error - root cron 44349 wd - - error - root cron 44349 text - - error - root cron 44349 0 /dev 36 crw-rw-rw- null rw smmsp sendmail 34691 root - - error - smmsp sendmail 34691 wd - - error - smmsp sendmail 34691 text - - error - smmsp sendmail 34691 0 /dev 36 crw-rw-rw- null r root sendmail 59787 root - - error - root sendmail 59787 wd - - error - root sendmail 59787 text - - error - root sendmail 59787 0 /dev 36 crw-rw-rw- null r colord colord 9162 root - - error - colord colord 9162 wd - - error - colord colord 9162 text - - error - colord colord 9162 0 /dev 36 crw-rw-rw- null rw colord colord 9162 6 /dev 36 crw-rw-rw- null rw colord colord 9162 12 /dev 36 crw-rw-rw- null rw root cupsd 61940 root - - error - root cupsd 61940 wd - - error - root cupsd 61940 text - - error - root cupsd 61940 0 /dev 36 crw-rw-rw- null r root cupsd 61940 6 /dev 36 crw-rw-rw- null w root sshd 4936 root - - error - root sshd 4936 wd - - error - root sshd 4936 text - - error - root sshd 4936 0 /dev 36 crw-rw-rw- null rw root openvpn 52369 root - - error - root openvpn 52369 wd - - error - root openvpn 52369 text - - error - root openvpn 52369 0 /dev 36 crw-rw-rw- null rw unbound unbound 39378 root - - error - unbound unbound 39378 wd - - error - unbound unbound 39378 jail - - error - unbound unbound 39378 text - - error - unbound unbound 39378 0 /dev 36 crw-rw-rw- null rw unbound unbound 39378 6 /dev 36 crw-rw-rw- null rw unbound unbound 39378 12 /dev 36 crw-rw-rw- null rw vnstat vnstatd 86810 root - - error - vnstat vnstatd 86810 wd - - error - vnstat vnstatd 86810 text - - error - vnstat vnstatd 86810 0 /dev 36 crw-rw-rw- null rw dhcpd dhcpd 28282 root - - error - dhcpd dhcpd 28282 wd - - error - dhcpd dhcpd 28282 text - - error - dhcpd dhcpd 28282 0 /dev 36 crw-rw-rw- null rw dhcpd dhcpd 28282 6 /dev 36 crw-rw-rw- null rw root powerd 98208 root - - error - root powerd 98208 wd - - error - root powerd 98208 text - - error - root powerd 98208 0 /dev 36 crw-rw-rw- null rw root zsh 24466 root - - error - root zsh 24466 wd - - error - root zsh 24466 text - - error - root zsh 24466 0 /dev 36 crw-rw-rw- null r root zsh 24466 6 - - bad - messageb dbus-daemon 98685 root - - error - messageb dbus-daemon 98685 wd - - error - messageb dbus-daemon 98685 text - - error - messageb dbus-daemon 98685 0 /dev 36 crw-rw-rw- null rw messageb dbus-daemon 98685 6 /dev 36 crw-rw-rw- null rw messageb dbus-daemon 98685 12 /dev 36 crw-rw-rw- null rw root syslogd 42723 root - - error - root syslogd 42723 wd - - error - root syslogd 42723 text - - error - root syslogd 42723 0 /dev 36 crw-rw-rw- null rw root syslogd 42723 6 /dev 36 crw-rw-rw- null rw root syslogd 42723 12 /dev 36 crw-rw-rw- null rw root syslogd 42723 18* pipe fffff80039ae48e8 <-> fffff80039ae4a50 = 0 rw root pf purge 7228 root - - error - root pf purge 7228 wd - - error - root devd 70948 root - - error - root devd 70948 wd - - error - root devd 70948 text - - error - root devd 70948 0 /dev 36 crw-rw-rw- null rw root devd 70948 6 /dev 36 crw-rw-rw- null rw _dhcp dhclient 28545 root - - error - _dhcp dhclient 28545 wd - - error - _dhcp dhclient 28545 text - - error - _dhcp dhclient 28545 0 /dev 36 crw-rw-rw- null rw _dhcp dhclient 28545 6 /dev 36 crw-rw-rw- null rw root dhclient 17941 root - - error - root dhclient 17941 wd - - error - root dhclient 17941 text - - error - root dhclient 17941 0 /dev 36 crw-rw-rw- null rw root dhclient 17941 6 /dev 36 crw-rw-rw- null rw root dhclient 30912 root - - error - root dhclient 30912 wd - - error - root dhclient 30912 text - - error - root dhclient 30912 0 /dev 36 crw-rw-rw- null rw root dhclient 30912 6 /dev 36 crw-rw-rw- null rw root moused 33269 root - - error - root moused 33269 wd - - error - root moused 33269 text - - error - root moused 33269 0 /dev 36 crw-rw-rw- null rw root moused 33269 6 /dev 36 crw-rw-rw- null rw root adjkerntz 64483 root - - error - root adjkerntz 64483 wd - - error - root adjkerntz 64483 text - - error - root adjkerntz 64483 0 /dev 36 crw-rw-rw- null rw root g_eli[3] ada0p2 27080 root - - error - root g_eli[3] ada0p2 27080 wd - - error - root g_eli[2] ada0p2 82183 root - - error - root g_eli[2] ada0p2 82183 wd - - error - root g_eli[1] ada0p2 77161 root - - error - root g_eli[1] ada0p2 77161 wd - - error - root g_eli[0] ada0p2 37813 root - - error - root g_eli[0] ada0p2 37813 wd - - error - root zfskern 8 root - - error - root zfskern 8 wd - - error - root init 1 root - - error - root init 1 wd - - error - root init 1 text - - error - root kernel 0 root - - error - root kernel 0 wd - - error - ------------------------------------------------------------------------ dmesg [1] ---<>--- [1] Copyright (c) 2013-2018 The HardenedBSD Project. [1] Copyright (c) 1992-2018 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 12.0-ALPHA2 #4 6091fec317a(hardened/current/master)-dirty: Thu= Aug 23 18:37:45 EDT 2018 [1] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd= 64 [1] FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on L= LVM 6.0.1) [1] VT(vga): text 80x25 [1] HardenedBSD: initialize and check features (__HardenedBSD_version 12000= 58 __FreeBSD_version 1200081). [1] CPU: Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz (2808.13-MHz K8-class C= PU) [1] Origin=3D"GenuineIntel" Id=3D0x506e3 Family=3D0x6 Model=3D0x5e St= epping=3D3 [1] Features=3D0xbfebfbff [1] Features2=3D0x7ffafbff [1] AMD Features=3D0x2c100800 [1] AMD Features2=3D0x121 [1] Structured Extended Features=3D0x29c6fbf [1] Structured Extended Features3=3D0xc000000 [1] XSAVE Features=3D0xf [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory =3D 68719476736 (65536 MB) [1] avail memory =3D 66636849152 (63549 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 4 core(s) [1] random: unblocking device. [1] ioapic0 irqs 0-119 on motherboard [1] Launching APs: 1 2 3 [1] Timecounter "TSC-low" frequency 1404066337 Hz quality 1000 [1] random: entropy device external interface [1] kbd1 at kbdmux0 [1] module_register_init: MOD_LOAD (vesa, 0xffffffff810451f0, 0) error 19 [1] random: registering fast source Intel Secure Key RNG [1] random: fast provider: "Intel Secure Key RNG" [1] netmap: loaded module [1] [ath_hal] loaded [1] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX plat= forms 390.77 Tue Jul 10 21:54:30 PDT 2018 [1] nexus0 [1] vtvga0: on motherboard [1] cryptosoft0: on motherboard [1] aesni0: on motherboard [1] acpi0: on motherboard [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] hpet0: iomem 0xfed00000-0xfed003ff on acpi0 [1] Timecounter "HPET" frequency 24000000 Hz quality 950 [1] Event timer "HPET" frequency 24000000 Hz quality 550 [1] Event timer "HPET1" frequency 24000000 Hz quality 440 [1] Event timer "HPET2" frequency 24000000 Hz quality 440 [1] Event timer "HPET3" frequency 24000000 Hz quality 440 [1] Event timer "HPET4" frequency 24000000 Hz quality 440 [1] atrtc0: port 0x70-0x77 irq 8 on acpi0 [1] atrtc0: Warning: Couldn't map I/O. [1] atrtc0: registered as a time-of-day clock, resolution 1.000000s [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 [1] acpi_ec0: port 0x930,0x934 on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: irq 16 at device 1.0 on pci0 [1] pci1: on pcib1 [1] vgapci0: port 0xe000-0xe07f mem 0xdb000000-0xd= bffffff,0xb0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 at device 0.0 on= pci1 [1] nvidia0: on vgapci0 [1] vgapci0: child nvidia0 requested pci_enable_io [1] vgapci0: child nvidia0 requested pci_enable_io [1] acpi_video0: on vgapci0 [1] vgapci0: Boot video device [1] hdac0: mem 0xdc080000-0xdc083fff irq 1= 7 at device 0.1 on pci1 [1] xhci0: mem 0xda130000-0xda13ff= ff irq 16 at device 20.0 on pci0 [1] xhci0: 32 bytes context size, 64-bit DMA [1] usbus0: waiting for BIOS to give up control [1] usbus0 on xhci0 [1] usbus0: 5.0Gbps Super Speed USB v3.0 [1] pci0: at device 22.0 (no driver attached) [1] ahci0: port 0xf050-0xf057,0xf= 040-0xf043,0xf020-0xf03f mem 0xda150000-0xda151fff,0xda154000-0xda1540ff,0x= da153000-0xda1537ff irq 16 at device 23.0 on pci0 [1] ahci0: AHCI v1.31 with 3 6Gbps ports, Port Multiplier not supported [1] ahcich1: at channel 1 on ahci0 [1] ahcich3: at channel 3 on ahci0 [1] ahcich4: at channel 4 on ahci0 [1] ahciem0: on ahci0 [1] pcib2: irq 17 at device 28.0 on pci0 [1] pci2: on pcib2 [1] pci2: at device 0.0 (no driver attached) [1] pcib3: irq 18 at device 28.2 on pci0 [1] pci3: on pcib3 [1] pci3: at device 0.0 (no driver attached) [1] pcib4: irq 16 at device 28.4 on pci0 [1] pcib4: [GIANT-LOCKED] [1] pcib5: irq 16 at device 29.0 on pci0 [1] pci4: on pcib5 [1] nvme0: mem 0xdc200000-0xdc203fff irq 16 at device= 0.0 on pci4 [1] isab0: at device 31.0 on pci0 [1] isa0: on isab0 [1] pci0: at device 31.2 (no driver attached) [1] hdac1: mem 0xda148000-0xda14bfff,0= xda120000-0xda12ffff irq 16 at device 31.3 on pci0 [1] em0: mem 0xda100000-0xda11ffff i= rq 16 at device 31.6 on pci0 [1] em0: attach_pre capping queues at 1 [1] em0: using 1024 tx descriptors and 1024 rx descriptors [1] em0: msix_init qsets capped at 1 [1] em0: Unable to map MSIX table=20 [1] em0: Using an MSI interrupt [1] em0: allocated for 1 tx_queues [1] em0: allocated for 1 rx_queues [1] em0: Ethernet address: 18:db:f2:3a:13:0d [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 [1] acpi_lid0: on acpi0 [1] acpi_button0: on acpi0 [1] acpi_button1: on acpi0 [1] acpi_acad0: on acpi0 [1] battery0: on acpi0 [1] acpi_tz0: on acpi0 [1] atkbdc0: port 0x60,0x64 irq 1 on acpi0 [1] atkbd0: irq 1 on atkbdc0 [1] kbd0 at atkbd0 [1] atkbd0: [GIANT-LOCKED] [1] psm0: irq 12 on atkbdc0 [1] psm0: [GIANT-LOCKED] [1] psm0: model IntelliMouse, device ID 3 [1] orm0: at iomem 0xd9800-0xda7ff pnpid ORM0000 on isa0 [1] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid= PNP0900 on isa0 [1] coretemp0: on cpu0 [1] est0: on cpu0 [1] ZFS filesystem version: 5 [1] ZFS storage pool version: features support (5000) [1] Timecounters tick every 1.000 msec [1] hdacc0: at cad 0 on hdac0 [1] hdaa0: at nid 1 on hdacc0 [1] pcm0: at nid 4 on hdaa0 [1] pcm1: at nid 5 on hdaa0 [1] pcm2: at nid 6 on hdaa0 [1] pcm3: at nid 7 on hdaa0 [1] ugen0.1: <0x8086 XHCI root HUB> at usbus0 [1] ada0 at ahcich3 bus 0 scbus1 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S252NXAG601111V ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 976762MB (2000409264 512 byte sectors) ada0: quirks=3D0x3<4K,NCQ_TRIM_BROKEN> [1] uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbu= s0 [1] ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device [1] nvd0: NVMe namespace [1] nvd0: 976762MB (2000409264 512 byte sectors) [1] hdacc1: at cad 0 on hdac1 [1] hdaa1: at nid 1 on hdacc1 [1] GEOM_ELI: Device ada0p3.eli created. [1] GEOM_ELI: Encryption: AES-XTS 256 [1] GEOM_ELI: Crypto: hardware [1] pcm4: at nid 20,21 and 25 on hdaa1 [1] pcm5: at nid 22 and 19 on hdaa1 [1] Trying to mount root from zfs:rpool/ROOT/master-2018-08-23_01 []... [1] Root mount waiting for: usbus0 [2] Root mount waiting for: usbus0 [2] uhub0: 26 ports with 26 removable, self powered [3] ugen0.2: at usbus0 [3] uhub1 on uhub0 [3] uhub1: on= usbus0 [3] Root mount waiting for: usbus0 [3] uhub1: 4 ports with 4 removable, self powered [4] Root mount waiting for: usbus0 [4] ugen0.3: at usbus0 [4] ukbd0 on uhub1 [4] ukbd0: on usbus0 [4] kbd2 at ukbd0 [5] ugen0.4: at usbus0 [5] ukbd1 on uhub1 [5] ukbd1: on usbus0 [5] kbd3 at ukbd1 [5] ukbd2 on uhub1 [5] ukbd2: on usbus0 [5] kbd4 at ukbd2 [5] Root mount waiting for: usbus0 [5] ugen0.5: at usbus0 [5] uhub2 on uhub1 [5] uhub2: on= usbus0 [6] Root mount waiting for: usbus0 [6] uhub2: 4 ports with 4 removable, self powered [7] ugen0.6: at usbus0 [7] Root mount waiting for: usbus0 [8] ugen0.7: at usbus0 [8] uhub3 on uhub0 [8] uhub3: on= usbus0 [8] Root mount waiting for: usbus0 [9] uhub3: 4 ports with 4 removable, self powered [9] Root mount waiting for: usbus0 [9] ugen0.8: at usbus0 [9] uhub4 on uhub3 [9] uhub4: on= usbus0 [10] Root mount waiting for: usbus0 [11] uhub4: 4 ports with 4 removable, self powered [11] Root mount waiting for: usbus0 [12] Root mount waiting for: usbus0 [12] ugen0.9: at usbus0 [12] umass0 on uhub0 [12] umass0: on usbus0 [12] umass0: SCSI over Bulk-Only; quirks =3D 0xc100 [12] umass0:4:0: Attached to scbus4 [12] da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number 4C530001130120113295 da0: 400.000MB/s transfers da0: 29328MB (60063744 512 byte sectors) da0: quirks=3D0x2 [13] Enter root password, or ^D to go multi-user [13] Password: [16] Enter full pathname of shell or RETURN for /bin/sh: # mount [19] rpool/ROOT/master-2018-08-23_01 on / (zfs, local, noatime, read-only, = nfsv4acls) [19] devfs on /dev (devfs, local, multilabel) [19] # mount -t zfs -orw rpool?\^H\^[[K/ROOT/master-2018-08-23_01 / [28] # sysrc slim_enable=3DNO [32] slim_enable: YES -> NO [32] # exit\^H\^[[K\^H\^[[K\^H\^[[K\^H\^[[Kvi /boot/loader.conf [41] \^[[1;25r\^[[m\^[[4l\^[[?1h\^[=3D\^[[H\^[[2Jkern.geom.label.disk_ident= =2Eenable=3D"0"\^[[1Bkern.geom.label.gptid.enable=3D"0"\^[[1Bzfs_load=3D"YE= S"\^[[1Bvmm_load=3D"YES"\^[[1Bnmdm_load=3D"YES"\^[[1Bif_tap_load=3D"YES"\^[= [1Bif_urndis_load=3D"YES"\^[[1B#linuxkpi_load=3D"YES"\^[[1Bnvidia-modeset_l= oad=3D"YES"\^[[1Bacpi_video_load=3D"YES"\^[[1B#secadm_load=3D"YES"\^[[1B#vf= s.zfs.arc_meta_limit=3D1073741824\^[[1B#vfs.zfs.arc_max=3D2147483648\^[[1B#= compat.linuxkpi.enable_fbc=3D0\^[[1Bhw.psm.synaptics_support=3D1\^[[1B#ipfw= _load=3D"YES"\^[[1B#ipfw_nat_load=3D"YES"\^[[1Bkern.racct.enable=3D0\^[[1Bh= w.vga.textmode=3D"1"\^[[1B#hw.ibrs_disable=3D"0"\^[[1B~\^[[1B\^H~\^[[1B\^H~= \^[[1B\^H~\^[[H\^[[24B/boot/loader.conf: unmodified: line 1\^[[H\^[[24B\^[[= J\^[[23A\^[[1B\^[[1B\^[[1B\^[[1B\^[[1B\^[[1B\^[[1B\^[[1B\^[[A#nvidia-modese= t_load=3D"YES"#\^[[16B\^HCopying file for recovery...\^[[J\^[[16A#\^H\^[[16= B:x/boot/loader.conf: 20 lines, 464 characters\^[[?1l\^[> [49] \^[[24;44H.\^[[1B\^[[25;1H\^[[?1l\^[># shutdown -r now [54] Shutdown NOW! [54] shutdown: [pid 39916] [54] # 2018-08-23T15:17:52.906406-04:00 shutdown 39916 - - reboot by root:= =20 [54] <118> [54] System shutdown time has arrived\^G\^G [54] Waiting (max 60 seconds) for system process `vnlru' to stop... done [54] Waiting (max 60 seconds) for system process `syncer' to stop...=20 [55] Syncing disks, vnodes remaining... 0 done [56] Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done [56] Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop.= =2E. done [56] Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop.= =2E. done [57] Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop.= =2E. done [57] Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop.= =2E. done [58] Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop.= =2E. done [59] Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop.= =2E. done [60] Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop.= =2E. done [60] All buffers synced. [60] Uptime: 1m0s [60] GEOM_ELI: Device ada0p3.eli destroyed. [60] GEOM_ELI: Detached ada0p3.eli on last close. [61] ukbd0: detached [61] ukbd1: detached [61] ukbd2: detached [61] uhub2: detached [61] uhub1: detached [61] uhub4: detached [61] uhub3: detached [61] umass0: detached [61] nvidia-modeset: Unloading ---<>--- [1] Copyright (c) 2013-2018 The HardenedBSD Project. [1] Copyright (c) 1992-2018 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 12.0-ALPHA2 #4 6091fec317a(hardened/current/master)-dirty: Thu= Aug 23 18:37:45 EDT 2018 [1] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd= 64 [1] FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on L= LVM 6.0.1) [1] VT(vga): text 80x25 [1] HardenedBSD: initialize and check features (__HardenedBSD_version 12000= 58 __FreeBSD_version 1200081). [1] CPU: Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz (2808.11-MHz K8-class C= PU) [1] Origin=3D"GenuineIntel" Id=3D0x506e3 Family=3D0x6 Model=3D0x5e St= epping=3D3 [1] Features=3D0xbfebfbff [1] Features2=3D0x7ffafbff [1] AMD Features=3D0x2c100800 [1] AMD Features2=3D0x121 [1] Structured Extended Features=3D0x29c6fbf [1] Structured Extended Features3=3D0xc000000 [1] XSAVE Features=3D0xf [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory =3D 68719476736 (65536 MB) [1] avail memory =3D 66657861632 (63569 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 4 core(s) [1] random: unblocking device. [1] ioapic0 irqs 0-119 on motherboard [1] Launching APs: 2 1 3 [1] Timecounter "TSC-low" frequency 1404056741 Hz quality 1000 [1] random: entropy device external interface [1] kbd1 at kbdmux0 [1] module_register_init: MOD_LOAD (vesa, 0xffffffff810451f0, 0) error 19 [1] random: registering fast source Intel Secure Key RNG [1] random: fast provider: "Intel Secure Key RNG" [1] netmap: loaded module [1] [ath_hal] loaded [1] nexus0 [1] vtvga0: on motherboard [1] cryptosoft0: on motherboard [1] aesni0: on motherboard [1] acpi0: on motherboard [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] hpet0: iomem 0xfed00000-0xfed003ff on acpi0 [1] Timecounter "HPET" frequency 24000000 Hz quality 950 [1] Event timer "HPET" frequency 24000000 Hz quality 550 [1] Event timer "HPET1" frequency 24000000 Hz quality 440 [1] Event timer "HPET2" frequency 24000000 Hz quality 440 [1] Event timer "HPET3" frequency 24000000 Hz quality 440 [1] Event timer "HPET4" frequency 24000000 Hz quality 440 [1] atrtc0: port 0x70-0x77 irq 8 on acpi0 [1] atrtc0: Warning: Couldn't map I/O. [1] atrtc0: registered as a time-of-day clock, resolution 1.000000s [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 [1] acpi_ec0: port 0x930,0x934 on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: irq 16 at device 1.0 on pci0 [1] pci1: on pcib1 [1] vgapci0: port 0xe000-0xe07f mem 0xdb000000-0xd= bffffff,0xb0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 at device 0.0 on= pci1 [1] acpi_video0: on vgapci0 [1] vgapci0: Boot video device [1] hdac0: mem 0xdc080000-0xdc083fff irq 1= 7 at device 0.1 on pci1 [1] xhci0: mem 0xda130000-0xda13ff= ff irq 16 at device 20.0 on pci0 [1] xhci0: 32 bytes context size, 64-bit DMA [1] usbus0: waiting for BIOS to give up control [1] xhci_interrupt: host controller halted [1] usbus0 on xhci0 [1] usbus0: 5.0Gbps Super Speed USB v3.0 [1] pci0: at device 22.0 (no driver attached) [1] ahci0: port 0xf050-0xf057,0xf= 040-0xf043,0xf020-0xf03f mem 0xda150000-0xda151fff,0xda154000-0xda1540ff,0x= da153000-0xda1537ff irq 16 at device 23.0 on pci0 [1] ahci0: AHCI v1.31 with 3 6Gbps ports, Port Multiplier not supported [1] ahcich1: at channel 1 on ahci0 [1] ahcich3: at channel 3 on ahci0 [1] ahcich4: at channel 4 on ahci0 [1] ahciem0: on ahci0 [1] pcib2: irq 17 at device 28.0 on pci0 [1] pci2: on pcib2 [1] pci2: at device 0.0 (no driver attached) [1] pcib3: irq 18 at device 28.2 on pci0 [1] pci3: on pcib3 [1] pci3: at device 0.0 (no driver attached) [1] pcib4: irq 16 at device 28.4 on pci0 [1] pcib4: [GIANT-LOCKED] [1] pcib5: irq 16 at device 29.0 on pci0 [1] pci4: on pcib5 [1] nvme0: mem 0xdc200000-0xdc203fff irq 16 at device= 0.0 on pci4 [1] isab0: at device 31.0 on pci0 [1] isa0: on isab0 [1] pci0: at device 31.2 (no driver attached) [1] hdac1: mem 0xda148000-0xda14bfff,0= xda120000-0xda12ffff irq 16 at device 31.3 on pci0 [1] em0: mem 0xda100000-0xda11ffff i= rq 16 at device 31.6 on pci0 [1] em0: attach_pre capping queues at 1 [1] em0: using 1024 tx descriptors and 1024 rx descriptors [1] em0: msix_init qsets capped at 1 [1] em0: Unable to map MSIX table=20 [1] em0: Using an MSI interrupt [1] em0: allocated for 1 tx_queues [1] em0: allocated for 1 rx_queues [1] em0: Ethernet address: 18:db:f2:3a:13:0d [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 [1] acpi_lid0: on acpi0 [1] acpi_button0: on acpi0 [1] acpi_button1: on acpi0 [1] acpi_acad0: on acpi0 [1] battery0: on acpi0 [1] acpi_tz0: on acpi0 [1] atkbdc0: port 0x60,0x64 irq 1 on acpi0 [1] atkbd0: irq 1 on atkbdc0 [1] kbd0 at atkbd0 [1] atkbd0: [GIANT-LOCKED] [1] psm0: irq 12 on atkbdc0 [1] psm0: [GIANT-LOCKED] [1] psm0: model IntelliMouse, device ID 3 [1] orm0: at iomem 0xd9800-0xda7ff pnpid ORM0000 on isa0 [1] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid= PNP0900 on isa0 [1] coretemp0: on cpu0 [1] est0: on cpu0 [1] ZFS filesystem version: 5 [1] ZFS storage pool version: features support (5000) [1] Timecounters tick every 1.000 msec [1] hdacc0: at cad 0 on hdac0 [1] hdaa0: at nid 1 on hdacc0 [1] pcm0: at nid 4 on hdaa0 [1] pcm1: at nid 5 on hdaa0 [1] ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device [1] ada0 at ahcich3 bus 0 scbus1 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S252NXAG601111V ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 976762MB (2000409264 512 byte sectors) ada0: quirks=3D0x3<4K,NCQ_TRIM_BROKEN> [1] pcm2: at nid 6 on hdaa0 [1] pcm3: at nid 7 on hdaa0 [1] GEOM_ELI: Device ada0p3.eli created. [1] GEOM_ELI: Encryption: AES-XTS 256 [1] GEOM_ELI: Crypto: hardware [1] ugen0.1: <0x8086 XHCI root HUB> at usbus0 [1] uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbu= s0 [1] nvd0: NVMe namespace [1] nvd0: 976762MB (2000409264 512 byte sectors) [1] hdacc1: at cad 0 on hdac1 [1] hdaa1: at nid 1 on hdacc1 [1] pcm4: at nid 20,21 and 25 on hdaa1 [1] pcm5: at nid 22 and 19 on hdaa1 [1] Trying to mount root from zfs:rpool/ROOT/master-2018-08-23_01 []... [1] Root mount waiting for: usbus0 [2] Root mount waiting for: usbus0 [2] uhub0: 26 ports with 26 removable, self powered [3] ugen0.2: at usbus0 [3] uhub1 on uhub0 [3] uhub1: on= usbus0 [3] Root mount waiting for: usbus0 [3] uhub1: 4 ports with 4 removable, self powered [4] Root mount waiting for: usbus0 [4] ugen0.3: at usbus0 [4] ukbd0 on uhub1 [4] ukbd0: on usbus0 [4] kbd2 at ukbd0 [5] ugen0.4: at usbus0 [5] ukbd1 on uhub1 [5] ukbd1: on usbus0 [5] kbd3 at ukbd1 [5] ukbd2 on uhub1 [5] ukbd2: on usbus0 [5] kbd4 at ukbd2 [5] Root mount waiting for: usbus0 [5] ugen0.5: at usbus0 [5] uhub2 on uhub1 [5] uhub2: on= usbus0 [6] Root mount waiting for: usbus0 [6] uhub2: 4 ports with 4 removable, self powered [7] ugen0.6: at usbus0 [7] Root mount waiting for: usbus0 [8] ugen0.7: at usbus0 [8] uhub3 on uhub0 [8] uhub3: on= usbus0 [8] Root mount waiting for: usbus0 [9] uhub3: 4 ports with 4 removable, self powered [9] Root mount waiting for: usbus0 [9] ugen0.8: at usbus0 [9] uhub4 on uhub3 [9] uhub4: on= usbus0 [10] Root mount waiting for: usbus0 [11] uhub4: 4 ports with 4 removable, self powered [11] Root mount waiting for: usbus0 [12] Root mount waiting for: usbus0 [12] ugen0.9: at usbus0 [12] umass0 on uhub0 [12] umass0: on usbus0 [12] umass0: SCSI over Bulk-Only; quirks =3D 0xc100 [12] umass0:4:0: Attached to scbus4 [12] da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number 4C530001130120113295 da0: 400.000MB/s transfers da0: 29328MB (60063744 512 byte sectors) da0: quirks=3D0x2 [13] GEOM_ELI: Device ada0p2.eli created. [13] GEOM_ELI: Encryption: AES-XTS 128 [13] GEOM_ELI: Crypto: hardware [13] Starting file system checks: [13] Mounting local filesystems:. [14] ELF ldconfig path: /lib /usr/lib /usr/local/lib /usr/local/lib/compat = /usr/local/lib/gcc48 /usr/local/lib/gegl-0.2 /usr/local/lib/graphviz /usr/l= ocal/lib/libav /usr/local/lib/mysql /usr/local/lib/mysql/plugin /usr/local/= lib/nss /usr/local/lib/opencollada /usr/local/lib/perl5/5.26/mach/CORE /usr= /local/lib/qt4 /usr/local/lib/qt5 /usr/local/lib/samba4 /usr/local/llvm40/l= ib /usr/local/llvm50/lib /usr/local/llvm60/lib /usr/local/share/chromium [14] 32-bit compatibility ldconfig path: /usr/local/lib32/compat [14] Loading kernel modules: [14] iwm0: mem 0xdc400000-0xdc401fff = irq 17 at device 0.0 on pci2 [14] iwm0: hw rev 0x200, fw ver 22.361476.0, address f0:d5:bf:e2:aa:e5 [14] ums0 on uhub1 [14] ums0: on usbus0 [14] ums0: 16 buttons and [XYZT] coordinates ID=3D0 [14] Setting hostname: hbsd-dev-laptop. [14] Setting up harvesting: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_= NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED [14] Feeding entropy: . [15] bridge0: Ethernet address: 5e:65:c9:b3:be:b7 [15] tap0: Ethernet address: 00:bd:83:0f:f7:00 [15] tap1: Ethernet address: 00:bd:90:0f:f7:01 [15] tap2: Ethernet address: 00:bd:9c:0f:f7:02 [15] tap3: Ethernet address: 00:bd:a9:0f:f7:03 [15] tap4: Ethernet address: 00:bd:b5:0f:f7:04 [15] tap5: Ethernet address: 00:bd:c1:0f:f7:05 [15] tap6: Ethernet address: 00:bd:ce:0f:f7:06 [15] tap7: Ethernet address: 00:bd:da:0f:f7:07 [15] tap8: Ethernet address: 00:bd:e7:0f:f7:08 [15] tap9: Ethernet address: 00:bd:f3:0f:f7:09 [15] bridge1: Ethernet address: 7e:ee:89:20:dd:96 [15] Created clone interfaces: bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 t= ap7 tap8 tap9 bridge1. [15] lo0: link state changed to UP [16] tap0: promiscuous mode enabled [16] bridge0: link state changed to DOWN [16] tap1: promiscuous mode enabled [16] tap2: promiscuous mode enabled [16] tap3: promiscuous mode enabled [16] tap4: promiscuous mode enabled [16] tap5: promiscuous mode enabled [16] tap6: promiscuous mode enabled [16] tap7: promiscuous mode enabled [19] Link state changed to up [19] em0: link state changed to UP [20] Starting Network: lo0 em0 bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 t= ap7 tap8 tap9 bridge1. [20] lo0: flags=3D8049 metric 0 mtu 16384 [20] options=3D680003 [20] inet6 ::1 prefixlen 128=20 [20] inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 [20] inet 127.0.0.1 netmask 0xff000000=20 [20] groups: lo=20 [20] nd6 options=3D21 [20] em0: flags=3D8843 metric 0 mtu= 1500 [20] options=3D81249b [20] ether 18:db:f2:3a:13:0d [20] media: Ethernet autoselect (1000baseT ) [20] status: active [20] nd6 options=3D29 [20] bridge0: flags=3D8843 metric 0= mtu 1500 [20] ether 5e:65:c9:b3:be:b7 [20] inet 192.168.8.1 netmask 0xffffff00 broadcast 192.168.8.255=20 [20] id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 [20] maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 [20] root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 [20] member: tap7 flags=3D143 [20] ifmaxaddr 0 port 11 priority 128 path cost 2000000 [20] member: tap6 flags=3D143 [20] ifmaxaddr 0 port 10 priority 128 path cost 2000000 [20] member: tap5 flags=3D143 [20] ifmaxaddr 0 port 9 priority 128 path cost 2000000 [20] member: tap4 flags=3D143 [20] ifmaxaddr 0 port 8 priority 128 path cost 2000000 [20] member: tap3 flags=3D143 [20] ifmaxaddr 0 port 7 priority 128 path cost 2000000 [20] member: tap2 flags=3D143 [20] ifmaxaddr 0 port 6 priority 128 path cost 2000000 [20] member: tap1 flags=3D143 [20] ifmaxaddr 0 port 5 priority 128 path cost 2000000 [20] member: tap0 flags=3D143 [20] ifmaxaddr 0 port 4 priority 128 path cost 2000000 [20] groups: bridge=20 [20] nd6 options=3D9 [20] tap0: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:83:0f:f7:00 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap1: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:90:0f:f7:01 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap2: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:9c:0f:f7:02 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap3: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:a9:0f:f7:03 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap4: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:b5:0f:f7:04 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap5: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:c1:0f:f7:05 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap6: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:ce:0f:f7:06 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap7: flags=3D8902 metric 0 mtu 1= 500 [20] options=3D80000 [20] ether 00:bd:da:0f:f7:07 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap8: flags=3D8802 metric 0 mtu 1500 [20] options=3D80000 [20] ether 00:bd:e7:0f:f7:08 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] tap9: flags=3D8802 metric 0 mtu 1500 [20] options=3D80000 [20] ether 00:bd:f3:0f:f7:09 [20] groups: tap=20 [20] media: Ethernet autoselect [20] status: no carrier [20] nd6 options=3D29 [20] bridge1: flags=3D8843 metric 0= mtu 1500 [20] ether 7e:ee:89:20:dd:96 [20] inet 192.168.7.1 netmask 0xffffff00 broadcast 192.168.7.255=20 [20] id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 [20] maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 [20] root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 [20] groups: bridge=20 [20] nd6 options=3D9 [20] Starting devd. [22] Autoloading module: uhid.koums.ko [22] kldload: can't load uhid.koums.ko: No such file or directory [22] Autoloading module: uhid.ko [22] uhid0 on uhub1 [22] uhid0: on usbus0 [22] device_attach: uhid0 attach returned 12 [23] Autoloading module: uhid.koums.ko [23] kldload: can't load uhid.koums.ko: No such file or directory [23] Autoloading module: uhid.ko [23] Starting ums0 moused. [23] Autoloading module: uhid.ko [23] Autoloading module: uhid.ko [23] Starting Network: tap0. [23] tap0: flags=3D8902 metric 0 mtu 1= 500 [23] options=3D80000 [23] ether 00:bd:83:0f:f7:00 [23] groups: tap=20 [23] media: Ethernet autoselect [23] status: no carrier [23] nd6 options=3D29 [23] Starting Network: tap1. [23] tap1: flags=3D8902 metric 0 mtu 1= 500 [23] options=3D80000 [23] ether 00:bd:90:0f:f7:01 [23] groups: tap=20 [23] media: Ethernet autoselect [23] status: no carrier [23] nd6 options=3D29 [24] Starting Network: tap2. [24] tap2: flags=3D8902 metric 0 mtu 1= 500 [24] options=3D80000 [24] ether 00:bd:9c:0f:f7:02 [24] groups: tap=20 [24] media: Ethernet autoselect [24] status: no carrier [24] nd6 options=3D29 [24] Starting Network: tap3. [24] tap3: flags=3D8902 metric 0 mtu 1= 500 [24] options=3D80000 [24] ether 00:bd:a9:0f:f7:03 [24] groups: tap=20 [24] media: Ethernet autoselect [24] status: no carrier [24] nd6 options=3D29 [24] Starting Network: tap4. [24] tap4: flags=3D8902 metric 0 mtu 1= 500 [24] options=3D80000 [24] ether 00:bd:b5:0f:f7:04 [24] groups: tap=20 [24] media: Ethernet autoselect [24] status: no carrier [24] nd6 options=3D29 [24] Starting Network: tap5. [24] tap5: flags=3D8902 metric 0 mtu 1= 500 [24] options=3D80000 [24] ether 00:bd:c1:0f:f7:05 [24] groups: tap=20 [24] media: Ethernet autoselect [24] status: no carrier [24] nd6 options=3D29 [25] Starting Network: tap6. [25] tap6: flags=3D8902 metric 0 mtu 1= 500 [25] options=3D80000 [25] ether 00:bd:ce:0f:f7:06 [25] groups: tap=20 [25] media: Ethernet autoselect [25] status: no carrier [25] nd6 options=3D29 [25] Starting Network: tap7. [25] tap7: flags=3D8902 metric 0 mtu 1= 500 [25] options=3D80000 [25] ether 00:bd:da:0f:f7:07 [25] groups: tap=20 [25] media: Ethernet autoselect [25] status: no carrier [25] nd6 options=3D29 [25] Starting Network: tap8. [25] tap8: flags=3D8802 metric 0 mtu 1500 [25] options=3D80000 [25] ether 00:bd:e7:0f:f7:08 [25] groups: tap=20 [25] media: Ethernet autoselect [25] status: no carrier [25] nd6 options=3D29 [25] Starting Network: tap9. [25] tap9: flags=3D8802 metric 0 mtu 1500 [25] options=3D80000 [25] ether 00:bd:f3:0f:f7:09 [25] groups: tap=20 [25] media: Ethernet autoselect [25] status: no carrier [25] nd6 options=3D29 [25] Starting dhclient. [26] DHCPREQUEST on em0 to 255.255.255.255 port 67 [26] DHCPACK from 192.168.254.1 [26] bound to 192.168.254.100 -- renewal in 21483 seconds. [26] Enabling pf. [26] add host 127.0.0.1: gateway lo0 fib 0: route already in table [26] Additional inet routing options: gateway=3DYES. [26] add host ::1: gateway lo0 fib 0: route already in table [26] add net fe80::: gateway ::1 [26] add net ff02::: gateway ::1 [26] add net ::ffff:0.0.0.0: gateway ::1 [26] add net ::0.0.0.0: gateway ::1 [26] Creating and/or trimming log files. [26] Starting syslogd. [27] Updating CPU Microcode... [27] CPU: Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz (2808.11-MHz K8-class = CPU) [27] Origin=3D"GenuineIntel" Id=3D0x506e3 Family=3D0x6 Model=3D0x5e S= tepping=3D3 [27] Features=3D0xbfebfbff [27] Features2=3D0x7ffafbff [27] AMD Features=3D0x2c100800 [27] AMD Features2=3D0x121 [27] Structured Extended Features=3D0x29c6fbf [27] Structured Extended Features3=3D0x9c000000 [27] XSAVE Features=3D0xf [27] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [27] TSC: P-state invariant, performance statistics [27] Done. [27] No core dumps found. [27] Clearing /tmp (X related). [27] Starting avahi-daemon. [30] Aug 23 19:19:06 hbsd-dev-laptop avahi-daemon[4338]: dbus_bus_get_priva= te(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such = file or directory [30] Starting dbus. [30] Starting local daemons:. [30] Updating motd:. [30] Mounting late filesystems:. [30] Starting powerd. [30] Starting dhcpd. [30] Internet Systems Consortium DHCP Server 4.3.6-P1 [30] Copyright 2004-2018 Internet Systems Consortium. [30] All rights reserved. [30] For info, please visit https://www.isc.org/software/dhcp/ [30] Config file: /usr/local/etc/dhcpd.conf [30] Database file: /var/db/dhcpd/dhcpd.leases [30] PID file: /var/run/dhcpd/dhcpd.pid [30] Wrote 6 leases to leases file. [30]=20 [30] No subnet declaration for bridge1 (192.168.7.1). [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]:=20 [30] ** Ignoring requests on bridge1. If this is not what [30] you want, please write a subnet declaration [30] in your dhcpd.conf file for the network segment [30] to which interface bridge1 is attached. ** [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: No subnet declaration fo= r bridge1 (192.168.7.1). [30]=20 [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: ** Ignoring requests on = bridge1. If this is not what [30] Listening on BPF/bridge0/5e:65:c9:b3:be:b7/192.168.8.0/24 [30] Sending on BPF/bridge0/5e:65:c9:b3:be:b7/192.168.8.0/24 [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: you want, please writ= e a subnet declaration [30]=20 [30] No subnet declaration for em0 (192.168.254.100). [30] ** Ignoring requests on em0. If this is not what [30] you want, please write a subnet declarationAug 23 19:19:07 hbsd-dev= -laptop dhcpd[86502]: in your dhcpd.conf file for the network segment [30]=20 [30] in your dhcpd.conf file for the network segment [30] to which interface em0 is attached. ** [30]=20 [30] Sending on Socket/fallback/fallback-net [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: to which interface br= idge1 is attached. ** [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]:=20 [30] Aug 23 19:19:07 hbsd-dev-laptop syslogd: last message repeated 1 times [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: No subnet declaration fo= r em0 (192.168.254.100). [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: ** Ignoring requests on = em0. If this is not what [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: you want, please writ= e a subnet declaration [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: in your dhcpd.conf fi= le for the network segment [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]: to which interface em= 0 is attached. ** [30] Aug 23 19:19:07 hbsd-dev-laptop dhcpd[86502]:=20 [31] Starting vnstat. [31] Obtaining a trust anchor:. [31] Starting unbound. [33] Starting hald. [33] Configuring vt: blanktime. [33] Starting openvpn. [33] Performing sanity check on sshd configuration. [33] Starting sshd. [33] Starting cupsd. [33] Starting avahi-dnsconfd. [33] Aug 23 19:19:10 hbsd-dev-laptop avahi-dnsconfd[47876]: connect(): No s= uch file or directory [33] Starting sendmail_submit. [38] tun0: link state changed to UP [49] Starting sendmail_msp_queue. [64] Starting cron. [64] Starting jails: [64] epair2a: Ethernet address: 02:8c:15:7b:56:0a [64] epair2b: Ethernet address: 02:8c:15:7b:56:0b [64] epair2a: link state changed to UP [64] epair2b: link state changed to UP [64] epair4a: Ethernet address: 02:8f:1a:d2:ab:0a [64] epair4b: Ethernet address: 02:8f:1a:d2:ab:0b [64] epair4a: link state changed to UP [64] epair4b: link state changed to UP [64] epair0a: Ethernet address: 02:d5:ed:36:05:0a [64] epair0b: Ethernet address: 02:d5:ed:36:05:0b [64] epair0a: link state changed to UP [64] epair0b: link state changed to UP [64] bridge1: link state changed to UP [64] epair2a: promiscuous mode enabled [64] epair0a: promiscuous mode enabled [64] epair4a: promiscuous mode enabled [64] epair3a: Ethernet address: 02:e3:e8:50:9f:0a [64] epair3b: Ethernet address: 02:e3:e8:50:9f:0b [64] epair3a: link state changed to UP [64] epair3b: link state changed to UP [64] epair5a: Ethernet address: 02:35:b0:a6:eb:0a [64] epair5b: Ethernet address: 02:35:b0:a6:eb:0b [64] epair5a: link state changed to UP [64] epair5b: link state changed to UP [64] epair3a: promiscuous mode enabled [64] epair1a: Ethernet address: 02:74:2f:a2:49:0a [64] epair1b: Ethernet address: 02:74:2f:a2:49:0b [64] epair1a: link state changed to UP [64] epair1b: link state changed to UP [64] epair6a: Ethernet address: 02:d2:c2:46:39:0a [64] epair6b: Ethernet address: 02:d2:c2:46:39:0b [64] epair6a: link state changed to UP [64] epair6b: link state changed to UP [64] epair5a: promiscuous mode enabled [64] epair1a: promiscuous mode enabled [64] epair6a: promiscuous mode enabled [65] lo0: link state changed to UP [65] lo0: link state changed to UP [65] lo0: link state changed to UP [65] lo0: link state changed to UP [65] lo0: link state changed to UP [65] lo0: link state changed to UP [65] lo0: link state changed to UP [69] mutt-g2 mutt-hbsd mutt-tormail mutt-opnsense sdr-01 mutt-gmail bhyve-= 01. [69] Starting background file system checks in 60 seconds. [69]=20 [69] Thu Aug 23 19:19:45 EDT 2018 [70] pid 19823 (polkitd), uid 565: exited on signal 11 [248] Aug 23 19:22:45 hbsd-dev-laptop shutdown[86445]: reboot by shawn:=20 [249] Stopping jails: mutt-g2 [249] epair2a: link state changed to DOWN [249] epair2b: link state changed to DOWN [249] in6_purgeaddr: err=3D65, destination address delete failed [249] Memory modified after free 0xfffff80039c89800(2040) val=3D0 @ 0xfffff= 80039c89b98 [249] panic: Most recently used by ifnet [249]=20 [249] cpuid =3D 3 [249] time =3D 1535066565 [249] __HardenedBSD_version =3D 1200058 __FreeBSD_version =3D 1200081 [249] version =3D FreeBSD 12.0-ALPHA2 #4 6091fec317a(hardened/current/mast= er)-dirty: Thu Aug 23 18:37:45 EDT 2018 [249] shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC [249] KDB: stack backtrace: [249] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0= 00041b6b0 [249] vpanic() at vpanic+0x1a8/frame 0xfffffe000041b710 [249] panic() at panic+0x43/frame 0xfffffe000041b770 [249] mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe000041b790 [249] uma_zalloc_arg() at uma_zalloc_arg+0x718/frame 0xfffffe000041b800 [249] malloc() at malloc+0x78/frame 0xfffffe000041b850 [249] xpt_run_allocq() at xpt_run_allocq+0xca/frame 0xfffffe000041b890 [249] adastrategy() at adastrategy+0x70/frame 0xfffffe000041b8c0 [249] g_disk_start() at g_disk_start+0x333/frame 0xfffffe000041b920 [249] g_io_schedule_down() at g_io_schedule_down+0x10b/frame 0xfffffe000041= b960 [249] g_down_procbody() at g_down_procbody+0x6d/frame 0xfffffe000041b970 [249] fork_exit() at fork_exit+0x89/frame 0xfffffe000041b9b0 [249] fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000041b9b0 [249] --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- [249] Uptime: 4m9s [249] Dumping 3665 out of 65350 MB:..1%..11%..21%..31%..41%..51%..61%..71%.= =2E81%..91% ------------------------------------------------------------------------ kernel config options CONFIG_AUTOGENERATED ident LATT-SEC machine amd64 cpu HAMMER makeoptions WITH_CTF=3D1 makeoptions DEBUG=3D-g options MMCCAM options EVDEV_SUPPORT options XENHVM options USB_DEBUG options ATH_ENABLE_11N options AH_AR5416_INTERRUPT_MITIGATION options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options VESA options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options PCI_IOV options PCI_HP options ACPI_DMAR options EARLY_AP_STARTUP options SMP options INVARIANT_SUPPORT options INVARIANTS options DEADLKRES options GDB options FULL_BUF_TRACKING options DDB options BUF_TRACKING options KDB_TRACE options KDB options HBSD_DEBUG options PAX_SEGVGUARD options PAX_HARDENING options PAX_NOEXEC options PAX_ASLR options PAX_SYSCTLS options PAX_JAIL_SUPPORT options PAX_CONTROL_EXTATTR options PAX_CONTROL_ACL_OVERRIDE_SUPPORT options PAX_CONTROL_ACL options PAX options RCTL options RACCT options INCLUDE_CONFIG_FILE options DDB_CTF options KDTRACE_HOOKS options KDTRACE_FRAME options MAC options CAPABILITIES options CAPABILITY_MODE options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=3D128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=3D5000 options COMPAT_FREEBSD11 options COMPAT_FREEBSD10 options GEOM_ELI options GEOM_LABEL options GEOM_RAID options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options QUOTA options UFS_EXTATTR_AUTOSTART options UFS_EXTATTR options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options TCP_HHOOK options TCP_OFFLOAD options IPSEC_SUPPORT options IPSEC options INET6 options INET options VIMAGE options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_GPT options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device mpr device sym device trm device adv device adw device aic device bt device isci device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptnr device hptrr device hpt27xx device iir device ips device mly device twa device tws device aac device aacp device aacraid device ida device mfi device mlx device mrsas device pmspcv device twe device nvme device nvd device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device vt device vt_vga device vt_efifb device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device ppi device puc device bxe device de device em device ix device ixv device ixl device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device cas device dc device et device fxp device gem device hme device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device padlock_rng device rdrand_rng device ether device vlan device tun device md device gif device firmware device bpf device uhci device ohci device ehci device xhci device usb device ukbd device umass device sound device snd_cmi device snd_csa device snd_emu10kx device snd_es137x device snd_hda device snd_ich device snd_via8233 device mmc device mmcsd device sdhci device virtio device virtio_pci device vtnet device virtio_blk device virtio_scsi device virtio_balloon device hyperv device xenpci device vmx device netmap device crypto device coretemp device cpuctl device cryptodev device aesni device evdev ------------------------------------------------------------------------ ddb capture buffer --edrtylun6ewzve3i-- --saevydtzne433viv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAluAhIcACgkQaoRlj1JF bu5HYw//UPIKOwdr6N7JQRYfE0eras58rwAurUdgwkzqO3AGX/sw76WVLPhgm2uO Zblt9WgnmtoT2Uh20w+L7XM/oHXKZtVqR+nb3cxU4FFk6o/1PvlhPNsZ3BMo2XTJ cus1jUj/Pm/t9i/914FSCSAaIXqy0yOgWFuNCeN4897j+PT+wnGzx0xBhtfcPCrx 8gTjn8XENk/5It1/3rn8Qpq8XkJ16YIzXg9kLa/un2F1rUHy346YfHV7DNOI3CZ/ FOVLx8cnVZJarEwQuVwOI0D1x1TeT1JNSThK3qg1XRhgmdY1HJlMfM6o4OFh9KUI tmy3GBfgUPcytwYqVSyWRJbUawQVEQu5VWR2xmS1FHtq6D+IjBhsEr41KQnZ0oA3 AxbkDafGFEeibwyfhGGfFS55yocqwdHdaIsbTz5Tr3noY+oTev5uhllwMS4o76TB W5JTUjudbYqyku1KqP2rNGnmdR3F8KsWH0Mc4LVaW8YhU/bUNe2eotPWUwDJxWjA sm3G0IWbZK5W2trU61QONGf6YieGEQfH/pAu0kr8QCQ/UvdZvtoKrqiCvx/KITUM 5InEET9KysVLPHbFkdPw8PF+kT3m5aBfh2/Z3RXwZB8LApyGXpqjAqmEC60aIh32 TWH2qQeu6Z8KShSlg6u8oen41qzBiIyBIWtVsCLTkSxZd4Zf7qs= =ZAwu -----END PGP SIGNATURE----- --saevydtzne433viv-- From owner-freebsd-current@freebsd.org Fri Aug 24 22:23: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 460221095839 for ; Fri, 24 Aug 2018 22:23:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD78F799DA for ; Fri, 24 Aug 2018 22:23:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id t69-v6so3814587itb.4 for ; Fri, 24 Aug 2018 15:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vKhoMMpGKE9lNkEItER0HyK1G0fm5LHWkB+cZdxBBUs=; b=Tm46sNEzvv5fEwL4c6caaep9rf4komRDgJOlhLCHUYLUI3oydkuQzfa7rDDmazJqWg V1UVx89S1oMdY4yRBenZxow+z/v+ZA8A4PJ3VnLYa643nNZdtcnVD6OCKccFf9oKvMGY s8H9WMTlvqij6a4el6Lztp3WEPdFQHts3nY/rq5i5RcK2Ly9prx6XzYaWFKmF+CqfrX6 6yasvxAmuP4vXgeK2YBcCzPK7eb6G/xsfMarngdNVAvjwHEFzrdKMaE4m7kH3MRIsGmX 0ZCkuMZHTScu+Utw7HuzwlnxQ1K7UN7L/1OGGCMkDyVqxBnaULitXsjO0BKNgkZV00vR 1DWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vKhoMMpGKE9lNkEItER0HyK1G0fm5LHWkB+cZdxBBUs=; b=AiBDnuyzBLWQRAXHOIle9m+FjnphM0xJEWDUjWaV/Eyw2mX6KUV64fByuMqlPgv/UU qSHaB/rakZHqcRb+WQuDf/IivnAMFxSEGWKtSc7aDFPrblLIXt/DX6Yn82+bM90WZvPD 2dZLD9lLjJJ8SS/2B21rrIV6yBEXiRsdDLOUIE7Wuwv6WcOZchIv7hysQFSpQjUDA1gS mLezm6UbIu1BmD1Ps1UiaRZp5tHPVtN+Ay1PUsU2Ba3HuwBOF1ul2pnMDZy37ifNHBNJ xbihDqeA8wzJR+WOiWT8+U49WsUFDBWNWIikaBeJOMbDpTQJasq6zJLXwjSnE+8nvT8w fBaA== X-Gm-Message-State: APzg51AjkzDgbXTfPNTjsqJMWHJT/b6gIhwTg+eKP8uXIO9/to+xd1o8 hlZ1SKcn9EoBlHjNyBAyodORdOtIT218z1N+zT8JbQ== X-Google-Smtp-Source: ANB0VdbnUnvi0MSDZK960yxVFVElo8m4610NAnX4JYKUE1k0KKi+Li9uE6v1j75lxEeQP0njDFIye+bdcc+ZQgBpKHQ= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr2762608ite.39.1535149432879; Fri, 24 Aug 2018 15:23:52 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 16:23:42 -0600 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Matt Macy Cc: aliovx@gmail.com, FreeBSD Current , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:23:54 -0000 On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > Just in case anyone misses the change to UPDATING: > > > > > > 20180821: > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > hardware, > > > or with GPUs predating Radeon and i915 will need to install t= he > > > graphics/drm-legacy-kmod. All other users should be able to u= se > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > Note that this applies only to 12. > > > > I see that The removal of drm and drm2 has been reverted on svn. Could > > you please kindly share the reasons behind the re-inclusion? > > > > > I can=E2=80=99t really give the blow by blow of internal project drama, b= ut the > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet ac= tually documented > anywhere that I=E2=80=99ve seen) were not followed with regards to the de= precation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. > Just so. Our only continued frustration is that we were never given any guidance by > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion w= as taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I=E2=80=99m cautiously optimistic that this well expedi= te > improving communications on those matters. > All the problems that are exposed by this aren't technical. This one is social, but no less important. Warner From owner-freebsd-current@freebsd.org Fri Aug 24 22:26: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 84B341095A8C for ; Fri, 24 Aug 2018 22:26:56 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 391F379DAE for ; Fri, 24 Aug 2018 22:26:56 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id EED41A311 for ; Fri, 24 Aug 2018 22:26:55 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f41.google.com with SMTP id 139-v6so3843888itf.0 for ; Fri, 24 Aug 2018 15:26:55 -0700 (PDT) X-Gm-Message-State: APzg51AKN1poru/E+1ypWkjedB6Vu7omcB3QUoAESgTZ30k0lpYB4n/l ouEpqlHJ82pxdc0YIHFM7WkDhXpTTuGYy4LdoRs= X-Google-Smtp-Source: ANB0VdY+VPn8wsVuui0sByKynFW9rjcnXggtqDu++mGuGVi4ImK9O6eQ7qps5MCbOIT3DjZBAVUXtUiHocMt39B/ctY= X-Received: by 2002:a02:685:: with SMTP id 127-v6mr2835990jav.98.1535149615409; Fri, 24 Aug 2018 15:26:55 -0700 (PDT) MIME-Version: 1.0 References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> In-Reply-To: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> From: Matthew Macy Date: Fri, 24 Aug 2018 15:26:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ifnet use after free To: Shawn Webb Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:26:56 -0000 On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote= : > Hey All, > > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out > which commit introduced the breakage. Attached is the core.txt (which > seems nonsensical because the dump is reporting on a different > thread). If the core.txt gets scrubbed, I've posted it here: > https://gist.github.com/796ea88cec19a1fd2a85f4913482286a > Do you have any guidance on how to reproduce? The hardenedbsd rev isn=E2=80= =99t useful - the svn commit that it=E2=80=99s based against is what is needed. Thanks. -M > I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a. > > FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4 > 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT > 2018 > shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal: +1 443-546-8752 > Tor+XMPP+OTR: lattera@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > From owner-freebsd-current@freebsd.org Fri Aug 24 22:48: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 81EF610964BF for ; Fri, 24 Aug 2018 22:48:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 289507ADA1; Fri, 24 Aug 2018 22:48:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) 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)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id C4A31A524; Fri, 24 Aug 2018 22:48:03 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8rgnodwguwcl7l2ksvq.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240b:b802:c9f5:de0e:83d2:3536]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 87AB63F80B; Sat, 25 Aug 2018 00:48:00 +0200 (CEST) From: "Kristof Provost" To: "Matthew Macy" Cc: "Shawn Webb" , freebsd-current@freebsd.org Subject: Re: ifnet use after free Date: Sat, 25 Aug 2018 00:47:59 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> In-Reply-To: References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> 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.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 22:48:04 -0000 On 25 Aug 2018, at 0:26, Matthew Macy wrote: > On Fri, Aug 24, 2018 at 15:25 Shawn Webb > wrote: > >> Hey All, >> >> Somewhere in the last month or so, a use after free was introduced. I >> don't have the time right now to bisect the commits and figure out >> which commit introduced the breakage. Attached is the core.txt (which >> seems nonsensical because the dump is reporting on a different >> thread). If the core.txt gets scrubbed, I've posted it here: >> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a >> > > Do you have any guidance on how to reproduce? The hardenedbsd rev > isn’t > useful - the svn commit that it’s based against is what is needed. > For what it’s worth, it’s not a hardenedbsd thing. I’ve been chasing the same one (same offset, same allocation size, same most recent user). Something gets set to zero/NULL. 8 bytes on amd64, so presumably a pointer. I currently only trigger it on a development branch, but I’ll see if I can clean that up into something I can share tomorrow. In my test scenario it happens after shutdown of a vnet jail with a few interfaces in it (including a pfsync interface which will disappear with the jail), and new jails are started. It’s pretty reliable. At a guess something’s wrong with the delayed cleanup of ifnets and vnet shutdown. Regards, Kristof From owner-freebsd-current@freebsd.org Fri Aug 24 23:07:37 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 14DFB1096DB8; Fri, 24 Aug 2018 23:07:37 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A4997B967; Fri, 24 Aug 2018 23:07:36 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x230.google.com with SMTP id y12-v6so8393836ioj.13; Fri, 24 Aug 2018 16:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Q+cZBmamAqw2iXZXTEVQQt7zvDkozLQHEc3H/sgujo=; b=A+BukvShRLJs3dvh1hLPLEITXMk0KQJ4TA91LTMlyl4By3Q0rxglQ0lgKV6WJsMCY5 s5H1D+ZnBarY9regso4fkq15X7WqcX+yFSr91YyodbeEkjt3iOZWZrHKS5D/z6OieNBb xE7kdWoQoEUUlvzqimXNCRdTeUOdBPNg0excAt3wKD1Tn20yGknUIQkW1IMKHJmnlzMy L7vifjaAkDBVFERjd2kJ7DKUBIj645K+pCsoAGYA64aKPtGeyIV9KhegJmcI1RBm0Jm5 HyYyVUz45jTy3z+pVrXqc3JRb1SyOmV3wMBW7ZRQrreFwM/Z+BKB9vWVWGriBCws3QLg SZJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1Q+cZBmamAqw2iXZXTEVQQt7zvDkozLQHEc3H/sgujo=; b=Lb1rX3SbkQ8TK2FkCPICog2C8jU18gVl1zDQHfG1Z3hWEROWfGnq+ZD4/dC3e9/Bol trJPe9sU1oFurZDto+QuqdSbZolYYiQNcgAtEIk/5h4Hs6NWN5XKliAUtHJWH6Jzzokh M6SL6Fqk2geronyGrvD+y2ipOevFmFqSGuUOwuTY1fzeO8EFpOYKgisgWVOwJNxYxJxb rLddbyeoFLM+J2iMjrz2Djut3LP6kiF7cayqaqBkkw8oWYbMNdohThO44a9pvI+rs3V5 CYvXhnspuHBWIlrqnb7qPt0YE2H0xWh3665+ZdOcNxPGwtsZn+yOYHK1GRy68N8slfmL Xlpg== X-Gm-Message-State: APzg51AjFC/9pXMCRy1uMpN33wbrXCIw8u5OTWnt173VtKaOY23/WkZb 6/TddITT3pqcxrp1uCCMnITromjhB2ke98YqrL8= X-Google-Smtp-Source: ANB0VdaOKLtvJS6FVDBBeIdQpZAWgt/7gLzxm9fp89XX6QGyE6Fc1/S61QTcywTe9Cv8bS2OG7KaMWFBf2cKKtEdklU= X-Received: by 2002:a5e:890c:: with SMTP id k12-v6mr2780762ioj.136.1535152055929; Fri, 24 Aug 2018 16:07:35 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 07:07:24 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Warner Losh Cc: mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:07:37 -0000 On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > > Just in case anyone misses the change to UPDATING: > > > > > > > > 20180821: > > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > > hardware, > > > > or with GPUs predating Radeon and i915 will need to install > the > > > > graphics/drm-legacy-kmod. All other users should be able to > use > > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > > Note that this applies only to 12. > > > > > > I see that The removal of drm and drm2 has been reverted on svn. Coul= d > > > you please kindly share the reasons behind the re-inclusion? > > > > > > > > > I can=E2=80=99t really give the blow by blow of internal project drama,= but the > > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet = actually > documented > > anywhere that I=E2=80=99ve seen) were not followed with regards to the > deprecation > > process. Warner and others believe that we can address the objectives o= f > > the drm removal (improving the user experience and communicating that > > drm/drm2 are _completely_ unsupported apart from continuing to compile) > > through less disruptive means. > > > > Just so. > > Our only continued frustration is that we were never given any guidance b= y > > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion= was taking place > in > > May and then those groups behaved as if this were a surprise when the > > removal happened. I=E2=80=99m cautiously optimistic that this well expe= dite > > improving communications on those matters. > > > > All the problems that are exposed by this aren't technical. This one is > social, but no less important. > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > I've been watching this debacle for quite some time now and I'd just like to ask why the rush? The graphics team is working very hard to destroy the stability of FreeBSD just so that they can force their uncooked work down users throats. The Linuxkpi is unstable at best, alpha level software that's constantly in need of someone to go and fix something on FreeBSD because Linux devs decided to make some changes or implement a new feature. This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. Are these guys insane and please avoid the nonsense about you're doing this in your spare time. If you cannot devote the resources to do something right then don't do it at all. Keep that stuff in to yourself or anyone crazy enough to follow those steps to get it up and running, you guys cannot expect to contaminate the entire FreeBSD project for this mess. This is nonsense and I hope that more people who see it as such would say so and stop having these guys forcing this crap; it's maintenance hell who will maintain it if they decide to leave? Best, Owen From owner-freebsd-current@freebsd.org Fri Aug 24 23:29: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 9104310974BD for ; Fri, 24 Aug 2018 23:29:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 190D67C38F for ; Fri, 24 Aug 2018 23:29:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id h20-v6so3962548itf.2 for ; Fri, 24 Aug 2018 16:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rba+CjQ4mO/qnBzTXzdmn9nKH/F6duENeyCKI1Lt35I=; b=vB1tTdEfpF9faIhgAP29tu7/7WrtaSNE9WmEto1vSL1GYGGC+KABSu2rAKWBEsrysX Mn4/UE8h0eWkGvU4aSHOxwdJ/ocpPKZ86NypRjwidpWj6Czt6cUKST6C83KZ0GCOKruh +p3YUMtBxYXkb09GdvZDVpGosWDyCAg2W2zWVX4/7SpqLlWjhXwVbwP+IGGxyMY2dt/R 3FaUWSf8W1oN7kEIKRpgJUugYwMoscbD2aOQNUT0IN2uF7ze8fh1/DUF6QzSt3aKlrW4 gtyhQPFed1mO6T5iriFJR3C2/lQDcQ5rmfXwgMuLuYUidSOyUOOe6cxLXVRA73BwtLse 3klw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rba+CjQ4mO/qnBzTXzdmn9nKH/F6duENeyCKI1Lt35I=; b=XLk6SSTRxn0BQdrvxsuc+v+TIr3b7srAcslxR+LhxUbfwP4Xnc6z4J8KNHgQhmZgF/ yA2G4T7mWDuH/CDKamWyqSvC9eT6i3+UME4xHW89fx4W2fYc0P23//ZwyjCwZL4DZbCv +Suzkb0aemvQcrrK4wq1fKewWjiwopnrUJPfJPu7qC/KLOF4yEbnaiXv4d+Awk2FZ+Dr QBGHDgpHIek5M4xLNNF5QUJE6BOF70p4RDBATJ6YNI9P9BbHaap42/+hEK1MfWiDJlcj L1SS81U1AnA3aOM/Hnba54K1hUg09ZoJGBimW8Lnkl/VCMWonxw4ghk5vwHLXfhnnego Vldw== X-Gm-Message-State: APzg51D9YSGoJLSunCl6YrEOMs2Co2fQK2C64MrOELs2NUByw6QP4m7Y tRpqw/vbd53A4JRHC42Fvq7FG97Q3hr2XXOYw7Y0GA== X-Google-Smtp-Source: ANB0VdbIA85qDomXF16CGYd16M19X5qMOhJzhmTO41ohbMjNDcK7HB71bAxCKGDFYmbEwM3lj24nZxXDtEGSiW/NgF0= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr2882932ite.39.1535153371005; Fri, 24 Aug 2018 16:29:31 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 17:29:19 -0600 Message-ID: Subject: Re: priority of paths to kernel modules? To: Niclas Zeising Cc: "Rodney W. Grimes" , Kyle Evans , Johannes Lundberg , Matt Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:29:32 -0000 On Fri, Aug 24, 2018 at 4:20 PM Niclas Zeising wrote: > On 08/24/18 17:20, Warner Losh wrote: > > This would allow the graphics port to have a rc script that sets > > this up so when X11 goes to automatically load the module, the right one > > gets loaded. > > > > I just want to point out that X11 doesn't load the graphics kernel > driver by default when using the drm-*-kmod ports, and I'm not sure the > hack to have the intel ddx (xf86-video-intel) load the drm2 driver is > still around. > > It doesn't really matter though, since upstream is moving away from > having X load the driver, and I'd like us to follow suit by using > devmatch (this is one of the reasons we wanted to get rid of the base > drivers, as I've stated before). X can't always know which driver to > load (when using modesetting for instance), and in my opinion, it should > be the kernel/loader that decides which drivers to load. Excellent. That reduces the compatibility matrix I need to consider. I have some ideas, and will hack on them to see if a clever bit of slide of hand will solve the main problem of loading the wrong driver in a dependency chain. Warner From owner-freebsd-current@freebsd.org Fri Aug 24 23:40: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 94C02109781D for ; Fri, 24 Aug 2018 23:40:00 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 21C407C809 for ; Fri, 24 Aug 2018 23:40:00 +0000 (UTC) (envelope-from kris@ixsystems.com) Received: by mail-yw1-xc2a.google.com with SMTP id z143-v6so3690311ywa.7 for ; Fri, 24 Aug 2018 16:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/LrRmnwvXnDRFAHtFcGs7jR/86+Bistp1Eb7NdEygQI=; b=tesPiaWmUw6/z5MIrARTJ+iXsBBbymNtOhCkcpxaTZLZcmGbJ6Ij2dlasKpiT/ZzlG iAbCUgvGUpHqQHiMdBvdKwbol9MX93vYPKk574aqB9htW8OM88UoL/rDB/LSmnqXb/Xc DDC0eJbpetTVD2xRttopBbpaBenbn++7NRVMw+yp3GcdKehx46oIqUQgrsLdhzpsct8j wAAQTnzpnxe7arWYn5GSC2HTlOnHQjtUQr3fzvq7YoY8MOtYls3C32/AnaUDR75UQLqA I5O2XA8ax6TX36xJHKW59++Mu9NihWOKQC2C1YdoGmjvUqLBaqa6E9kuMmS3RJncRjPV HiMw== 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-transfer-encoding:content-language; bh=/LrRmnwvXnDRFAHtFcGs7jR/86+Bistp1Eb7NdEygQI=; b=n6eLlZMPbegZMthXg4S02tIGwoRqcl/l+La7xmUgNSJqr3DbWGEKQfVsbHt9uSpY2O j8JXMfrB1+GH0sipwSHPOYqfGtb2EUd6Rnb60UzHACCf234XzfePB41RmSaO1S57wd+f HtMosul+mgYmIQnqcDsW44EjMYS3rGNgh5PlFvhH+0w2ZjToFZPy6gLXg8kCKvvrzWyl edyowqhO+tAJdxltdRAkpzkLjSa/UWxYZruwP7jxQ+eI4DQsb8KqfeoYsDlx2vRB6ZBQ XQtxZfmcvauRNHbwciSctd1gl7yCbiZJq+/4X9+w6kVyli03dI1qbSgnO0ERgPP+R8+t 4GYg== X-Gm-Message-State: APzg51CbYft/WXckf5tIvTkBXeD4uwMqj+SlPVP9alopf2YlEj1hv9wj IY+SrK2hPGgTPZmgOSqsgsoVTfx7lLZejzldtMSKD311hctKoTBZpfFKWgH6si/LX325xqxDKEa +ORU9S9LfwqVg1WQVY5aQq4lMiPwJuX1YQuHFrzZygQeWFJJL7WBGWFWLSZEHdqT5CarlDPnmqw == X-Google-Smtp-Source: ANB0VdbTphN3BlznUdepU+Bjeey0htfC3/2xB6mdKV0xlWvSvA8hGjTVAnb+EytiLrt3TLk+cZgxug== X-Received: by 2002:a81:4418:: with SMTP id r24-v6mr2266353ywa.427.1535153999091; Fri, 24 Aug 2018 16:39:59 -0700 (PDT) Received: from [192.168.0.189] (75-130-56-30.static.kgpt.tn.charter.com. [75.130.56.30]) by smtp.gmail.com with ESMTPSA id n187-v6sm8521599ywn.76.2018.08.24.16.39.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 16:39:58 -0700 (PDT) Subject: Re: drm / drm2 removal in 12 To: freebsd-current@freebsd.org References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Kris Moore Openpgp: preference=signencrypt Autocrypt: addr=kris@ixsystems.com; prefer-encrypt=mutual; keydata= xsBNBE5nfNMBCADxo/scoVqCZbXXeJTFET/xl/TWfjP5HtlP65F2LLzmjCcGz8/6B7lyCYDp yMawhEael7QPRBt/PCbc6fKspq3Rei+3IniPKkxfxfpUtsr1AIA6iMntzRWTa0DrW2C1NpDH 8MU5VXu91dNKE86umFZYqO54GUGmCEM06q0ZMCPBooUgQchNs8YztiEJzg6GokYQm4/3EHRJ ddQcyB7jupZYSNG49Hqm84QDeGBuXKJDcn7a6dn5ZvStFQO523Clv+83qYLdnaMPsQVAyj+w ifcC28jyGegvxK2gz5j2zcqmlK//3UEKiTwqoxsQM0McbE4PsVotpBDR5rSiydvRlimRABEB AAHNKUtyaXMgTW9vcmUgKG5vIHBhc3N3b3JkKSA8a3Jpc0BwY2JzZC5vcmc+wsB4BBMBAgAi AhsjBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVHM5MAAKCRB/3CIMMFd81zyiB/9rKgfK 9i4pwSB6qYPkrNOavRqu3cLDL4H86k9PUBWeGWDtHYVqu6yhSxz3rUSyipNltmxl2IardlQl AJj2YCe+lrdRMejW4DpPhc8Yx1/OBcYlZ31SE98ns9tqrQVPNg7/rGazO/4osW8bwYvI61w2 W82fS7UzDb9++Qg2prsXo1YA5pKxCM52NX7UwkhREvBjDBlW2R3CubAyVcKqDXVb6ILCisFA mx0s78NucK6nbuHCfot31IIpD5wdnyY2qkLsLeFPnMpkrC8XpAh5mRkrlBw862vGjT2/GVR6 LwCGnHZNLawPcU53H1U3Nq50dDayhwk0ZCYuqSVC/rOQVaRezsBNBE5nfNMBCADD6cD19M4r W5hUuGnmrKhNH0d5j0xSUjQS0jM2Y7c52jra+qEYUstPr1oJX5IPG5fvi0ItIpQ1kU9O9GbA oLlL0rP16HmrWV+lzDK71L3m3jZg35pvXrhBjdygR5jozd8FpMH5FNCRtjjn7iiQQWv2u82A udJunI8xdB+HPtg0l/HdhWX5cf2Av/96G1zbA+r5bW6+k7pUM/XCMVYozRrScW7paK6PSkg5 XL3OdtA/PBUg0RoEdomeJlKU87Phs0qIJw6pG/Ng8ThoLLhtqFGCsPnj+UqBklzGQaC3kPeg dEHsf/xeiFdWo/AyKc9R6R4a1Kr0N8lQxCJBzvVz9BDrABEBAAHCwF8EGAECAAkCGwwFAlRz OTAACgkQf9wiDDBXfNf0SQf/bsIeG9s+lIC1muXPTjfZH5k1U1V0pFI2i4jjBOL+OfgqTpNx XeIs2NclW1A/xBRt9YuoTQJRZMOXZBxeMCEm1n5MLRj+zxCJmUWnQvEBE6gC/cadB7efqc70 /UVjmgyxKZTJzmUuJ2ZKbe/LekfZuzSQ83lX1pVT/gfCe2zJBfZwoNoNQ8lDBwT/fdleChLe qVlArrhxYtTdQCAfG4M3Uxs6OWQK3OQJO15aNjybQl514xLnQrLmLMD95zIuckGbGlSEJ+HO 0BZYPdcT3C1sIRnhxifbEd4wose9ydOsxxdVZr3mYarTjPlAVxAsX4nP2+K75ymFi/YH+ARE dxQWXA== Message-ID: Date: Fri, 24 Aug 2018 19:39:56 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:40:00 -0000 On 8/24/18 7:07 PM, blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >> >>> On Fri, Aug 24, 2018 at 14:53 Ali wrote: >>> >>>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >>>>> Just in case anyone misses the change to UPDATING: >>>>> >>>>> 20180821: >>>>> drm and drm2 have been removed. Users on powerpc, 32-bit >>>> hardware, >>>>> or with GPUs predating Radeon and i915 will need to install >> the >>>>> graphics/drm-legacy-kmod. All other users should be able to >> use >>>>> one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >>>>> graphics/drm-next-kmod, graphics/drm-devel-kmod. >>>>> Note that this applies only to 12. >>>> I see that The removal of drm and drm2 has been reverted on svn. Could >>>> you please kindly share the reasons behind the re-inclusion? >>>> >>> >>> I can’t really give the blow by blow of internal project drama, but the >>> gist of it is that “best practices” (which are not yet actually >> documented >>> anywhere that I’ve seen) were not followed with regards to the >> deprecation >>> process. Warner and others believe that we can address the objectives of >>> the drm removal (improving the user experience and communicating that >>> drm/drm2 are _completely_ unsupported apart from continuing to compile) >>> through less disruptive means. >>> >> Just so. >> >> Our only continued frustration is that we were never given any guidance by >>> RE or core on said “best practices” when the discussion was taking place >> in >>> May and then those groups behaved as if this were a surprise when the >>> removal happened. I’m cautiously optimistic that this well expedite >>> improving communications on those matters. >>> >> All the problems that are exposed by this aren't technical. This one is >> social, but no less important. >> >> Warner >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > I've been watching this debacle for quite some time now and I'd just like > to ask why the rush? > > The graphics team is working very hard to destroy the stability of FreeBSD > just so that they can force their uncooked work down users throats. > > The Linuxkpi is unstable at best, alpha level software that's constantly in > need of someone to go and fix something on FreeBSD because Linux devs > decided to make some changes or implement a new feature. > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > > - Move DRM headers to a similar location as Linux > - > > Use kmalloc() instead of malloc(9) > - Use kref > - > > Use idr and get rid of drm_gem_names.c > - Use PCI API > - Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go do > that on Linux. > > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. > > If you cannot devote the resources to do something right then don't do it > at all. > > Keep that stuff in to yourself or anyone crazy enough to follow those steps > to get it up and running, you guys cannot expect to contaminate the entire > FreeBSD project for this mess. > > This is nonsense and I hope that more people who see it as such would say > so and stop having these guys forcing this crap; it's maintenance hell who > will maintain it if they decide to leave? > > Best, > Owen > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I've been personally using the new DRM bits since almost day one. I haven't found it to be unstable in the slightest. Compared to not having it and being forced to run 5+ year old hardware, it's been a huge blessing for those of us who care about running FreeBSD as a modern desktop / laptop. FreeBSD being an open source project, you are welcome to contribute back your work anytime. But since I don't imagine we'll see that patch coming anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop running awesomeness. (Written from my brand new Lenovo P71 which worked flawlessly out of box) -- Kris Moore Vice President of Engineering iXsystems Enterprise Storage & Servers Driven By Open Source From owner-freebsd-current@freebsd.org Fri Aug 24 23:55: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 7CF631097F4C for ; Fri, 24 Aug 2018 23:55:32 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12B527D1DA for ; Fri, 24 Aug 2018 23:55:31 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x241.google.com with SMTP id 139-v6so4023776itf.0 for ; Fri, 24 Aug 2018 16:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R5Jk89x23lEFltr7M7J+V4rVH9MwPPwfwQ4J/A0I2eA=; b=ZiMrjUMxHAVYcLEe4MpLrudJcOhcB/o311HpQr1/kHoIXEE/C99Y2Q3h+0XBhJUmKh 60Px8pVgfDzwfFp5hLWqDRkF+QQek47oFy51wD887w/NPlj6UMGDFSyg+FXgYvawpl9g mPKr6rTJfizbDsXPimwZ7NmL/bEImqGdzhcfpVR6/sa7g5/9lFFLSLWqJO5MM0QvAkyA g2X9nOv6zkyoNZWzfg/Q2e83JovSMm7JLellK2IOGfza15Sz1rVroxWDUjTildXG0oQL CfUcpop5AXNQqFkx1eLagYybsw5HlFputX1I7CkzheCcdyHKwzjT5XB/Uww36Dh52Fhk TRdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R5Jk89x23lEFltr7M7J+V4rVH9MwPPwfwQ4J/A0I2eA=; b=cKRSXLp1zF6Nft5apofTgnb1rYxeN27D+WMTtD7DrgZQvKltYq2yTWVC5j+BcnHLdi XWqXElELczbmkcre7wkbo1QFSkTwbaFACtFKjU2iBDq0xcUp6siZZ1oRgbEPxOLIw3AT IGYi0tnQQIQXJVZfEJyGd4QR44T8s/S7lIuaqSMBrvzjxywrudMA75t2TtWGHIKiB3hu fyhTGULGGBITwsRmVuE5XgN405/TX6gyNXUr6HvC2uO4JsMdRLY+QTaaOuGDy6K5jsAt gldtf6Lk60puzugKnCcwnnee1zDEHQzHYdbljBWrvpt9LdxADW2lqb6ZeHt4m8miYL5T X32Q== X-Gm-Message-State: APzg51BMnqBfGS3rQqxxNBOxbS84X8HIbvb863tIp2pCxx8fN1Er3t7p +9n+2AuHIDcNi2NqrxGPcNBx6oqkVXiPaWrZFveOKgsbYYY= X-Google-Smtp-Source: ANB0VdZgcdFKHM7TstGjickq/6Kq5/H1SReduR/s2P7GkqxCIbHq+LXPtPA0r9bpaMVik1TBss4LLiS6XC2NUzzmZlA= X-Received: by 2002:a02:1643:: with SMTP id a64-v6mr3003688jaa.133.1535154931122; Fri, 24 Aug 2018 16:55:31 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 07:55:19 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: kris@ixsystems.com Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 23:55:32 -0000 On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > On 8/24/18 7:07 PM, blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > > > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote= : > >> > >>> On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >>> > >>>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > >>>>> Just in case anyone misses the change to UPDATING: > >>>>> > >>>>> 20180821: > >>>>> drm and drm2 have been removed. Users on powerpc, 32-bit > >>>> hardware, > >>>>> or with GPUs predating Radeon and i915 will need to install > >> the > >>>>> graphics/drm-legacy-kmod. All other users should be able to > >> use > >>>>> one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > >>>>> graphics/drm-next-kmod, graphics/drm-devel-kmod. > >>>>> Note that this applies only to 12. > >>>> I see that The removal of drm and drm2 has been reverted on svn. Cou= ld > >>>> you please kindly share the reasons behind the re-inclusion? > >>>> > >>> > >>> I can=E2=80=99t really give the blow by blow of internal project dram= a, but the > >>> gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not ye= t actually > >> documented > >>> anywhere that I=E2=80=99ve seen) were not followed with regards to th= e > >> deprecation > >>> process. Warner and others believe that we can address the objectives > of > >>> the drm removal (improving the user experience and communicating that > >>> drm/drm2 are _completely_ unsupported apart from continuing to compil= e) > >>> through less disruptive means. > >>> > >> Just so. > >> > >> Our only continued frustration is that we were never given any guidanc= e > by > >>> RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussi= on was taking > place > >> in > >>> May and then those groups behaved as if this were a surprise when the > >>> removal happened. I=E2=80=99m cautiously optimistic that this well ex= pedite > >>> improving communications on those matters. > >>> > >> All the problems that are exposed by this aren't technical. This one i= s > >> social, but no less important. > >> > >> Warner > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > >> > > I've been watching this debacle for quite some time now and I'd just li= ke > > to ask why the rush? > > > > The graphics team is working very hard to destroy the stability of > FreeBSD > > just so that they can force their uncooked work down users throats. > > > > The Linuxkpi is unstable at best, alpha level software that's constantl= y > in > > need of someone to go and fix something on FreeBSD because Linux devs > > decided to make some changes or implement a new feature. > > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > > - Move DRM headers to a similar location as Linux > > - > > > > Use kmalloc() instead of malloc(9) > > - Use kref > > - > > > > Use idr and get rid of drm_gem_names.c > > - Use PCI API > > - Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > > > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > > > If you cannot devote the resources to do something right then don't do = it > > at all. > > > > Keep that stuff in to yourself or anyone crazy enough to follow those > steps > > to get it up and running, you guys cannot expect to contaminate the > entire > > FreeBSD project for this mess. > > > > This is nonsense and I hope that more people who see it as such would s= ay > > so and stop having these guys forcing this crap; it's maintenance hell > who > > will maintain it if they decide to leave? > > > > Best, > > Owen > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > I've been personally using the new DRM bits since almost day one. I > haven't found it to be unstable in the slightest. Compared to not having > it and being forced to run 5+ year old hardware, it's been a huge > blessing for those of us who care about running FreeBSD as a modern > desktop / laptop. > > FreeBSD being an open source project, you are welcome to contribute back > your work anytime. But since I don't imagine we'll see that patch coming > anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop > running awesomeness. > > (Written from my brand new Lenovo P71 which worked flawlessly out of box) > > > -- > Kris Moore > Vice President of Engineering > iXsystems > Enterprise Storage & Servers Driven By Open Source > > _______________________________________________ > 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= " > Please tell me more about you're modern hardware, Kris Vice President of Engineering at iXsystems. Try asking a person who doesn't run server infrastructure software and hardware to get that stuff up and running, would you? ----- pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x6a011558 chip=3D0x19108086 rev= =3D0x07 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x6a011558 chip=3D0x19018086 rev= =3D0x07 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16)' class =3D bridge subclass =3D PCI-PCI xhci0@pci0:0:20:0: class=3D0x0c0330 card=3D0x6a011558 chip=3D0xa12f8086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H USB 3.0 xHCI Controller' class =3D serial bus subclass =3D USB none0@pci0:0:22:0: class=3D0x078000 card=3D0x6a011558 chip=3D0xa13a8086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H CSME HECI' class =3D simple comms ahci0@pci0:0:23:0: class=3D0x010601 card=3D0x6a011558 chip=3D0xa1038086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H SATA Controller [AHCI mode]' class =3D mass storage subclass =3D SATA pcib2@pci0:0:28:0: class=3D0x060400 card=3D0x6a011558 chip=3D0xa1108086 rev= =3D0xf1 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:28:4: class=3D0x060400 card=3D0x6a011558 chip=3D0xa1148086 rev= =3D0xf1 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:28:6: class=3D0x060400 card=3D0x6a011558 chip=3D0xa1168086 rev= =3D0xf1 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:29:0: class=3D0x060400 card=3D0x6a011558 chip=3D0xa1188086 rev= =3D0xf1 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x6a011558 chip=3D0xa14e8086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H LPC Controller' class =3D bridge subclass =3D PCI-ISA none1@pci0:0:31:2: class=3D0x058000 card=3D0x6a011558 chip=3D0xa1218086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H PMC' class =3D memory hdac0@pci0:0:31:3: class=3D0x040300 card=3D0x6a021558 chip=3D0xa1708086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H HD Audio' class =3D multimedia subclass =3D HDA none2@pci0:0:31:4: class=3D0x0c0500 card=3D0x6a011558 chip=3D0xa1238086 rev= =3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Sunrise Point-H SMBus' class =3D serial bus subclass =3D SMBus vgapci0@pci0:1:0:0: class=3D0x030000 card=3D0x6a021558 chip=3D0x1ba110de re= v=3D0xa1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'GP104M [GeForce GTX 1070 Mobile]' class =3D display subclass =3D VGA none3@pci0:109:0:0: class=3D0xff0000 card=3D0x6a011558 chip=3D0x528710ec re= v=3D0x01 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8411B PCI Express Card Reader' re0@pci0:109:0:1: class=3D0x020000 card=3D0x6a011558 chip=3D0x816810ec rev= =3D0x12 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet iwm0@pci0:110:0:0: class=3D0x028000 card=3D0x50108086 chip=3D0x095a8086 rev= =3D0x48 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Wireless 7265' class =3D network nvme0@pci0:111:0:0: class=3D0x010802 card=3D0x390a8086 chip=3D0xf1a58086 re= v=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D mass storage subclass =3D NVM From owner-freebsd-current@freebsd.org Sat Aug 25 00:40:03 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 046F71098DCF; Sat, 25 Aug 2018 00:40:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A9B77E31D; Sat, 25 Aug 2018 00:40:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.203] (cpe-76-175-75-27.socal.res.rr.com [76.175.75.27]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id e5d9fd9d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 24 Aug 2018 17:39:59 -0700 (PDT) Subject: Re: drm / drm2 removal in 12 To: blubee blubeeme , Warner Losh Cc: mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Pete Wright Message-ID: Date: Fri, 24 Aug 2018 17:39:55 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 00:40:03 -0000 On 8/24/18 4:07 PM, blubee blubeeme wrote: > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > > - Move DRM headers to a similar location as Linux > - > > Use kmalloc() instead of malloc(9) > - Use kref > - > > Use idr and get rid of drm_gem_names.c > - Use PCI API > - Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go do > that on Linux. having a hard time not feeding the troll here...but what specifically is garbage.  as in, what implementation of all this work do you have available that has been developed independently which also enables support for modern desktop and portable systems that you can buy today? > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. speaking as someone who's been working on this from pretty much the day of the initial CFT (maybe before?) - i don't know anyone who's getting paid for this specific work.  at least when it comes to GPU support.  but, if you have the means, I'd love to work on this full time and am open to any serious offers :) -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Aug 25 00:55: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 3A8CB1099670; Sat, 25 Aug 2018 00:55:29 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99A787F21C; Sat, 25 Aug 2018 00:55:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id p129-v6so4113112ite.3; Fri, 24 Aug 2018 17:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K2UfZBhBFmhJy7iqOlPoEy+gUzJxkZA+hsOqUmaruY4=; b=MmHqVS/PKPMc019iIF2wQVrmIa6UaGXtdvoXpOcCHAVFTBHoFQ+4jpUQtd67coh+jy W8KpPsWX5MlE52JzwtdrG9LW3+TeYJRSFqNeONsjCk1zjqIVHIdnPrbCo+z1u0ONxrEL glgzFtCLD+VsEXG5/CfCQeTHh7lK9r+80YjmFaNoICXA3NA/r9Yrq1RsmLS4u+ZSwlP0 ZB8Jx4cW4+qTdSeaWPbXr8JTVWk/YCv3LWmhJoUufEymN7QeoKOck8aiXYMqb5s2Ord9 9qodaV4LkMeNY24wtuLn40kY3LAEvInUvk415KOIhd9sDsOphkkqUR85tBZsL7AMI1Zi yU5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K2UfZBhBFmhJy7iqOlPoEy+gUzJxkZA+hsOqUmaruY4=; b=sfBfP+/CBV6aD+bBsmgmHwOmFe9fuBwgBSsn+gCp2D5noT+rVJ5hyRWH/M7a3TeABz Wto9viia5mR/hDGUxXj2h7EfrHJCB7RxGzOicnOQ3HztZ79WbA4OHpkPa5NJqYs2hC7u kYpO7iz8ouT9gyz5dLmHACiXRPCdMkgENRE4PqfhPOye0ZrWuVPGDrmsSwK9Vw3Y+qvQ J0fB0PZFQXhyggGhk5j3Eh/LUE051F4BBDGjwTJ3Yr+MmwjHXIPLl5Cap/ySn9chJ7vh yfAgH6pUEgiPAT87DxvBxXlNjmIF0oMUnMqhNT26bq38/+WFvzCpdkjGIObF6LYQgwDw H4Rg== X-Gm-Message-State: APzg51Dv+NsVu/x6hhYQ4PAk1GsZU7Fkgfh000LcUTchWNhsRqeV0cD2 aPgDN17AO3SuM5zEkEyMafJ1LvnnGXmuipaFMTY= X-Google-Smtp-Source: ANB0VdZrG/JDEu51+/gVZsF9f1Ej+XON6OL5c4U1eo3Wr/t0mUAEErGnec0ZgyFUeww5OjYj+pby+P7V5dIz6SDm+X8= X-Received: by 2002:a24:7c4a:: with SMTP id a71-v6mr60698itd.69.1535158527617; Fri, 24 Aug 2018 17:55:27 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 08:55:15 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Pete Wright Cc: Warner Losh , mmacy@freebsd.org, Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 00:55:29 -0000 On Sat, Aug 25, 2018 at 8:40 AM Pete Wright wrote: > > > On 8/24/18 4:07 PM, blubee blubeeme wrote: > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > > - Move DRM headers to a similar location as Linux > > - > > > > Use kmalloc() instead of malloc(9) > > - Use kref > > - > > > > Use idr and get rid of drm_gem_names.c > > - Use PCI API > > - Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > having a hard time not feeding the troll here...but what specifically is > garbage. as in, what implementation of all this work do you have > available that has been developed independently which also enables > support for modern desktop and portable systems that you can buy today? > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > The idea that FreeBSD relax it's standards just so that some devs have an easier time bringing up a half baked idea is nonsense. Let's take power management, after you guys do all this work to get the graphics card working how much of devd will you need to implement to get that working properly? I don't understand why this concept seems so hard to grasp but FreeBSD is not Linux why are some people continually trying to turn it into some Frankenstein thing. If you guys consider yourself developers then do what developers do and solve problems with constraints, if you cannot accomplish that stop pushing these breaking changes. None of these kmod guys seems to have put any thought into long term maintenance of this project. Look at the mailing list, every few days there's some breaking changes waiting for patches because something changed in Linux-land... If you can't solve the problem in a maintainable way, you will just create bigger problems for developers down the line. Until you guys have something that's at least as stable as what's available now, keep working on it. Some people take pride in their work and deliver a working product, they don't need to twist peoples arms into getting their way. speaking as someone who's been working on this from pretty much the day > of the initial CFT (maybe before?) - i don't know anyone who's getting > paid for this specific work. at least when it comes to GPU support. > but, if you have the means, I'd love to work on this full time and am > open to any serious offers :) > > -pete > I'd hope you have something more compelling than [http://nomadlogic.org] as your calling card. -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Aug 25 02:04:28 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 8382A109C3E1; Sat, 25 Aug 2018 02:04:28 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32AC181C88; Sat, 25 Aug 2018 02:04:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 4FE2F13B37; Sat, 25 Aug 2018 02:04:27 +0000 (UTC) Date: Sat, 25 Aug 2018 02:04:25 +0000 From: Mark Linimon To: blubee blubeeme Cc: Warner Losh , mmacy@freebsd.org, aliovx@gmail.com, FreeBSD current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 Message-ID: <20180825020424.GA16497@lonesome.com> References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 02:04:28 -0000 On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. Let us know how whatever OS you wind up using instead works for you. I suggest you look for one that will put up with your constant harangues. There are very few people on the mailing lists as nasty and rude as yourself. It is tiresome, demotivating, and childish. Please go elsewhere. mcl From owner-freebsd-current@freebsd.org Sat Aug 25 07:07:21 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 1B4AF1080279 for ; Sat, 25 Aug 2018 07:07:21 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D14A8C1C2 for ; Sat, 25 Aug 2018 07:07:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([2.247.16.44]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYtId-1gOert2JDH-00VkCQ for ; Sat, 25 Aug 2018 09:07:10 +0200 Date: Sat, 25 Aug 2018 09:06:37 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: [CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA Message-ID: <20180825090704.69e17a6e@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:eoAfY89bArfTXREUSSLbKukjyHuMm9n6Rd1BNQVNpBmvmzkRFUa HEoE6+S5jto60WaQpyBF/OTao0f+YlShaRFniQ6gmGMyHUsDrmbZmIDNEG8q0fxCu+yQITZ z3FFGvL5L8LqhKHyLLGD41SKP1yBUX0i2hCgy5/bHZ5DhcigkOVze6P6cNlmAh5CiCvY3V1 YmXqA7FRAEZmCfxlaz3Vw== X-UI-Out-Filterresults: notjunk:1;V01:K0:aK2JNiz6jho=:UfPDE6dxMTD+VFP2c3NiNP EiH8KuvMf0RT0Torgl0xBmlCgqzZACOLoKQ2FDO1qSCvo381Da7s+iDeZwJtrox0TpstU9l3V z8tzQKDUkrpQnQWfj6S72YIQ2YNu+vUzdutdei3nLLTEVZi1OUBnSdQA3wd5OorX9pBL8r6pi f+gSgGGbtNn7t0C8q9OROkzYTM6mLRyFpSPDTsnSz4XjkuBQ1XZ1PCr/IVVNQ8yXmRljkkr12 rHfAmEDwyEVUMeK76c6dsmazvVUCuvK9rlWBqVWuYBFkQ2kOhQy2PTIsvkIO2Gzzi9wg7IXQc 4j2Po7kl5ncM2VkjBCqo6oQ+W+/BdgbCNm7H3nWJuQtYgCsLMOx+N+S1GOFSQnUH4PePtBQoN bsa5riqJO9V0ozcozd4/7zHcPt+BOwHLXPQlfO/PH/Le0aJbay2n1KuKKwKA++E1PhVIEWjef miZt4dtvZFjBXo1TJJGlPdJTT1LQSdJDI8A7MSjRVfN8To9nPe46vgmQssX+m0VDG5DAEeWg1 fiQmqWq8yj/mWUnR5W3am/MWj+JxsusRIrWqQnK527QiysnmUryG+EfgYDLGJ77+ipsYtXt1E N4s9nukLBCVP53BzFEPyP+6zeWyuzM7Hhda6xvv+EqPKm3fKeDl00nUmdIKcjydqxPVHmIuDp nLcAK9vYReDSxHy/9thn9jDC9G71Co7h0HMq4eD75/FzcJHv5r5w1eEUXMS8G0L5i+tDDN8Gx YdaYy+yTa/liKcOXKNxEjM/7jRAPwC583mZvkS5DX1Kh4suL2BvMO0TAfYepc+hzG46vbQUXY msFYT2F X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 07:07:21 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkknbSB1 c2luZyBlemphaWwtYWRtaW4gZnJvbSBwb3J0cyAobW9zdCByZWNlbnQgdHJlZSwgdXAgdG8gZGF0 ZSBhcyBvZiB0b2RheSwgYXQgUmV2aXNpb246DQo0NzgwMDEsIEZyZWVCU0QgaXMgRnJlZUJTRCAx Mi4wLUFMUEhBMyAjNDU1IHIzMzgzMDk6IFNhdCBBdWcgMjUgMDc6MTA6NDUgQ0VTVCAyMDE4IGFt ZDY0LA0KdGhlIGphaWxzIHNvdXJjZXMgYXJlIGF0IHJldmlzaW9uIDMzODMwOSkuDQoNClVwZGF0 ZXMgb2YgdGhlIGphaWwncyBiYXNlIGlzIHRha2VuIGZyb20gL3Vzci9zcmMgb3IgYW5vdGhlciBw YXRoIChpbiBjYXNlIG9mIGFub3RoZXINCnBhdGgsIGV6amFpbC1hZG1pbiB1cGRhdGUgLWkgcmVx dWlyZXMgdGhlIHNldHRpbmcgb2YgZXZuIE1BS0VPQkpESVJQUkVGSVg9IHNvbWUvcGxhY2UpLg0K DQpVcGRhdGluZyBqYWlscyBhbmQgY3JlYXRpbmcgbmV3IGphaWxzIGhhcyB3b3JrZWQgZm9yIGEg d2hpbGUsIGJ1dCByZWNlbnRseSwgbmV3bHkgY3JlYXRlZA0KamFpbHMgZmFpbCB0byBzdGFydCBi ZWNhdXNlIHRoZSBpbml0aWFsIHN0YXJ0IHJvdXRpbmUgYnJpbmdpbmcgdXAgdGhlIGphaWwgZHVt cHMgYW4gZXJyb3INCmFib3V0IC9iaW4vc2ggL2V0Yy9yYyBtaXNzaW5nIQ0KDQpJbnZlc3RpZ2F0 aW5nIGEgY29tcGxldGUgZnJlc2ggZXphamlsIHNldHVwIChvbiBaRlMpIHJldmVhbHMsIHRoYXQg bmVpdGhlciBpbiBmdWxsamFpbCwNCm5ld2phaWwgb3IgYmFzZWphaWwgYW55IG9mIHRoZSBpbml0 aWFsIHJjLXNyY2lwdHMgcmMgb3IgcmMuc3ViciBpcyBwcmVzZW50IGFueSBtb3JlISBJDQpzdG9w cGVkIGxvb2tpbmcgZm9yIG90aGVyIG1pc3Npbmcgc2NyaXB0cyBzaW5jZSByYyBhbmQgcmMuc3Vi ciBhcmUgY3J1Y2lhbCBhbmQgZXNzZW50aWFsDQp0byB0aGUgc3lzdGVtLCBzbyBJIGd1ZXNzIHRo ZXJlIGhhcyBiZWVuIGludHJvZHVjZWQgYSBzb3J0IG9mIGJ1ZyByZWNlbnRseSBpbiB0aGUgd2F5 DQpGcmVlQlNEIDEyIGlzIGdvaW5nIHRvIGhhbmRsZS9rZWVwL3N0b3JlIHJjIHNjcmlwdHMgaW4g dGhlIHNvdXJjZSB0cmVlIG9yIHRoZWlyDQppbnN0YWxsYXRpb24gYW5kIGV6amFpIGRpZG4ndCBj YXRjaCB1cCBzbyBmYXIuDQoNCkkgYWxyZWFkeSBmaWxlZCBhIFBSIChzZWUgQnVnIDIzMDgyMiks IGJ1dCBJJ20gdW5zdXJlIHdoZXRoZXIgdGhpcyBpcyBhICJyZWFsIiBidWcgb3IgSQ0KZGlkIGp1 c3QgbWlzcyBzb21lIGltcG9ydGFudCBjaGFuZ2VzIGFuZCBJIGRpZG4ndCBjYXRjaCB1cC4NCg0K VGhhbmtzIGluIGFkdmFuY2UsDQoNCm9oDQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lk ZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9kZXIgw5xiZXJtaXR0bHVuZyBtZWluZXIgRGF0ZW4gZsO8 cg0KV2VyYmV6d2Vja2Ugb2RlciBmw7xyIGRpZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVu ZyAowqcgMjggQWJzLiA0IEJEU0cpLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCg0K aUxVRUFSTUtBQjBXSVFRWlZaTXpBdHdDMlQvODZUclM1MjhmeUZoWWxBVUNXNEVBR0FBS0NSRFM1 MjhmeUZoWQ0KbExWR0FmOTVrRUYyRm5WdHVEczRYWVpzM3FEbHpsRU1Oa050WG9IbkxZTmRJcDBG bXZsNGE4K0d3d3N3UW9nRA0KRGRGY0JiVG9KMkVSK21VMGk5bHVBeEk2ekorcEFmd0x6MjQvQmla Zk1hSkh6OE8wMTVFNTY4dzdVdDFZWjVWZg0KSnlpSExDSm5uYzdCL1NUMGY0OXR4TkdWWHZ4Zkxp UmJyck5pY0hZRnh3L0RpWXREV0xGaw0KPXZhYmINCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0t LQ0K From owner-freebsd-current@freebsd.org Sat Aug 25 07:09:42 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 3C551108035F; Sat, 25 Aug 2018 07:09:42 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF07B8C2E4; Sat, 25 Aug 2018 07:09:41 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id p16-v6so4691141itp.1; Sat, 25 Aug 2018 00:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmAw1c00j+Mc2pGgdP5PC4j+7C2Vb473bBX23LmxzA0=; b=iLryk+y2QYQBjsYlYefYDTxkZ7REVBUDUP8kEx4L12IftriU6GxhQ6I6SedaNyBJUO cCRNHdWKBCYOfr0xjPV0jdH15qEldvesDy1x1AyxN36SyTvfcUktJJTetAV3hBVX8kND LTR/BV/c4p0kyyg8Iy9R6U4KBYXC53D6pa2+Bzsh5pMQgLV0RUcq2UJjkMeUUPsoNY28 b9M/NpofI41euk6sLAtz1m/4WTSaEUABEyNqj539wNyxYr7eFnYKgum7YLNbr7u3kKUV ytceSFvbj/TAr6x0pBp06htCfF/Ku/9jRZPBPxzdVCUbxvtQk9Kath4cT9jspaUuQnvT j9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RmAw1c00j+Mc2pGgdP5PC4j+7C2Vb473bBX23LmxzA0=; b=K2+L13fjZl/BlfxCJavR/fW+I7fREsZu9lDJNkh6om2VLtDgSE8JToO6Clda51qwL2 5a9cIAbZJjihdCXm88hXUShLU6hRWJ3k+DqWxGX51VCbYYtgP//wcy0yB4kr+W4ajyLx ODdaX4syd0V4z2dESgufOcTUN9WB2H4lPa2Q6kt9OPydh8g2hWzUNMaUQKckHaQmZmlR OvadAxYf/rHJA5s2aiTxgXcbhRFTIU9u+aRHWiUxA6DeX4h4wBqbUk3Nv7Idb1cZfQBO DsLH8Mx78z3S+oYCyLzkS2ULPMVDeQIwj4xQ0l+jtGeEgO4xyEkkuBghLdLDJUyK3wqH DxZQ== X-Gm-Message-State: APzg51DxqlXDrnkL10h66ccNMpPtIOxoBcarIiHB7/uYFErqUYuTmy7F MmwPo3gEdbAhbw5yrPElrPBYSgoB/bSKvbLkX1s= X-Google-Smtp-Source: ANB0VdackqLgtoqDvm9wCk7onIWjHnPCvdm0MNLfMyG0RbzGxg3QjNj0/xH3d9XPqMiEoSokXxToW1TI/ZWzzfzc4ok= X-Received: by 2002:a02:1643:: with SMTP id a64-v6mr3774697jaa.133.1535180981050; Sat, 25 Aug 2018 00:09:41 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <20180825020424.GA16497@lonesome.com> In-Reply-To: <20180825020424.GA16497@lonesome.com> From: blubee blubeeme Date: Sat, 25 Aug 2018 15:09:29 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Mark Linimon Cc: Warner Losh , mmacy@freebsd.org, Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 07:09:42 -0000 On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon wrote: > On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > Let us know how whatever OS you wind up using instead works for you. > I suggest you look for one that will put up with your constant harangues. > > There are very few people on the mailing lists as nasty and rude as > yourself. It is tiresome, demotivating, and childish. Please go > elsewhere. > > mcl > Your opinion has been noted but this issue isn't about me. It's about the Graphics devs coding themselves into a corner and looking for an easy button so they can continue to feel good about their toy. There's a reason the changes they tried to force down the FreeBSD source tree was reverted; It does not meet any standards of quality. I have no inside knowledge other than my ability to think clearly and it's obvious that The FreeBSD team wanted to hint at them that their code doesn't pass the sniff test. Instead of being whiny brats improve your code and have it work without breaking compatibility with what has been working for quite a long time. Here's the play by play; You guys push this mess contaminating the FreeBSD source tree, some long standing user tries to update their machines and it blows up; 1) Most will just leave 2) Some will complain 2a) You guys will say; Read UPDATING..... bleh bleh blen They'll get aggravated, thereby aggravating people who came to this platform for Stability. Users who actually use FreeBSD to get things done do not time to trawl these mailing lists, they have real world problems to solve with real world constraints. There are OS with kqueue and all those things it's called Linux; You can go there and play w/ that stuff to your hearts content. If you want your code to get merged, make sure it follows the guidelines and not break the systems for people who are already using the platform. Now, I understand hearing harsh criticism about your work might hurt your feelings and all but here's the antidote; work harder, improve your code, try again when your code quality improves. You guys cannot expect people to accept these kludges in their systems that they run everyday. It's an open source project, you can't get mad because your code isn't accepted, it's your jobs and engineers to do better not expect users to jump through hoops to accommodate your subpar attempts at coding. This isn't about me, it's about the quality of code that you guys are trying to submit. Best, Owen From owner-freebsd-current@freebsd.org Sat Aug 25 08:04:03 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 6423E108187A for ; Sat, 25 Aug 2018 08:04:03 +0000 (UTC) (envelope-from Alexander@leidinger.net) 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 04FE78DCE9 for ; Sat, 25 Aug 2018 08:04:03 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id BDF131081879; Sat, 25 Aug 2018 08:04:02 +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 9C26B1081878 for ; Sat, 25 Aug 2018 08:04:02 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 153028DCE8 for ; Sat, 25 Aug 2018 08:04:01 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sat, 25 Aug 2018 10:03:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1535184232; bh=HgkN3MFAgHRitYSdTczUhCV9URL1Rk7NkeJ0mcTnL00=; h=Date:From:To:Subject; b=YCFY/D3fq40e/ArLKDtHP+c8mjMQVPhvvtj8MQpu2mct0CoXoiXlQdf6GnWcRiv5H vVq2raK50unTou5zmI2bgru905GYnUE8SkHLQKRRKeiblNHLpJ+WluH/z/VKT2ZIbG kjtn6fqo55idC9Dl7smoWRxIPGrws8m7c08GZy9X3J4ZGNpJEaRTFuCIaAUqthxxsT Q9o71PHhc2KCHaSTEQyaGnJGAmao/QFe3YzJg+hoEQY+lD/KL3yg8mIxmpHRu+jZ8F YI0roUr47GF9Mw386O3PiYb0e75qm/AKS43oCNTLcUN19qR6DtHtGy7R8H5ZZI8Upq cu2uoKzxGxAOg== Message-ID: <20180825100321.Horde.mw4vLgtWePKqECPy5D8JAg4@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org Subject: watchdog broken with r338290 User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:04:03 -0000 Hi, I get an immediate reset/reboot of the system with an enabled watchdog on r338290. If I disable it no reset. With r336767 the enabled watchdog doesn't cause an immediate reset. Can someone test? rc.conf: ---snip--- watchdogd_enable="YES" watchdogd_flags="-e /root/bin/wd_check.sh -s 5 -t 60" ---snip--- wd_check.sh: ---snip--- #!/bin/sh exec ls / /space/jails >/dev/null 2>&1 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 E9484108202B; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B2FF8E851; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 528E2DFFA; Sat, 25 Aug 2018 08:27:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-it0-f44.google.com with SMTP id k188-v6so5147361itk.3; Sat, 25 Aug 2018 01:27:27 -0700 (PDT) X-Gm-Message-State: APzg51CEAUjbeJKN2JDmzFhBCf5SsoK04UVDof4BRQ+hjNZjtQ6VmcyB QZoPSnp6bj97yfHQM+vM7zchBzYnBAf3n21moT0= X-Google-Smtp-Source: ANB0VdbzHht3oDJPaowMk2cBWb3pgW3vuyvFzEaDidRZMc0qqGDVBhnjW+tyy0crtiVgtGltdpWcJ+9dTGERRpzXTPI= X-Received: by 2002:a24:704f:: with SMTP id f76-v6mr827257itc.30.1535185646401; Sat, 25 Aug 2018 01:27:26 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: Matthew Macy Date: Sat, 25 Aug 2018 01:27:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: drm / drm2 removal in 12 To: gurenchan@gmail.com Cc: Warner Losh , Ali , freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:27:28 -0000 Hi Owen - I understand that you're enthusiastic and you just want what's best for the project. However, there's a couple of points I hope you'll take to heart. First, please read what you sent and think about the tone and word choice. It's extremely negative and critical - you're actively alienating people on the list. You're not going to be successful engaging any open source community or workplace if you choose to communicate like this. Second, this is a volunteer project. One needs to establish a track record of producing patches and working with developers to get them committed. Regardless of how sound your technical position is - you're going to have a hard time being acknowledged if there is no contribution to match. Best wishes. -M On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme wrote= : > > > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >> >> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >> > >> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > > > Just in case anyone misses the change to UPDATING: >> > > > >> > > > 20180821: >> > > > drm and drm2 have been removed. Users on powerpc, 32-bit >> > > hardware, >> > > > or with GPUs predating Radeon and i915 will need to instal= l >> the >> > > > graphics/drm-legacy-kmod. All other users should be able t= o >> use >> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. >> > > > Note that this applies only to 12. >> > > >> > > I see that The removal of drm and drm2 has been reverted on svn. Cou= ld >> > > you please kindly share the reasons behind the re-inclusion? >> > > >> > >> > >> > I can=E2=80=99t really give the blow by blow of internal project drama= , but the >> > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet= actually >> documented >> > anywhere that I=E2=80=99ve seen) were not followed with regards to the >> deprecation >> > process. Warner and others believe that we can address the objectives = of >> > the drm removal (improving the user experience and communicating that >> > drm/drm2 are _completely_ unsupported apart from continuing to compile= ) >> > through less disruptive means. >> > >> >> Just so. >> >> Our only continued frustration is that we were never given any guidance = by >> > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussio= n was taking >> place in >> > May and then those groups behaved as if this were a surprise when the >> > removal happened. I=E2=80=99m cautiously optimistic that this well exp= edite >> > improving communications on those matters. >> > >> >> All the problems that are exposed by this aren't technical. This one is >> social, but no less important. >> >> Warner >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> > > I've been watching this debacle for quite some time now and I'd just like > to ask why the rush? > > The graphics team is working very hard to destroy the stability of FreeBS= D > just so that they can force their uncooked work down users throats. > > The Linuxkpi is unstable at best, alpha level software that's constantly > in need of someone to go and fix something on FreeBSD because Linux devs > decided to make some changes or implement a new feature. > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > > - Move DRM headers to a similar location as Linux > - > > Use kmalloc() instead of malloc(9) > - Use kref > - > > Use idr and get rid of drm_gem_names.c > - Use PCI API > - Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go d= o > that on Linux. > > Are these guys insane and please avoid the nonsense about you're doing > this in your spare time. > > If you cannot devote the resources to do something right then don't do it > at all. > > Keep that stuff in to yourself or anyone crazy enough to follow those > steps to get it up and running, you guys cannot expect to contaminate the > entire FreeBSD project for this mess. > > This is nonsense and I hope that more people who see it as such would say > so and stop having these guys forcing this crap; it's maintenance hell wh= o > will maintain it if they decide to leave? > > Best, > Owen > > From owner-freebsd-current@freebsd.org Sat Aug 25 08:32: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 24A6810823DE; Sat, 25 Aug 2018 08:32:40 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA90D8ECE8; Sat, 25 Aug 2018 08:32:39 +0000 (UTC) (envelope-from aliovx@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id p84-v6so19288025oic.4; Sat, 25 Aug 2018 01:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPDe6yrEpFGuRtOupOrkHo2OzH7ScBHn884XA0Ie814=; b=X2GfbUupOoF+yJGuf5tY/Q50nrbJ1EyX9YZL+0f1AIAWXkprkwIvNqAmECkR1Mz2Bk zR0JmoF1Y3BffHActCrP1SThImjH/B1DS/XPNBRBr8+IUJYR8GeaZn/lvqKY2P8Oeem5 +HdsK7GpVoT2KAVrR0PgZja8hMXikgGPyEFtMi7/UvJ94AaYSIRXvKj1fvbC/3JE34a0 CEHjyf2HNccBL5I+9JbpJ6RBBkw3XPGjyWeLH8xOFH2FimqZ+UU90ZoUAGpKrB1pTSiA pmKyWIhCbbb3HYSyzWQ7eNnLTfFUjREWsVgXPWAHq0akZMnoM6dGVeIviJBCRAmFVoxM Tb9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPDe6yrEpFGuRtOupOrkHo2OzH7ScBHn884XA0Ie814=; b=guWmVhaIF+h09BoJlf24hxKN3oYBdJZ8Qj3Rb54rgPnB+WcgqSWdS4jL1FE1uCSqD2 j+NTq3BL9wpnsy4SE5JQ2n7VV6WVsTHT0k+sTTOWT+7RhBlxTCBYC6zJ5gpT9yjv9iJv i8vAhoVNaoCEteQykytXMIgsZZq92NiEXnQL8yGIv4alnw+kcYjgE7F8j/b+OQXPXyWq bc8yZmM/Pms/12qrTDUNJ4ACvTBczEoRFTKiSxozdhL4pvyu4TfYsW3+i28aMwvRpsml zsVg1nst3BLjcTYFVWecvPO0EIPIW+YiLDBFW1EU1TI2MSE7OaCnYvp7dy0ajl1mgK65 qjvw== X-Gm-Message-State: APzg51BhgcPs9R5d8pnJbXvaAiJvEVgz3+fGgmPMqZ7mQLyvbvzNtSt3 /cTdVBd+IuVsR1LaHKCu6dW2sPEpdw0DqIENXJ0/sWfh X-Google-Smtp-Source: ANB0VdY3v/zx0lwM3JnCGqlm3n2Ij5OIJwxLmKmJNgj1XRmYb4Tw9gn8ylwuuPMasBDruhBZO7MYmAoPjkfacHqWWcY= X-Received: by 2002:aca:d4cd:: with SMTP id l196-v6mr4664304oig.15.1535185958512; Sat, 25 Aug 2018 01:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:144b:0:0:0:0:0 with HTTP; Sat, 25 Aug 2018 01:32:38 -0700 (PDT) In-Reply-To: References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> From: Ali Abdallah Date: Sat, 25 Aug 2018 10:32:38 +0200 Message-ID: Subject: Re: drm / drm2 removal in 12 To: Matthew Macy Cc: freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:32:40 -0000 Isn't Intel supposed to be working on a native drm driver for FreeBSD? https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from= -2015/ On Sat, Aug 25, 2018 at 12:19 AM, Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >> > Just in case anyone misses the change to UPDATING: >> > >> > 20180821: >> > drm and drm2 have been removed. Users on powerpc, 32-bit >> hardware, >> > or with GPUs predating Radeon and i915 will need to install th= e >> > graphics/drm-legacy-kmod. All other users should be able to us= e >> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >> > graphics/drm-next-kmod, graphics/drm-devel-kmod. >> > Note that this applies only to 12. >> >> I see that The removal of drm and drm2 has been reverted on svn. Could >> you please kindly share the reasons behind the re-inclusion? >> > > > I can=E2=80=99t really give the blow by blow of internal project drama, b= ut the > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not yet ac= tually documented > anywhere that I=E2=80=99ve seen) were not followed with regards to the de= precation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. I am only acting as a lightning rod and > representative of the graphics team and so have done an inadequate job of > tracking their activities with respect to project timelines. As a result = of > this misunderstanding Johannes Lundberg will be sponsored for a bit and > will be able to be involved in internal discussions that impact his work. > > Our only continued frustration is that we were never given any guidance b= y > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussion w= as taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I=E2=80=99m cautiously optimistic that this well expedi= te > improving communications on those matters. > > > Cheers. > -M > From owner-freebsd-current@freebsd.org Sat Aug 25 08:44: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 EC9951082B40; Sat, 25 Aug 2018 08:44:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 779A88F5BA; Sat, 25 Aug 2018 08:44:15 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x230.google.com with SMTP id j81-v6so5181259ite.0; Sat, 25 Aug 2018 01:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gqfb2oSsiSUIEN0b+lYkkEHmpR6w1Po/a32C0ej1fMk=; b=GfuXK/syqbG+/kUc0Wc9OBF9rjpOx1Wf6spyZSkQWeHbfQ6qrRsWb4RX/aBxpaoKkb w+Z7wQJVF848QommWPcBoLaZ572w1Yydq6lsIAuBkMbikVseWudA9l+4eIlIdvpGAqg1 R0yo5vFtexs2/giRwFVGYCBiMmbrZMoodtthtLm3m94BjPL2j8Cbz/rtjwo7lukIRTUO stwdEVIvFgVlRkD4tpqVgZY+5fT+FyVTD+dJz8VPP5NY5v+tQ+Ka+M6f7RWQyJc58ICP 4u/TPehG9SDzPnA7P6qw7ALyga4DotXP7iYFO9Pvfmo5fuQTTa51Ubq2ynBGHvGdfzXu 961A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gqfb2oSsiSUIEN0b+lYkkEHmpR6w1Po/a32C0ej1fMk=; b=saKadzpo1+ns+K9H+DUKssasFJQMTjPmDARZlx9/TxibFilFfM4X+yLiVZRc4ytiX/ sIPJDN816UCMcxRUkrdDrnt2zncvi+wAIZfX7zfQdMz9OjfVvPo1L6K1Ezi7B6mCyGnp 8oVT/2C3GpdnmfBAU8a2/DeDVLass5vySL9tyiOc3Nu6WGwsD/kjGLv2apx3Ao0KgDQY tg0i9BqDltpoSWMURPU/Mjwe/HlBfwnuC6RNB1wh3Tm5C3aP0a8dnT2Uf/vOcLOsLUor dV1a1SGAdsO1Qe0XGRzG1oqzOhT8lijWEkOYpNH+kY8M39OU5vXlZc0uYmeagyNwyKU7 Peew== X-Gm-Message-State: APzg51A6zd+0FkAfU6+h/3iGBjduSoG44/d2rUJYtb4rceWBCTavQRd3 Utk0dbi/awXy1AlVsysy89rqk+LEOTgx/k6FCkUL4PMBZvk= X-Google-Smtp-Source: ANB0Vdb/c27/HAzg3fWD16x8Jgal1VhMutkqcZDPTI55ujkYGv94rQ+RUw5q1pRq8U07tOgwgTRfq0Awj9GLYYhkhu0= X-Received: by 2002:a24:d0d6:: with SMTP id m205-v6mr863089itg.89.1535186654061; Sat, 25 Aug 2018 01:44:14 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> In-Reply-To: From: blubee blubeeme Date: Sat, 25 Aug 2018 16:44:02 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: mmacy@freebsd.org Cc: Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 08:44:16 -0000 On Sat, Aug 25, 2018 at 4:27 PM Matthew Macy wrote: > Hi Owen - > I understand that you're enthusiastic and you just want what's best for > the project. However, there's a couple of points I hope you'll take to > heart. First, please read what you sent and think about the tone and word > choice. It's extremely negative and critical - you're actively alienating > people on the list. You're not going to be successful engaging any open > source community or workplace if you choose to communicate like this. > Second, this is a volunteer project. One needs to establish a track recor= d > of producing patches and working with developers to get them committed. > Regardless of how sound your technical position is - you're going to have= a > hard time being acknowledged if there is no contribution to match. > > Best wishes. > -M > True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. How far will core FreeBSD bend over backwards to accommodate these devs. Their project is half baked at best and sure it works; sorta if the moon is just right. This is the beauty of an open source project, we bring the best to the table, not rip off two legs only to glue them back on later just slightly askew. This isn't a world where everyone gets a gold star, people fail even if they work very hard, failure is still an option. I guess the most important question to ask is what's the standards that the FreeBSD Foundation want to represent, uphold, and maintain? > > > On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme > wrote: > >> >> >> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: >> >>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >>> >>> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >>> > >>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >>> > > > Just in case anyone misses the change to UPDATING: >>> > > > >>> > > > 20180821: >>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit >>> > > hardware, >>> > > > or with GPUs predating Radeon and i915 will need to >>> install the >>> > > > graphics/drm-legacy-kmod. All other users should be able >>> to use >>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod= , >>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. >>> > > > Note that this applies only to 12. >>> > > >>> > > I see that The removal of drm and drm2 has been reverted on svn. >>> Could >>> > > you please kindly share the reasons behind the re-inclusion? >>> > > >>> > >>> > >>> > I can=E2=80=99t really give the blow by blow of internal project dram= a, but the >>> > gist of it is that =E2=80=9Cbest practices=E2=80=9D (which are not ye= t actually >>> documented >>> > anywhere that I=E2=80=99ve seen) were not followed with regards to th= e >>> deprecation >>> > process. Warner and others believe that we can address the objectives >>> of >>> > the drm removal (improving the user experience and communicating that >>> > drm/drm2 are _completely_ unsupported apart from continuing to compil= e) >>> > through less disruptive means. >>> > >>> >>> Just so. >>> >>> Our only continued frustration is that we were never given any guidance >>> by >>> > RE or core on said =E2=80=9Cbest practices=E2=80=9D when the discussi= on was taking >>> place in >>> > May and then those groups behaved as if this were a surprise when the >>> > removal happened. I=E2=80=99m cautiously optimistic that this well ex= pedite >>> > improving communications on those matters. >>> > >>> >>> All the problems that are exposed by this aren't technical. This one is >>> social, but no less important. >>> >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> I've been watching this debacle for quite some time now and I'd just lik= e >> to ask why the rush? >> >> The graphics team is working very hard to destroy the stability of >> FreeBSD just so that they can force their uncooked work down users throa= ts. >> >> The Linuxkpi is unstable at best, alpha level software that's constantly >> in need of someone to go and fix something on FreeBSD because Linux devs >> decided to make some changes or implement a new feature. >> >> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM >> Goals >> >> - Move DRM headers to a similar location as Linux >> - >> >> Use kmalloc() instead of malloc(9) >> - Use kref >> - >> >> Use idr and get rid of drm_gem_names.c >> - Use PCI API >> - Use Linux locking primitives >> >> is garbage, if you want to use develop Linux code and use Linux then go >> do that on Linux. >> >> Are these guys insane and please avoid the nonsense about you're doing >> this in your spare time. >> >> If you cannot devote the resources to do something right then don't do i= t >> at all. >> >> Keep that stuff in to yourself or anyone crazy enough to follow those >> steps to get it up and running, you guys cannot expect to contaminate th= e >> entire FreeBSD project for this mess. >> >> This is nonsense and I hope that more people who see it as such would sa= y >> so and stop having these guys forcing this crap; it's maintenance hell w= ho >> will maintain it if they decide to leave? >> >> Best, >> Owen >> >> > From owner-freebsd-current@freebsd.org Sat Aug 25 09:06: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 099C41083713 for ; Sat, 25 Aug 2018 09:06:33 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from mail.codevoid.de (codevoid.de [176.9.40.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8E17690002 for ; Sat, 25 Aug 2018 09:06:32 +0000 (UTC) (envelope-from sh+freebsd-current@codevoid.de) Received: from localhost (HSI-KBW-109-193-103-113.hsi7.kabel-badenwuerttemberg.de [109.193.103.113]) by mail.codevoid.de (Postfix) with ESMTPSA id 7A8721D59B for ; Sat, 25 Aug 2018 11:06:24 +0200 (CEST) Date: Sat, 25 Aug 2018 11:06:23 +0200 From: Stefan Hagen To: FreeBSD current Subject: Re: drm / drm2 removal in 12 Message-ID: <20180825090623.GA1342@ptrace.hagen.corp> References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: first-class Priority: normal X-Editor: VIM - Vi IMproved 8.1 X-Operating-System: FreeBSD 12.0-ALPHA2 amd64 X-Mailer: Mutt 1.10.1 (2018-07-13) X-PGP-Fingerprint: CBD3 C468 64B4 6517 E8FB B90F B6BC 2EC5 52BE 43BA OpenPGP: id=52BE43BA; =?utf-8?B?dXJsPWh0dHBzOi8v?= =?utf-8?B?Y29kZXZvaWQuZGUvP+KYuj1ncGc7?= preference=sign; X-Jabber: sh@codevoid.de User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 09:06:33 -0000 blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: >> I've been personally using the new DRM bits since almost day one. I >> haven't found it to be unstable in the slightest. Compared to not >> having it and being forced to run 5+ year old hardware, it's been a >> huge blessing for those of us who care about running FreeBSD as a >> modern desktop / laptop. >> >> FreeBSD being an open source project, you are welcome to contribute >> back your work anytime. But since I don't imagine we'll see that >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered, >> Plasma-desktop running awesomeness. >> >> (Written from my brand new Lenovo P71 which worked flawlessly out of >> box) > > Please tell me more about you're modern hardware, Kris Vice President > of Engineering at iXsystems. > > Try asking a person who doesn't run server infrastructure software and > hardware to get that stuff up and running, would you? Do you want to ask me? I'm mostly a private individual and linux/debian user that got fed up with the Linux fragmentation and direction of development (from a user perspective). I found my new home in FreeBSD. I migrated my (hobby) root server and have a few jails up and running and doing random stuff on them for myself and friends. Key to this was that I was able to get FreeBSD up and running on my Laptop - with the drm-next kmod - and use it daily to get used to it and learn about it. Actually it was a pain in the ass because back then I had to learn how to make -current run and even worse, I had to use the drm-next graphics branch from a github repository which wasn't even on the main FreeBSD account. I was forced to update the kernel every once in a while because the pkg update would complain otherwise. It frequently broke and I had to deal with it and learn how to recover it. The alternative would have been to go back to Linux, which has a whole lot more to complain about. So I stayed. And I'm happy with it. I accepted all this trouble to have decent graphics support. In all the time I had to fight -current issues a lot more than anything drm/graphics related. This stuff was always stable for me. I saw a few people trying out FreeBSD. And the first thing after the Installation is always: Graphics and Wifi. That's what people need. These are "desktop needs", where supporting new hardware fast is more important than being rock stable and feature complete. Just my 2 cents, Stefan -- Stefan Hagen Mail: sh@codevoid.de | encryption key in header. gopher://codevoid.de | https://codevoid.de From owner-freebsd-current@freebsd.org Sat Aug 25 09:31:21 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 EACFD1083F16 for ; Sat, 25 Aug 2018 09:31:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 618AD90A11 for ; Sat, 25 Aug 2018 09:31:19 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([2.245.56.39]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MAy40-1g3Mnf1Cb6-00A0ry for ; Sat, 25 Aug 2018 11:31:15 +0200 Date: Sat, 25 Aug 2018 11:30:41 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: pkg-base: how to avoid FreeBSD-$PACKAGE-{profile|development} when using FreeBSD pkg-base Message-ID: <20180825113108.19b8cd86@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:sHlDmDs1uV4S/Kt/sE0Rxf3qR9lbCM0YBZ/qSm8WZKJSXY9G+W2 QXyz93WUa7RKfZb0buNQQGPNLA2mHWLIXENraBP1JkPLuob9qE0JM8XQ/DjdnQi8fVdgZft T+Aum3F3fi9JAuq+Erh3LxZGXYGxceVhzaJ8fuxHHnEahmn76SVYU6+KPEEQv2ldl1jAZAD DNXGQvwJw4TF5hFgFuGEA== X-UI-Out-Filterresults: notjunk:1;V01:K0:7SkOpLbW850=:c5Hhp1hc9pKwENnbbtXjUV VOwvU2uxzen46JLMT3Mw/LuDEBGM9f8kIGRuJEj5UBaENBqG3bTKg/Sc/HtaDUFXpMxARod8D wGDglJGiYRDEtfCl3Nippg36s7CUWIum2p3bF4zT8Z92BlCwRU7ZDAKYnuBETyITdA+hKuL90 t3PbPYYlLK/nzsyv2TrUtpTs0wWh+KRVVtDEdB2gUR5eC/Io+vYwukBeE1UiGf9Cj2ToTDwN+ Y+jJAz2u5rYVSX435/Yp+Zie2e3ty5Nu3l+vEhZYupjcC3q331m9uVk9bdTyhYLbCVNfXZsv0 pB+zpYp7WMrfRmIWawpLik5xdaJpfIuMm6FhW5cxTzhF4TgXoC1BOK/bCsy4hB4mFWx9TAu7u uM3lMoiuXRIjChFp9LKg1jxfS8RVmu0uLBRdA+BS0GD2luPA2dZU9xReFq/kh8gEllQi7SCEp JgUPr9x0a3Iq8H1rLEquGactiFWaJni89Cc171VIDmAU7auiLF+rXqoRikMvfNIvLu1+rG9cv Q58BK3zZBInWg6HFMhCUF5te0CuC2yW6FBnJKj0hVE7V9xBfxQ1pHk22p3oDqOvxm9VX/de8v tWpRBlhY300+kQdQErcAoSTtYvGF0KShgsNFxlz6haHqCNcjfgG3TpIkE4+Fg1G4dvGQiXD8C UzUjFWFYlmni/DaVHbtybmgsB3VIM3vMtzHu7dEa3tSUxm8BIw1QrTZC/zxUwMzFByqeVEX3G 1qU0M8orakHXb6EUOLc8oaioYxZjOZab8yw5zfG4OfnP1uLvgw3KbS7ReFzmhsTj5aVgZ9IMJ 7QQpYPV X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 09:31:21 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCg0KRm9y IHNvbWUgZXhwZXJpbWVudHMgb24gUElORTY0IHdlIGJ1aWxkIHBhY2thZ2VzIGZyb20gRnJlZUJT RCdzIGJhc2Ugc3lzdGVtLiBUaGUNCmluZGl2aWR1YWwgcGFja2FnZSBzZWVtcyB0byBjb21wcmlz ZSBhbHdheXMgZnJvbSBzZXZlcmFsIGZsYXZvdXJzLCB0aGUNCiJyZWd1bGFyL3Byb2R1Y3Rpb24i IG9uZSwgcHJvZmlsZS9wcm9maWxpbmcgb25lIGFuZCBkZXZlbG9wbWVudCwgZm9yIGluc3RhbmNl IGZvciBwYWNrYWdlDQpGcmVlQlNELWxpYnhvOg0KDQpGcmVlQlNELWxpYnhvOiAxMi4wLnMyMDE4 MDgyNTA5MDAzNiBbRnJlZUJTRC1iYXNlXQ0KRnJlZUJTRC1saWJ4by1kZXZlbG9wbWVudDogMTIu MC5zMjAxODA4MjUwOTAwMzYgW0ZyZWVCU0QtYmFzZV0NCkZyZWVCU0QtbGlieG8tcHJvZmlsZTog MTIuMC5zMjAxODA4MjUwOTAwMzYgW0ZyZWVCU0QtYmFzZV0NCg0KV2hlbiBpbnN0YWxsaW5nIHBh Y2thZ2VzIGFzIHJlY29tbWVuZGVkIG9uIHRoZSBGcmVlQlNEIHBrZy1iYXNlIFdpa2kNCihodHRw czovL3dpa2kuZnJlZWJzZC5vcmcvUGtnQmFzZSkgdmlhDQoNCnBrZyBpbnN0YWxsIC1nICdGcmVl QlNELSonDQoNCml0IGlzIGltcGxpY2l0IHRoYXQgSSBhbHNvIGdldCB0aG9zZSB1bndhbnRlZCAi cHJvZmlsaW5nIiBhbmQgImRldmVsb3BtZW50IiBwYWNrYWdlcyBhcw0Kd2VsbCBhcyB0aGUgc3Vw cG9zZWQgdG8gYmUgdGhlICJwcm9kdWN0aW9uIiBvbmVzLiBGaWRkbGluZyBhcm91bmQgd2hpdGgg dGhlIHBhdHRlcm4gbGVmdA0KbWUgd2l0aCBzb21lIHByb2JsZW1zLCBhcyBpdCBzZWVtcyB0byBt ZSB0byBtYWtlIHRoZSBlZmZvcnRzIHRvIGhpZ2ggdG8gdGFyZ2V0IGFsbCB3YW50ZWQNCnBhY2th Z2VzIG9yIGF2b2lkIGRldmVsb3BtZW50IHBhY2thZ2VzLiBJIGhhdmVuJ3QgZm91bmQgYSBwcm9w ZXIgd2F5IHRvIGV4Y2x1ZGUgYWxsIHRoZQ0KdW53YW50ZWQgcGFja2FnZXMgKGRldmVsb3BtZW50 LCBwcmlmaWxlKSBieSB0aGUgZ2xvYmFsIHBhdHRlcm4uDQoNCkkgd2FzIHRoaW5raW5nIHRoYXQg dGhlIGJ1aWxkIGJveCBhbHNvIGhhcyB0byB0YWtlIHNvbWUgbG9hZCB3aGVuIHBhY2thZ2luZy9i dWlsZGluZyBhbGwNCnRoZSBwcm9maWxpbmcvZGV2ZWxvcG1lbnQgc3R1ZmYsIHNvIGlzIHRoZXJl IGEgd2F5IHRvIGF2b2lkIGJ1aWxkaW5nIHRob3NlIHVud2FudGVkDQpwYWNrYWdlcyBpbiB0aGUg Zmlyc3QgcGxhY2U/DQoNCkF0IHRoZSBlbmQgbXkgUElORTY0IHduYXRzIHRvIGluc3RhbGwgMzEz IHBhY2thZ2VzLiBUaGlzIHNlZW1zIDIvMyB1bm5lY2Vzc2FyeS4NCg0KS2luZCByZWdhcmRzLA0K DQpvaA0KDQotIC0tIA0KTy4gSGFydG1hbm4NCg0KSWNoIHdpZGVyc3ByZWNoZSBkZXIgTnV0enVu ZyBvZGVyIMOcYmVybWl0dGx1bmcgbWVpbmVyIERhdGVuIGbDvHINCldlcmJlendlY2tlIG9kZXIg ZsO8ciBkaWUgTWFya3QtIG9kZXIgTWVpbnVuZ3Nmb3JzY2h1bmcgKMKnIDI4IEFicy4gNCBCRFNH KS4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQoNCmlMVUVBUk1LQUIwV0lRUVpWWk16 QXR3QzJULzg2VHJTNTI4ZnlGaFlsQVVDVzRFaDNBQUtDUkRTNTI4ZnlGaFkNCmxMYXZBZ0Ntakt1 aGFqTkNObU81M2tVN2dCZFFtVGRLbms5ckRLRk1WT3k0V1Q4bXhQNlI5WU1LSjJNZGZWbFoNCm5N Mi9KNHprdFpSaFRFSXJWdENJQnNGL1hEN0VBZ0NKZmhmK3psN3VNNGdEb2QrYkVlbklEUllkeXl3 TnVIVzINCkVrMGl0TXI3bk1iSkNzVlE4QklNbTlTb3JmdEQ0bHV1N2xhTklnTVVtWFVrUWUrRnhX VGMNCj00cjI1DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-current@freebsd.org Sat Aug 25 09:38:49 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 748AA1084273 for ; Sat, 25 Aug 2018 09:38:49 +0000 (UTC) (envelope-from srs0=xebg=li=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 E725990F7F; Sat, 25 Aug 2018 09:38:48 +0000 (UTC) (envelope-from srs0=xebg=li=sigsegv.be=kristof@codepro.be) Received: from [10.0.2.164] (ptr-8rgnodwguwcl7l2ksvq.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240b:b802:c9f5:de0e:83d2:3536]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 7A3FA401C4; Sat, 25 Aug 2018 11:38:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1535189926; bh=2hwrukxtwG/pxgqkc+C6uztOFbmr49Hxfrv3xkn0BgA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=a1YMW5/QePsF7zg3oHCa8z69uRKHfBkAE06pXiCnmFdXmXSGMPHXbdfgK8dpOhCnj 8jD09EjM7ZBMICHDU5/m8XIy98dPIv1hln08sVEAPZt7VrOKY6uQ47wHf+0nehgLYx s2Qxmh3GmSsRfJzJlXWi5HmDiYIIP3md0L+PkneU= From: "Kristof Provost" To: "O. Hartmann" Cc: "FreeBSD CURRENT" , "Brad Davis" Subject: Re: [CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA Date: Sat, 25 Aug 2018 11:38:40 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <3C0C5CB5-1A0F-49DD-A3FE-ADA5B00BAD48@sigsegv.be> In-Reply-To: <20180825090704.69e17a6e@thor.intern.walstatt.dynvpn.de> References: <20180825090704.69e17a6e@thor.intern.walstatt.dynvpn.de> 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.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 09:38:49 -0000 On 25 Aug 2018, at 9:06, O. Hartmann wrote: > I'm using ezjail-admin from ports (most recent tree, up to date as of > today, at Revision: > 478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25 > 07:10:45 CEST 2018 amd64, > the jails sources are at revision 338309). > > Updates of the jail's base is taken from /usr/src or another path (in > case of another > path, ezjail-admin update -i requires the setting of evn > MAKEOBJDIRPREFIX= some/place). > > Updating jails and creating new jails has worked for a while, but > recently, newly created > jails fail to start because the initial start routine bringing up the > jail dumps an error > about /bin/sh /etc/rc missing! > > Investigating a complete fresh ezajil setup (on ZFS) reveals, that > neither in fulljail, > newjail or basejail any of the initial rc-srcipts rc or rc.subr is > present any more! I > stopped looking for other missing scripts since rc and rc.subr are > crucial and essential > to the system, so I guess there has been introduced a sort of bug > recently in the way > FreeBSD 12 is going to handle/keep/store rc scripts in the source tree > or their > installation and ezjai didn't catch up so far. > > I already filed a PR (see Bug 230822), but I'm unsure whether this is > a "real" bug or I > did just miss some important changes and I didn't catch up. > Yep, it’s a real problem. I ran into it myself a few weeks ago. Many of the scripts and files in sys/etc have been moved, for pkg base. This, combined with ezjail doing the install wrong breaks your jails. Brad posted a patch to the ezjail mailing list. I can’t immediately find an archive linke, but this should fix it: --- ezjail-admin 2018-08-12 09:41:46.750946000 +0200 +++ /usr/local/bin/ezjail-admin 2018-08-12 09:42:42.863180000 +0200 @@ -1053,7 +1053,7 @@ # make and setup our world, then split basejail and newjail cd "${ezjail_sourcetree}" && env DESTDIR="${ezjail_jailfull}" make ${ezjail_installaction} || exerr "Error: The command 'make ${ezjail_installaction}' failed.\n Refer to the error report(s) above." - cd "${ezjail_sourcetree}/etc" && env DESTDIR="${ezjail_jailfull}" make distribution || exerr "Error: The command 'make distribution' failed.\n Refer to the error report(s) above." + cd "${ezjail_sourcetree}" && env DESTDIR="${ezjail_jailfull}" make distribution || exerr "Error: The command 'make distribution' failed.\n Refer to the error report(s) above." ezjail_splitworld fi # installaction="none" Regards, Kristof From owner-freebsd-current@freebsd.org Sat Aug 25 10:13: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 51C9710853D5 for ; Sat, 25 Aug 2018 10:13:16 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [144.76.30.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.bsd4all.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAD69921B4 for ; Sat, 25 Aug 2018 10:13:15 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sat, 25 Aug 2018 12:13:08 +0200 From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: pkg-base: how to avoid FreeBSD-$PACKAGE-{profile|development} when using FreeBSD pkg-base Message-ID: <20180825101308.xbnfbv7xfmuifl2b@mail.bsd4all.net> References: <20180825113108.19b8cd86@thor.intern.walstatt.dynvpn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180825113108.19b8cd86@thor.intern.walstatt.dynvpn.de> User-Agent: NeoMutt/20180716 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 10:13:16 -0000 On Sat, Aug 25, 2018 at 11:30:41AM +0200, O. Hartmann wrote: > > For some experiments on PINE64 we build packages from FreeBSD's base system. The > individual package seems to comprise always from several flavours, the > "regular/production" one, profile/profiling one and development, for instance for package > FreeBSD-libxo: > > FreeBSD-libxo: 12.0.s20180825090036 [FreeBSD-base] > FreeBSD-libxo-development: 12.0.s20180825090036 [FreeBSD-base] > FreeBSD-libxo-profile: 12.0.s20180825090036 [FreeBSD-base] > > When installing packages as recommended on the FreeBSD pkg-base Wiki > (https://wiki.freebsd.org/PkgBase) via > > pkg install -g 'FreeBSD-*' > > it is implicit that I also get those unwanted "profiling" and "development" packages as > well as the supposed to be the "production" ones. Fiddling around whith the pattern left > me with some problems, as it seems to me to make the efforts to high to target all wanted > packages or avoid development packages. I haven't found a proper way to exclude all the > unwanted packages (development, prifile) by the global pattern. Have you checked the content of the development packages? I guess you have to install them! To disable profile-packages set WITHOUT_PROFILE in /etc/src.conf. -- Herbert From owner-freebsd-current@freebsd.org Sat Aug 25 10:44:03 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 A12E41085EE5 for ; Sat, 25 Aug 2018 10:44:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FBCA93188 for ; Sat, 25 Aug 2018 10:44:03 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id h20-v6so5023098itf.2 for ; Sat, 25 Aug 2018 03:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eakQBjgtt3KBcOmL333K7I0hZGh1CPTRPMRqIig2LcM=; b=hBRoECGZrnKr5acvBXb19x1Whm4B6E5sq6sss8YArFUR1Ek2ZMS1g2fhYi63Vygczo X08Nq3ntxodykWiVZbD5CiQ7Kbifx30kMq5UUdTjS3cJ3vjTVfKuek0JTrCypHwfpZI8 ZGKTQ4xwyz/Cr20TrSkC60KrVSKS17I7RtKvxI/CjooYAgfhGJZxSVt0fgb4eREPUr1N joWD6w8+Z/jk7UMRFBdyZMcrMgnVDzXcHxMdwP+diKrRiksh/X0jmhROCmq5ERejK/nC THRvXKCCl3Muip9RejEZmTuPc2jufeLEh0kqMDNb+2FrHABRMVwBWySqHx6JICLsm2SQ aSOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eakQBjgtt3KBcOmL333K7I0hZGh1CPTRPMRqIig2LcM=; b=BiEOSORm+mcY5lA4pC2t37/5rVlO5TesZFD5BnB9hMxF3zBjszc7/1CX5elzW+qcRj 27SJTZKwah4udllWUBTWq+e7ewb8KjgRPaE/U09kWrfnBBL69hzgjS/+Dy0GEqB91JB5 jvbjJNBTJsy2iMSpW3u8xxUsN8HUJeB2hB+Q3Q79bZeyN76sC4qtO5ramwolfVNt4SOZ JUZIPuOVoSyMM2zp+MuhKI3UbFdYuHXIXJFjHp1cueHNeivlnTPIltDDEZ35ZJC9Z2c4 7WUrlOj56ayPDBykJg6lgV23X3ks6pBvSDlneZXrGY1fxgGDl1bAypDsihRzhjRUoKqh Wlzw== X-Gm-Message-State: APzg51D3ISxkaKmU86nsNhojKMGpPlPGLt5XUAI807ITYtJVraw5As+A RJGNqo2toC0UBLvbXEBsj7sil+JCN5Z8xmzCAK9VFzK5O00= X-Google-Smtp-Source: ANB0Vdb08Q4T86eHsKDPfP39ohcriRTnzDh7seytah38omxm0yuTYJVxYVEGkgnpV22Yxo1DkVGEDOJka343aUtH5dw= X-Received: by 2002:a24:7f94:: with SMTP id r142-v6mr1111264itc.137.1535193842329; Sat, 25 Aug 2018 03:44:02 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <20180825090623.GA1342@ptrace.hagen.corp> In-Reply-To: <20180825090623.GA1342@ptrace.hagen.corp> From: blubee blubeeme Date: Sat, 25 Aug 2018 18:43:50 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: sh+freebsd-current@codevoid.de Cc: FreeBSD current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 10:44:03 -0000 On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen wrote: > blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > >> I've been personally using the new DRM bits since almost day one. I > >> haven't found it to be unstable in the slightest. Compared to not > >> having it and being forced to run 5+ year old hardware, it's been a > >> huge blessing for those of us who care about running FreeBSD as a > >> modern desktop / laptop. > >> > >> FreeBSD being an open source project, you are welcome to contribute > >> back your work anytime. But since I don't imagine we'll see that > >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered, > >> Plasma-desktop running awesomeness. > >> > >> (Written from my brand new Lenovo P71 which worked flawlessly out of > >> box) > > > > Please tell me more about you're modern hardware, Kris Vice President > > of Engineering at iXsystems. > > > > Try asking a person who doesn't run server infrastructure software and > > hardware to get that stuff up and running, would you? > > Do you want to ask me? I'm mostly a private individual and linux/debian > user that got fed up with the Linux fragmentation and direction of > development (from a user perspective). I found my new home in FreeBSD. > I migrated my (hobby) root server and have a few jails up and running > and doing random stuff on them for myself and friends. > > Key to this was that I was able to get FreeBSD up and running on my > Laptop - with the drm-next kmod - and use it daily to get used to it and > learn about it. Actually it was a pain in the ass because back then I > had to learn how to make -current run and even worse, I had to use the > drm-next graphics branch from a github repository which wasn't even > on the main FreeBSD account. I was forced to update the kernel every > once in a while because the pkg update would complain otherwise. It > frequently broke and I had to deal with it and learn how to recover it. > > The alternative would have been to go back to Linux, which has a whole > lot more to complain about. So I stayed. And I'm happy with it. > > I accepted all this trouble to have decent graphics support. In all > the time I had to fight -current issues a lot more than anything > drm/graphics related. This stuff was always stable for me. > > I saw a few people trying out FreeBSD. And the first thing after the > Installation is always: Graphics and Wifi. That's what people need. > > These are "desktop needs", where supporting new hardware fast is more > important than being rock stable and feature complete. > > Just my 2 cents, > Stefan > > -- > Stefan Hagen > Mail: sh@codevoid.de | encryption key in header. > gopher://codevoid.de | https://codevoid.de > _______________________________________________ > 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" > Like you said you're doing hobby work, that's fine. Take the time to test that bleeding edge stuff on a branch somewhere. You guys cannot expect reasonable people who have machines running production code to have to deal with that type of nonsense that you just described. You left Linux because it's an unorganized mess, FreeBSD is not Linux. There are clear rules and restrictions if you guys cannot understand this then this is just a waste of time. FreeBSD is server first and while that may suck for hobbyist at first, once you understand that people who run servers do not care about graphics as much as hobbyist do they need a reliable core. The linuxkpi stuff the total antithesis of what I understand to be the FreeBSD philosophy. Try reading it again: https://www.freebsd.org/doc/handbook/nutshell.html You guys can't expect to destroy the stability for everyone because a few hobbyist who volunteer in their free time want to wreck the system. Work on your code to improve the quality instead of trying to turn the FreeBSD kernel into a thin wrapper around Linux kernel. Solve the engineering problems instead of asking for quick fix solutions. Any of you linuxkpi guys who are pushing this, what will be enough? Haven't you guys gotten enough leeway from the core team? How many breaking changes do you want to introduce to the FreeBSD kernel vs engineering your software to work well within the existing infrastructure? Which one of you guys dare to stand up and define a goal? From owner-freebsd-current@freebsd.org Sat Aug 25 12:51: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 51DCC1089D8E for ; Sat, 25 Aug 2018 12:51:29 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0679896D6B; Sat, 25 Aug 2018 12:51:29 +0000 (UTC) (envelope-from kp@FreeBSD.org) 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)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id B039CFB51; Sat, 25 Aug 2018 12:51:28 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8rgnodwguwcl7l2ksvq.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240b:b802:c9f5:de0e:83d2:3536]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 64D26404C7; Sat, 25 Aug 2018 14:51:26 +0200 (CEST) From: "Kristof Provost" To: "Matthew Macy" Cc: "Shawn Webb" , freebsd-current@freebsd.org Subject: Re: ifnet use after free Date: Sat, 25 Aug 2018 14:51:24 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <2287F455-EDFD-4065-BB83-33DDDF74D027@FreeBSD.org> In-Reply-To: <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> 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.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 12:51:29 -0000 On 25 Aug 2018, at 0:47, Kristof Provost wrote: > On 25 Aug 2018, at 0:26, Matthew Macy wrote: >> On Fri, Aug 24, 2018 at 15:25 Shawn Webb >> wrote: >> >>> Hey All, >>> >>> Somewhere in the last month or so, a use after free was introduced. >>> I >>> don't have the time right now to bisect the commits and figure out >>> which commit introduced the breakage. Attached is the core.txt >>> (which >>> seems nonsensical because the dump is reporting on a different >>> thread). If the core.txt gets scrubbed, I've posted it here: >>> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a >>> >> >> Do you have any guidance on how to reproduce? The hardenedbsd rev >> isn’t >> useful - the svn commit that it’s based against is what is needed. >> > For what it’s worth, it’s not a hardenedbsd thing. I’ve been > chasing the same one (same offset, same allocation size, same most > recent user). Something gets set to zero/NULL. 8 bytes on amd64, so > presumably a pointer. > > I currently only trigger it on a development branch, but I’ll see if > I can clean that up into something I can share tomorrow. > > In my test scenario it happens after shutdown of a vnet jail with a > few interfaces in it (including a pfsync interface which will > disappear with the jail), and new jails are started. It’s pretty > reliable. > > At a guess something’s wrong with the delayed cleanup of ifnets and > vnet shutdown. > I see this: Memory modified after free 0xfffff800623ab000(2040) val=0 @ 0xfffff800623ab398 panic: Most recently used by ifnet cpuid = 7 time = 1535199812 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c8e13c0 vpanic() at vpanic+0x1a3/frame 0xfffffe008c8e1420 panic() at panic+0x43/frame 0xfffffe008c8e1480 mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe008c8e14a0 uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfffffe008c8e1510 malloc() at malloc+0x9a/frame 0xfffffe008c8e1560 if_alloc() at if_alloc+0x23/frame 0xfffffe008c8e1590 epair_clone_create() at epair_clone_create+0x239/frame 0xfffffe008c8e1610 if_clone_createif() at if_clone_createif+0x4a/frame 0xfffffe008c8e1660 ifioctl() at ifioctl+0x852/frame 0xfffffe008c8e1750 kern_ioctl() at kern_ioctl+0x2ba/frame 0xfffffe008c8e17b0 sys_ioctl() at sys_ioctl+0x15e/frame 0xfffffe008c8e1880 amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe008c8e19b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe008c8e19b0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = 0x7fffffffe208, rbp = 0x7fffffffe250 --- KDB: enter: panic [ thread pid 1426 tid 100466 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db> It does require a couple of bug fixes in pfsync to trigger. You can get them from the pfsync_vnet branch in https://github.com/kprovost/freebsd/tree/pfsync_vnet After that: kldload pfsync pkg install scapy cd /usr/tests/sys/netpfil/pf kyua test It should panic reliably. Regards, Kristof From owner-freebsd-current@freebsd.org Sat Aug 25 15:33:09 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 DBA45108DFB7 for ; Sat, 25 Aug 2018 15:33:09 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29C3875658; Sat, 25 Aug 2018 15:33:08 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:to:subject:message-id; s=default; bh=lXLKyfJQh08jOKpn2GuimNNoG5K//utY2+bowbIrM1Q=; b=O/IoMdD74pLE9wINq7ZJ+M5L6d86TC9dInSRKvjDnR3ME5kHf7E4Sh/bZrpJ8ngE1sfub1UsJjNQe6awCfAB23ChcJ5GknXIYj0EvzRsZYHmD9apwKSnqZdQxSO9+39wDrTphBj5tiqsEuOMgXvYj1qTT4bZJrGyrUwnotG8+Bw= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id c1c04f71 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 25 Aug 2018 15:32:49 +0000 (UTC) Received: from localhost (markarth.lan [local]) by markarth.lan (OpenSMTPD) with ESMTPA id 5e3fbb22; Sat, 25 Aug 2018 18:32:43 +0300 (MSK) Date: Sat, 25 Aug 2018 18:32:43 +0300 From: Greg To: Niclas Zeising Cc: Warner Losh , "Rodney W. Grimes" , Kyle Evans , Johannes Lundberg , Matt Macy , FreeBSD Current Subject: Re: priority of paths to kernel modules? Message-ID: <20180825153243.7igswejbqcgqkyzg@unrelenting.technology> References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: OpenPGP: url=https://unrelenting.technology/pub/3B011BAF.asc User-Agent: the one that sucks less X-Hashcash: 1:20:180825:johalun0@gmail.com::gAJUm1jpa1hWYBDa:31Vo X-Hashcash: 1:20:180825:freebsd-current@freebsd.org::V5i88JE2y45El1G/:Iib6 X-Hashcash: 1:20:180825:freebsd-rwg@pdx.rh.cn85.dnsmgr.net::pF9RsP+89uZSmVn6:3ggZ X-Hashcash: 1:20:180825:kevans@freebsd.org::YZp24pDBSVcHOvit:8fM X-Hashcash: 1:20:180825:mmacy@freebsd.org::XQUdAYtBIpT2etql:22rA X-Hashcash: 1:20:180825:imp@bsdimp.com::AoAkZLa3IrMwlftR:0m69 X-Hashcash: 1:20:180825:zeising@freebsd.org::36mdQZFSZCMQuinr:AKfc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 15:33:10 -0000 On 08/25, Niclas Zeising wrote: >On 08/24/18 17:20, Warner Losh wrote: >> This would allow the graphics port to have a rc script that sets >>this up so when X11 goes to automatically load the module, the right one >>gets loaded. >> > >I just want to point out that X11 doesn't load the graphics kernel >driver by default when using the drm-*-kmod ports, and I'm not sure >the hack to have the intel ddx (xf86-video-intel) load the drm2 driver >is still around. > >It doesn't really matter though, since upstream is moving away from >having X load the driver, and I'd like us to follow suit by using >devmatch (this is one of the reasons we wanted to get rid of the base >drivers, as I've stated before). X can't always know which driver to >load (when using modesetting for instance), and in my opinion, it >should be the kernel/loader that decides which drivers to load. Yes, of course X shouldn't load the driver - also because: - X is not the only display server people use (I use Weston) - the console (vt) should also run with the graphics driver! (e.g. efifb currently conflicts with radeon/amdgpu so you have to turn efifb off to get anything working on EFI + Radeon, also many ARM boards do not have any graphics support in U-Boot or whatever firmware) I'm surprised to hear anyone was relying on the X server to load the kernel module. I *always* used kld_list. From owner-freebsd-current@freebsd.org Sat Aug 25 15:34: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 F41B7108E08D for ; Sat, 25 Aug 2018 15:34:31 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E68075706 for ; Sat, 25 Aug 2018 15:34:31 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 25B1920D87 for ; Sat, 25 Aug 2018 11:34:31 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Sat, 25 Aug 2018 11:34:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=gIL6HCpB/6GWp15lsq5c2GHHWWzcy ESnww+4LPKO0ME=; b=fHUTNTlnJffKdZvp3VnMPsSAo8VmPr3pEs/+S3eZ01zpj +DGpZwkgN5M2YuFMxrisYGLOk29iXj67york+3mBObBdXnM0bVzCgAHSxCoLMZNr yUNoe3jcWk+IomtgSbiK+s0qvjmx81xHYW4U3KwyUqwluj4Z3CrwzvPXnv96NJS4 DEJsu5neqEn4zf/E8RgqCZUBCUyBs+CWBGgvxP8iyp8uev0ex0ZYASQQaYGc2WsN zyFv4aUyncvh7CPc252TOcwHAF0Pjuj2c2vXQj22Aqb2cBKaY0vVJaQPsxXMVX9T VAm4iFprzi5ot2mMN4GNs8546Ipw5cpS8QOz8m2oA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gIL6HC pB/6GWp15lsq5c2GHHWWzcyESnww+4LPKO0ME=; b=sSSSlKfwxLWqmFLDa/C2aK 4Xi9/rZF1/AzBJ79Tncb/j8Y1yipAnxad+H3v2/p7obVB1J04oSZnkIehBpYiZZt JP5SyiZUHM/DVwnmZbsp1q2kMJghUTShk/cBXj618BGlvOUG50TpqpFcsMNekYHa DgL6ACG2hxii+AhGG2PeEEWGUxlIkU8vVK7yjI5qt+DDI3c2uJ+Yyqdt+ezixCNS vmj9iu1N7TmCFVQwz+wdmV3REunIHwdmG+bRWwpe6w2LYcwPMKvl327n3fsMqys2 Q+y9ZvgWA0Pr890yE8aghp11ExPNu0mvERTwfaidWgQ8k3SUCKwwK4XNrpOgloSQ == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C338D9E1E9; Sat, 25 Aug 2018 11:34:30 -0400 (EDT) Message-Id: <1535211270.43712.1485939120.7028945E@webmail.messagingengine.com> From: Dave Cottlehuber To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <20180825090623.GA1342@ptrace.hagen.corp> Subject: Re: drm / drm2 removal in 12 In-Reply-To: Date: Sat, 25 Aug 2018 17:34:30 +0200 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 15:34:32 -0000 > On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen > > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > >> I've been personally using the new DRM bits since almost day one. I > > >> haven't found it to be unstable in the slightest. Compared to not > > >> having it and being forced to run 5+ year old hardware, it's been a > > >> huge blessing for those of us who care about running FreeBSD as a > > >> modern desktop / laptop. Ditto. I'd like to express my heartfelt thanks for all the people who have been working on the drm-next code for over 2 years now. It's fantastic and an incredible piece of effort to pull it all together. I bought a new laptop 2 years ago, started running the drm-next branch before it even landed in the main FreeBSD tree, and its been solid as a rock. It was my first foray into running current and I've not looked back since. Power mgmt is great, I have working suspend/resume, backlight, HDMI hot-plug output with video & sound as well. That's amazing. A+++++++++++ Dave From owner-freebsd-current@freebsd.org Sat Aug 25 16:29:22 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 D5C70108FC8B for ; Sat, 25 Aug 2018 16:29:21 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FD7278775 for ; Sat, 25 Aug 2018 16:29:21 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id c14-v6so4204824wmb.4 for ; Sat, 25 Aug 2018 09:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RtI0lzo7LKUTmqD0M+QdGZsj0dWdilB/zUd1nqMNv7o=; b=Awza0B8splz1Uk7UtnJ9RCvr0MOG6H/FOAgyCB+T2eWI11dBK4fpK3Wa9ikQFeQ97D XnQD5zd2amB7cALshCPk5ryk+FZQ8K0MUSle6/B5oCbK21MsqSu0+xAdtFe3+md55nxP 90aWTBdj3uinn1WzUudPCW5XKh+WmvyBPRQzuLw7LdxwpJG5w+G/trEzIOAtckLqKrRL gn40CXbYc60kAsCwaa7BCf64X6kR5EiXFSJkTnPoWRa1S9wlN8BhRcvaNs2PI5fynKRP i560Jswz/xH8O5bbRR3oNc+0pLuLSPmx2YDzhYj20m6KF5Dga2eV6d6NzZ9ztQV18YF1 dWeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RtI0lzo7LKUTmqD0M+QdGZsj0dWdilB/zUd1nqMNv7o=; b=IqKEyl7Ku32IalIPiyNHwXRjoSuZm9QX49V9twyYvLeLwwlVkxUb1UBdugHSpi3qPx zPUnT7wTU0uHcDXM9oL1zSSxVChN7/1mJ3ewWrBkaCWbBx6OxNlm1jzcP1I4/o9sVaYg RHcv/0/awYkjgzB8gOrho2CayZkeHgVBiEa/lz7R2PhY/tXFYGDCTAJMzcvFSfYBAwEL +CRK4pmeFgUGqUq81UGylfgAc6+ipnZka1TClfIY3OkePDiNSmcGeNbc3u3hKObZyKfQ 61ZHpfNsnrdLWOp2yr5iM5lgxy5XhOZTULv1jjtksTGdVCKwoZnde2M/EE8tntLc2Qgs 9XsA== X-Gm-Message-State: APzg51CvYKXuxGdMhmxQDAM7W7ZMsXz6lPsMxmNA+xst/pt1s+k1wdS5 PGtIZeVk5VQ1OkS7Fqaz5pJFPISgZGYqBmdLfIc= X-Google-Smtp-Source: ANB0VdYx8WMUJcmK6XlypnEFLN9RebUyJv9CrQJe5Q2mTRfP523UBo8VEK6IrXcshfGoTVFNP4gpVJCVmDawaKt2vsw= X-Received: by 2002:a1c:f03:: with SMTP id 3-v6mr1477160wmp.129.1535214559872; Sat, 25 Aug 2018 09:29:19 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <20180825090623.GA1342@ptrace.hagen.corp> In-Reply-To: From: Johannes Lundberg Date: Sat, 25 Aug 2018 18:28:42 +0200 Message-ID: Subject: Re: drm / drm2 removal in 12 To: blubee blubeeme Cc: sh+freebsd-current@codevoid.de, freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 16:29:22 -0000 Hi Owen I'm truly sorry you feel this way about our work. At first I was thinking "I'm not going to feed the troll" but after giving what you're writing some more thought it seems maybe you have misunderstood some things that I want to clarify to make sure there's no misunderstanding by you or any one else reading this. There are almost 30,000 ports now in the ports tree. Many are ported from various operating systems. Many are from Linux, GPL'd and in most cases we depend on them for running the graphical desktop of our choice on FreeBSD. However, these ports are all optional. You don't have to install any of them if you don't want to, this includes the new generation GPU drivers and LinuxKPI. Linux is not "moving in to" the FreeBSD kernel. For those of you who want a "pure" BSD experience, running without X is just fine, or finding a pure BSD solution if one exists. For those who don't want Linux derived graphics drivers (which by the way the ones in sys/dev/drm2/ also are), nothing is forcing you to use them. Vesa of scfb works beautifully for a software rendered graphical user interface. Nvidia provides a native driver for FreeBSD if you have their hardware. CURRENT breaks sometimes, not only because of graphics. This is the nature of bleeding edge but we work hard to keep breakage to a minimal. For those of you who wish to run a more stable system, use a stable release. The graphics team at FreeBSD has new members and we're still trying to find our way regarding release schedule, support and other things. It's still a WIP and the road has been bumpy. There is still a lot to do for us to catch up and be able to provide a consistent experience for everyone. Again, we're doing the best we can with the resources we have. There's no way the few developers we have could develop and maintain native GPU drivers, spanning 20 years on three different hardware platforms. Especially considering how fast moving target the graphics hardware is. I know nothing I say matters to you, Owen, but your comments are quite extreme and contain false doomsday propaganda.. This mail is more to provide some information from the graphics team for anyone reading this so they don't fall for false propaganda. On Sat, Aug 25, 2018 at 12:45 PM blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen < > sh+freebsd-current@codevoid.de> > wrote: > > > blubee blubeeme wrote: > > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > >> I've been personally using the new DRM bits since almost day one. I > > >> haven't found it to be unstable in the slightest. Compared to not > > >> having it and being forced to run 5+ year old hardware, it's been a > > >> huge blessing for those of us who care about running FreeBSD as a > > >> modern desktop / laptop. > > >> > > >> FreeBSD being an open source project, you are welcome to contribute > > >> back your work anytime. But since I don't imagine we'll see that > > >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered, > > >> Plasma-desktop running awesomeness. > > >> > > >> (Written from my brand new Lenovo P71 which worked flawlessly out of > > >> box) > > > > > > Please tell me more about you're modern hardware, Kris Vice President > > > of Engineering at iXsystems. > > > > > > Try asking a person who doesn't run server infrastructure software and > > > hardware to get that stuff up and running, would you? > > > > Do you want to ask me? I'm mostly a private individual and linux/debian > > user that got fed up with the Linux fragmentation and direction of > > development (from a user perspective). I found my new home in FreeBSD. > > I migrated my (hobby) root server and have a few jails up and running > > and doing random stuff on them for myself and friends. > > > > Key to this was that I was able to get FreeBSD up and running on my > > Laptop - with the drm-next kmod - and use it daily to get used to it and > > learn about it. Actually it was a pain in the ass because back then I > > had to learn how to make -current run and even worse, I had to use the > > drm-next graphics branch from a github repository which wasn't even > > on the main FreeBSD account. I was forced to update the kernel every > > once in a while because the pkg update would complain otherwise. It > > frequently broke and I had to deal with it and learn how to recover it. > > > > The alternative would have been to go back to Linux, which has a whole > > lot more to complain about. So I stayed. And I'm happy with it. > > > > I accepted all this trouble to have decent graphics support. In all > > the time I had to fight -current issues a lot more than anything > > drm/graphics related. This stuff was always stable for me. > > > > I saw a few people trying out FreeBSD. And the first thing after the > > Installation is always: Graphics and Wifi. That's what people need. > > > > These are "desktop needs", where supporting new hardware fast is more > > important than being rock stable and feature complete. > > > > Just my 2 cents, > > Stefan > > > > -- > > Stefan Hagen > > Mail: sh@codevoid.de | encryption key in header. > > gopher://codevoid.de | https://codevoid.de > > _______________________________________________ > > 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" > > > Like you said you're doing hobby work, that's fine. Take the time to test > that bleeding edge stuff on a branch somewhere. > > You guys cannot expect reasonable people who have machines running > production code to have to deal with that type of nonsense that you just > described. > > You left Linux because it's an unorganized mess, FreeBSD is not Linux. > There are clear rules and restrictions if you guys cannot understand this > then this is just a waste of time. > > FreeBSD is server first and while that may suck for hobbyist at first, once > you understand that people who run servers do not care about graphics as > much as hobbyist do they need a reliable core. > > The linuxkpi stuff the total antithesis of what I understand to be the > FreeBSD philosophy. Try reading it again: > https://www.freebsd.org/doc/handbook/nutshell.html > > You guys can't expect to destroy the stability for everyone because a few > hobbyist who volunteer in their free time want to wreck the system. > > Work on your code to improve the quality instead of trying to turn the > FreeBSD kernel into a thin wrapper around Linux kernel. Solve the > engineering problems instead of asking for quick fix solutions. > > Any of you linuxkpi guys who are pushing this, what will be enough? > > Haven't you guys gotten enough leeway from the core team? > How many breaking changes do you want to introduce to the FreeBSD kernel vs > engineering your software to work well within the existing infrastructure? > > Which one of you guys dare to stand up and define a goal? > _______________________________________________ > 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 Sat Aug 25 17:21: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 4F9E81090F0F for ; Sat, 25 Aug 2018 17:21:32 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id BEFBE7A6B9 for ; Sat, 25 Aug 2018 17:21:31 +0000 (UTC) (envelope-from freebsd@grem.de) Received: (qmail 90977 invoked by uid 89); 25 Aug 2018 17:21:29 -0000 Received: from unknown (HELO ?192.168.250.192?) (mg@grem.de@46.244.231.99) by mail.grem.de with ESMTPA; 25 Aug 2018 17:21:29 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy) From: Michael Gmelin X-Mailer: iPhone Mail (15G77) In-Reply-To: <20180824203903.GJ2340@kib.kiev.ua> Date: Sat, 25 Aug 2018 19:21:28 +0200 Cc: John Baldwin , "freebsd-current@freebsd.org" , Matthias Apitz Content-Transfer-Encoding: quoted-printable Message-Id: <3CE9AF7F-CD5B-4FE3-9BDA-7F25C7A7C0B9@grem.de> References: <20180819161642.GP2340@kib.kiev.ua> <20180820004512.5171fa75@bsd64.grem.de> <20180820150904.GS2340@kib.kiev.ua> <57B6DC4C-16EE-4B7B-B691-CB79D8C40289@grem.de> <20180822154603.GW2340@kib.kiev.ua> <20180822211528.GB2340@kib.kiev.ua> <1C7DACDC-36F2-4E65-8C75-7B7215BB6546@grem.de> <20180824195947.GG2340@kib.kiev.ua> <32F22868-92ED-4223-84B5-77E72C7DCF50@grem.de> <20180824203903.GJ2340@kib.kiev.ua> To: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 17:21:32 -0000 >> On 24. Aug 2018, at 22:39, Konstantin Belousov wrot= e: >>=20 >> On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote: >>=20 >>=20 >>> On 24. Aug 2018, at 21:59, Konstantin Belousov wro= te: >>> Please apply the following debugging patch on top of the previous 'fix'.= >>> You need debug.late_console=3D0. >>=20 >> Unfortunately debug.late_console=3D0 doesn???t work on this machine (no m= ore output on the console), I tried that earlier in this thread - hence the s= lightly complicated debugging code I had to add to see the contents of physm= ap. >>=20 >> I could run this code after boot (feeding it an identical physmap) to get= debug output, would this make sense? > Yes, with exactly the same physmap[]. >=20 > Really, I do not need exactly the output from my patch, but just make it > clear why is_kernel_paddr() did not triggered selection from different > location. I have to apologize, something went wrong when I applied your previous fix, so it was never really used when I tested.= Now, with the patch applied correctly, the machine actually boots. Before calling init_ops.mp_bootaddress in getmemsize (machdep.c), physmap looks like this: physmap_idx: 8 i mem atop 0 0x0 0x0 1 0x30000 0x30 2 0x40000 0x40 3 0x9e400 0x9e 4 0x100000 0x100 5 0xf00000 0xf00 6 0x1000000 0x1000 7 0x7bf7a000 0x7bf7a 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 With your patch, it looks like this now (after calling getmemsize) 0 0x0 0x0 1 0x30000 0x30 2 0x40000 0x40 3 0x9e400 0x9e 4 0x100000 0x100 5 0xf00000 0xf00 6 0x1000000 0x1000 7 0x7bf77000 0x7bf77 8 0x100000000 0x100000 9 0x100600000 0x100600 10 0x0 0x0 PAGETABLES is 0x7bf77000 So I guess this means that the gap is now at the last three pages of [0x1000= , 0x7bf7a[. If this is what was intended, I guess it's good, as the machine boots okay n= ow. Sorry again for the extra roundtrip, the patched file was simply in the wron= g path. Yours, Michael p.s. Please see below the patched version of mp_machdep.c I used for testing (should match yours): ... #define AP_BOOTPT_SZ (PAGE_SIZE * 3) extern struct pcpu __pcpu[]; /* Temporary variables for init_secondary() */ char *doublefault_stack; char *mce_stack; char *nmi_stack; char *dbg_stack; /* * Local data and functions. */ static int start_ap(int apic_id); static bool is_kernel_paddr(vm_paddr_t pa) { return (pa >=3D trunc_2mpage(btext - KERNBASE) && pa < round_page(_end - KERNBASE)); } static bool is_mpboot_good(vm_paddr_t start, vm_paddr_t end) { return (start + AP_BOOTPT_SZ <=3D GiB(4) && end >=3D start + AP_BOOTPT_SZ && atop(end) < Maxmem); } /* * Calculate usable address in base memory for AP trampoline code. */ void mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx) { vm_paddr_t start, end; unsigned int i; bool allocated; alloc_ap_trampoline(physmap, physmap_idx); /* * Find a memory region big enough below the 4GB boundary to * store the initial page tables. Region must be mapped by * the direct map. * * Note that it needs to be aligned to a page boundary. */ allocated =3D false; for (i =3D *physmap_idx; i <=3D *physmap_idx; i -=3D 2) { /* * First, try to chomp at the start of the physmap region. * Kernel binary might claim it already. */ start =3D round_page(physmap[i]); end =3D trunc_page(physmap[i + 1]); if (is_mpboot_good(start, end) && !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { allocated =3D true; physmap[i] =3D start + AP_BOOTPT_SZ; break; } /* * Second, try to chomp at the end. Again, check * against kernel. */ end =3D trunc_page(physmap[i + 1]); start =3D end - AP_BOOTPT_SZ; if (start >=3D physmap[i] && is_mpboot_good(start, end) && !is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) { allocated =3D true; physmap[i + 1] =3D start; break; } } if (allocated) { mptramp_pagetables =3D start; if (physmap[i] =3D=3D physmap[i + 1] && *physmap_idx !=3D 0) { memmove(&physmap[i], &physmap[i + 2], sizeof(*physmap) * (*physmap_idx - i + 2)); *physmap_idx -=3D 2; } } else { mptramp_pagetables =3D trunc_page(boot_address) - AP_BOOTPT_SZ; if (bootverbose) printf( "Cannot find enough space for the initial AP page tables, placing them at %#= x", mptramp_pagetables); } } ... From owner-freebsd-current@freebsd.org Sat Aug 25 17:44:27 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 BEE1810916A5 for ; Sat, 25 Aug 2018 17:44:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7E57B059; Sat, 25 Aug 2018 17:44:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 315C9118A9; Sat, 25 Aug 2018 17:44:27 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f181.google.com with SMTP id r196-v6so9635199iod.0; Sat, 25 Aug 2018 10:44:27 -0700 (PDT) X-Gm-Message-State: APzg51DqVPOS641yYXoFvtQKUOsB6RT3VvM/Wj2+kbK2t0BzFp5L4avO pxqkYsY2J3gdP6yk6wM6xytbTVVn0xJz2Bcx7Uk= X-Google-Smtp-Source: ANB0VdZC6kGV4edQpJ1eMJfJqSEnv8HxXM96iHKoGx8D/cKhPUF3vY2zdY9OXjW6xEz/BMrU9e3BGYWNhGW5lT3oKc8= X-Received: by 2002:a5e:dd4b:: with SMTP id u11-v6mr5080251iop.237.1535219066460; Sat, 25 Aug 2018 10:44:26 -0700 (PDT) MIME-Version: 1.0 References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> <2287F455-EDFD-4065-BB83-33DDDF74D027@FreeBSD.org> In-Reply-To: <2287F455-EDFD-4065-BB83-33DDDF74D027@FreeBSD.org> From: Matthew Macy Date: Sat, 25 Aug 2018 10:44:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ifnet use after free To: Kristof Provost Cc: Shawn Webb , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 17:44:28 -0000 I'll take a look. But it's likely to not be the OP's issue. For future reference memguard on the memory type in question is extremely useful in catching use after free. -M On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: > On 25 Aug 2018, at 0:47, Kristof Provost wrote: > > On 25 Aug 2018, at 0:26, Matthew Macy wrote: > > On Fri, Aug 24, 2018 at 15:25 Shawn Webb > wrote: > > Hey All, > > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out > which commit introduced the breakage. Attached is the core.txt (which > seems nonsensical because the dump is reporting on a different > thread). If the core.txt gets scrubbed, I've posted it here: > https://gist.github.com/796ea88cec19a1fd2a85f4913482286a > > Do you have any guidance on how to reproduce? The hardenedbsd rev isn=E2= =80=99t > useful - the svn commit that it=E2=80=99s based against is what is needed= . > > For what it=E2=80=99s worth, it=E2=80=99s not a hardenedbsd thing. I=E2= =80=99ve been chasing the > same one (same offset, same allocation size, same most recent user). > Something gets set to zero/NULL. 8 bytes on amd64, so presumably a pointe= r. > > I currently only trigger it on a development branch, but I=E2=80=99ll see= if I can > clean that up into something I can share tomorrow. > > In my test scenario it happens after shutdown of a vnet jail with a few > interfaces in it (including a pfsync interface which will disappear with > the jail), and new jails are started. It=E2=80=99s pretty reliable. > > At a guess something=E2=80=99s wrong with the delayed cleanup of ifnets a= nd vnet > shutdown. > > I see this: > > Memory modified after free 0xfffff800623ab000(2040) val=3D0 @ 0xfffff8006= 23ab398 > panic: Most recently used by ifnet > > cpuid =3D 7 > time =3D 1535199812 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c8= e13c0 > vpanic() at vpanic+0x1a3/frame 0xfffffe008c8e1420 > panic() at panic+0x43/frame 0xfffffe008c8e1480 > mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe008c8e14a0 > uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfffffe008c8e1510 > malloc() at malloc+0x9a/frame 0xfffffe008c8e1560 > if_alloc() at if_alloc+0x23/frame 0xfffffe008c8e1590 > epair_clone_create() at epair_clone_create+0x239/frame 0xfffffe008c8e1610 > if_clone_createif() at if_clone_createif+0x4a/frame 0xfffffe008c8e1660 > ifioctl() at ifioctl+0x852/frame 0xfffffe008c8e1750 > kern_ioctl() at kern_ioctl+0x2ba/frame 0xfffffe008c8e17b0 > sys_ioctl() at sys_ioctl+0x15e/frame 0xfffffe008c8e1880 > amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe008c8e19b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe008c8e19= b0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x80047b74a, rsp =3D = 0x7fffffffe208, rbp =3D 0x7fffffffe250 --- > KDB: enter: panic > [ thread pid 1426 tid 100466 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> > > It does require a couple of bug fixes in pfsync to trigger. You can get > them from the pfsync_vnet branch in > https://github.com/kprovost/freebsd/tree/pfsync_vnet > > After that: > kldload pfsync > pkg install scapy > cd /usr/tests/sys/netpfil/pf > kyua test > > It should panic reliably. > > Regards, > Kristof > From owner-freebsd-current@freebsd.org Sat Aug 25 18:08:26 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 30DB71091C39 for ; Sat, 25 Aug 2018 18:08:26 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA64D7B896 for ; Sat, 25 Aug 2018 18:08:25 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.190] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 204acf67 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Sat, 25 Aug 2018 11:08:23 -0700 (PDT) To: FreeBSD-current From: Pete Wright Subject: issues with usb mouse detection on 12.0-ALPHA3 Message-ID: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.org> Date: Sat, 25 Aug 2018 11:08:20 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:08:26 -0000 howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected.  i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so.  starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. thx! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Aug 25 18:08: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 7586E1091C47; Sat, 25 Aug 2018 18:08:33 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 10BAE7B89C; Sat, 25 Aug 2018 18:08:33 +0000 (UTC) (envelope-from des@des.no) Received: from next.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 6F9C58505; Sat, 25 Aug 2018 18:08:32 +0000 (UTC) Received: by next.des.no (Postfix, from userid 1001) id 4D8EB8CAB; Sat, 25 Aug 2018 20:08:32 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: blubee blubeeme Cc: mmacy@freebsd.org, Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Subject: Re: drm / drm2 removal in 12 In-Reply-To: (blubee blubeeme's message of "Sat, 25 Aug 2018 16:44:02 +0800") References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) Date: Sat, 25 Aug 2018 20:08:32 +0200 Message-ID: <86k1oepbdr.fsf@next.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:08:33 -0000 blubee blubeeme writes: > True on both points my tone is just a reflection of attitudes of the > individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. > Some people enjoy making contributions w/o waving a banner constantly > wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. > How far will core FreeBSD bend over backwards to accommodate these > devs. The core team does not decide what goes into the tree or not. The developers do. > This is the beauty of an open source project, we bring the best to the > table, [...] Who exactly is =E2=80=9Cwe=E2=80=9D here? You are not a member of the proj= ect, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@freebsd.org Sat Aug 25 18:10: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 1AFBB1091DC0 for ; Sat, 25 Aug 2018 18:10:25 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC58E7BB6F for ; Sat, 25 Aug 2018 18:10:24 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 12B5D21B6F; Sat, 25 Aug 2018 14:10:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 25 Aug 2018 14:10:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=+JAKNoS9fWTisZ9Qb2581FPe7toKy rDo4bybbyjO0JA=; b=fSq0suTB+1upnTs7cOlI2S+ZxYl/iD92/Lvm9X6DYek3w RwA7iTi2tmo0Djn7yaKZ8/0hfQif0c0Z/QC7HBtIh9fLyiRKHGj8Px+mcrHAzxxz iNxiAxE/sFh6E8SSDoiXygNaYcse15i0nESMGERY4Kn/7S1Zln7NKFRRqv5Bou8d q0kRIkx2QarChEt9Cbts01lHq58uAKyiEcHRP6GJly9T0Gs6VD8btmH0obenT+Ep fGiIMEe/k06AxvSUzSt0EBk4oU/XK/ZVQwKM2/ZqHmIQwJUAagnFFKWkI9K8YoeX rI5gnu9tBSWSOj7Wb8LX8JEvFz9U2ciQFUttTUhNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+JAKNo S9fWTisZ9Qb2581FPe7toKyrDo4bybbyjO0JA=; b=Q4R1HbwT63exk3qeftBmZa J2w+HpZepLDH5hIvACY5M39T5xwCgotk57y32rg3KLRfbtyAfS/vcPqZXQxaAfbM FREC3+qSP2mt858zgKbxelnkMZZgI4oVPGR45ML20YrFEE890S2ZeFbC5ItDRqLc SqofTXvgQvVaz9HMzRNWab4pSutjMM/Vwkcl4XU63NQR21320yzY+xh545zQ4hds /2h9jaqRP8Fh70w8ImWkqfAjrdpw9kEYdX/+eIiJVD75mQ/jyyVX+uBJpjxPAqvD kZG1eyV9E1WauT+cYD08owMybFjmme5JsNXgN6Z1Rih0toH+WH65/qc1mzESufQA == X-ME-Proxy: X-ME-Sender: Received: from odin.yuripv.net (unknown [94.233.224.99]) by mail.messagingengine.com (Postfix) with ESMTPA id 2B1F310288; Sat, 25 Aug 2018 14:10:23 -0400 (EDT) Subject: Re: issues with usb mouse detection on 12.0-ALPHA3 To: Pete Wright , FreeBSD-current References: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.org> From: Yuri Pankov Message-ID: Date: Sat, 25 Aug 2018 21:10:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.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.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:10:25 -0000 Pete Wright wrote: > howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that > my usb mouse is not being detected.  i made sure to do a proper > mergemaster after building my kernel and world, and verified that > updates to devd configs were picked up as per UPDATING. > > i am seeing the following in my dmesg console: > ugen0.2: at usbus0 (disconnected) > ugen0.2: at usbus0 > > > this seems to happen every 60secs or so.  starting moused also reports > the following: > $ sudo service moused start > Starting default mousedmoused: unable to open /dev/psm0: No such file or > directory > > not really sure what the best way to debug this is as i'm a bit > uncertain about devd and devmatch's recent changes, so let me know if > more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. From owner-freebsd-current@freebsd.org Sat Aug 25 18:13: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 B621110922EE for ; Sat, 25 Aug 2018 18:13:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 347FD7C092 for ; Sat, 25 Aug 2018 18:13:00 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.106] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 35242d29 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sat, 25 Aug 2018 11:12:59 -0700 (PDT) Subject: Re: issues with usb mouse detection on 12.0-ALPHA3 To: Yuri Pankov , FreeBSD-current References: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.org> From: Pete Wright Message-ID: <173b9e42-9b38-340b-5fee-45188ef1fbfb@nomadlogic.org> Date: Sat, 25 Aug 2018 11:12:55 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:13:00 -0000 On 8/25/18 11:10 AM, Yuri Pankov wrote: > Pete Wright wrote: >> howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed >> that my usb mouse is not being detected.  i made sure to do a proper >> mergemaster after building my kernel and world, and verified that >> updates to devd configs were picked up as per UPDATING. >> >> i am seeing the following in my dmesg console: >> ugen0.2: at usbus0 (disconnected) >> ugen0.2: at usbus0 >> >> >> this seems to happen every 60secs or so.  starting moused also >> reports the following: >> $ sudo service moused start >> Starting default mousedmoused: unable to open /dev/psm0: No such file >> or directory >> >> not really sure what the best way to debug this is as i'm a bit >> uncertain about devd and devmatch's recent changes, so let me know if >> more info is needed or if i'm just missing something obvious. > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. d'oh - didn't even think to check bugzilla. thanks! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Aug 25 18:51:26 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 A77C1109324A for ; Sat, 25 Aug 2018 18:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 369FB7D4FE for ; Sat, 25 Aug 2018 18:51:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id p129-v6so5901985ite.3 for ; Sat, 25 Aug 2018 11:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qGHPguh90REwdk8QzWFQwEqkdk29Cbn5BNN/spyogq4=; b=1q/04Y/ZZHL/zwVTf1idT8Z2RChFoJXicGl5iivqLRKN6XcCl/k04hjHbyKuxwNfwb RRKGMyM7B44FMvuoMNSOj7E1dSif7H7mQQE0nFAQuGZZvVpVjGmjD/wqnTsgV1VlhJOm j+ti2dKtMY9i/+oqoq/cQtk3OLcWdfG/wZRkSlbhh+BngXGvApvSQwP5XXrlkepqgDMN Ao3wCOmmi3P68NVQ9gEP/ZJkUaZ0/pMeFMJtcYuypJe0FO6CdElwIRHfQ+lnrdkYJ77n gnzWrzue1T+DKI1qfmPE6H6rDluapSUz0cq5VOgWuQXeqmYMPiSSS0Vv7FJ405wpTxHl +xLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qGHPguh90REwdk8QzWFQwEqkdk29Cbn5BNN/spyogq4=; b=mJKWAA46r5EqRe3o+OjM0TC0GxpFN/GHxAORGZ4ngXO9yTT3TJW0ltY4oAEWGJ+DiN rzmO/TBKWp8BDMKj3Ws2DY2wb6CSEv8lQzeK0VumalLToG4CC/EllV54Y6Jfo4mE5/dV DOoofKWktyw3I1+mMFdn8aguUBW+NN+yI7/5H3REA4oY2RWWECSUsqSjF3MdbG98e+Gi Eu/kJigp0SYRGM0IxIVt9OWB3GU7grIBM9xHuVdAWrRPO5I2cKgr8WSl6Q75xTH1CAxG I5YqXO5LCB5lhvwZDcx68eGk1wqTvdlDTby/0WPZeW/mkbd5neLoKR1ohWF/6u3DG+Lq hlJA== X-Gm-Message-State: APzg51AzvkuDV9w2m0ZWmZpYSFHPWEkQSDqv/pWOaIlfIPJKzGITiwZj f/tPuM3+8P9UuvwmV6IljQIHUFdWsOlME0C+TR2sThor X-Google-Smtp-Source: ANB0VdZd2R97Pz5/kYSu0UVBEmiR33iHvakbTJm/vQIrY1ONNrTpdLHnSBJ1Qe5+EsSWEkQCuwelCOL1iuCRRytgdag= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr2110315ite.39.1535223085484; Sat, 25 Aug 2018 11:51:25 -0700 (PDT) MIME-Version: 1.0 References: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.org> <173b9e42-9b38-340b-5fee-45188ef1fbfb@nomadlogic.org> In-Reply-To: <173b9e42-9b38-340b-5fee-45188ef1fbfb@nomadlogic.org> From: Warner Losh Date: Sat, 25 Aug 2018 12:51:13 -0600 Message-ID: Subject: Re: issues with usb mouse detection on 12.0-ALPHA3 To: Pete Wright Cc: Yuri Pankov , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:51:26 -0000 On Sat, Aug 25, 2018, 12:17 PM Pete Wright wrote: > > > On 8/25/18 11:10 AM, Yuri Pankov wrote: > > Pete Wright wrote: > >> howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed > >> that my usb mouse is not being detected. i made sure to do a proper > >> mergemaster after building my kernel and world, and verified that > >> updates to devd configs were picked up as per UPDATING. > >> > >> i am seeing the following in my dmesg console: > >> ugen0.2: at usbus0 (disconnected) > >> ugen0.2: at usbus0 > >> > >> > >> this seems to happen every 60secs or so. starting moused also > >> reports the following: > >> $ sudo service moused start > >> Starting default mousedmoused: unable to open /dev/psm0: No such file > >> or directory > >> > >> not really sure what the best way to debug this is as i'm a bit > >> uncertain about devd and devmatch's recent changes, so let me know if > >> more info is needed or if i'm just missing something obvious. > > > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. > > d'oh - didn't even think to check bugzilla. > Just committed a change to devmatch. It looks like I committed from the wrong tree, dropping a new line.:( Warner thanks! > -pete > > -- > Pete Wright > pete@nomadlogic.org > @nomadlogicLA > > _______________________________________________ > 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 Sat Aug 25 18:58:22 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 E88791093505 for ; Sat, 25 Aug 2018 18:58:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 778827D9B8 for ; Sat, 25 Aug 2018 18:58:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.102] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id d7bc8934 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sat, 25 Aug 2018 11:58:18 -0700 (PDT) Date: Sat, 25 Aug 2018 11:58:13 -0700 Subject: Re: issues with usb mouse detection on 12.0-ALPHA3 Message-ID: <0ff49e03-ec2e-4be4-aa26-0e3484eed3e7@email.android.com> X-Android-Message-ID: <0ff49e03-ec2e-4be4-aa26-0e3484eed3e7@email.android.com> In-Reply-To: From: Pete Wright To: Warner Losh Cc: Yuri Pankov , FreeBSD Current Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 18:58:22 -0000 From owner-freebsd-current@freebsd.org Sat Aug 25 19:10:49 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 CAE551093A97 for ; Sat, 25 Aug 2018 19:10:49 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E4B77E27A; Sat, 25 Aug 2018 19:10:49 +0000 (UTC) (envelope-from kp@FreeBSD.org) 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)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 2FF74120B8; Sat, 25 Aug 2018 19:10:49 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8rgnodwguwcl7l2ksvq.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240b:b802:c9f5:de0e:83d2:3536]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 9D2FC409B4; Sat, 25 Aug 2018 21:10:46 +0200 (CEST) From: "Kristof Provost" To: "Matthew Macy" Cc: "Shawn Webb" , freebsd-current@freebsd.org Subject: Re: ifnet use after free Date: Sat, 25 Aug 2018 21:10:45 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <3B8F3112-6DD3-4461-9256-ECB044FA6D44@FreeBSD.org> In-Reply-To: References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> <2287F455-EDFD-4065-BB83-33DDDF74D027@FreeBSD.org> MIME-Version: 1.0 Embedded-HTML: [{"HTML":[1263, 4800], "plain":[812, 3370], "uuid":"CA9F1319-8BF7-4391-974F-72C201EF5342"}] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 19:10:50 -0000 You may be right about that. With memguard (on ifnet) it implicates pf: pfi_cleanup_vnet() at pfi_cleanup_vnet+0xa4/frame 0xfffffe084f775320 vnet_pf_uninit() at vnet_pf_uninit+0x85f/frame 0xfffffe084f7757c0 vnet_destroy() at vnet_destroy+0x12c/frame 0xfffffe084f7757f0 prison_deref() at prison_deref+0x29d/frame 0xfffffe084f775830 sys_jail_remove() at sys_jail_remove+0x28a/frame 0xfffffe084f775880 amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe084f7759b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe084f7759b0 --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x8003130da, rsp = 0x7fffffffe848, rbp = 0x7fffffffe8d0 --- I’ll investigate that. Sorry for the noise. Thanks for the pointer to memguard. Very useful. Kristof On 25 Aug 2018, at 19:44, Matthew Macy wrote: > I'll take a look. But it's likely to not be the OP's issue. For future > reference memguard on the memory type in question is extremely useful > in > catching use after free. > > -M > > On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: > >> On 25 Aug 2018, at 0:47, Kristof Provost wrote: >> >> On 25 Aug 2018, at 0:26, Matthew Macy wrote: >> >> On Fri, Aug 24, 2018 at 15:25 Shawn Webb >> wrote: >> >> Hey All, >> >> Somewhere in the last month or so, a use after free was introduced. I >> don't have the time right now to bisect the commits and figure out >> which commit introduced the breakage. Attached is the core.txt (which >> seems nonsensical because the dump is reporting on a different >> thread). If the core.txt gets scrubbed, I've posted it here: >> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a >> >> Do you have any guidance on how to reproduce? The hardenedbsd rev >> isn’t >> useful - the svn commit that it’s based against is what is needed. >> >> For what it’s worth, it’s not a hardenedbsd thing. I’ve been >> chasing the >> same one (same offset, same allocation size, same most recent user). >> Something gets set to zero/NULL. 8 bytes on amd64, so presumably a >> pointer. >> >> I currently only trigger it on a development branch, but I’ll see >> if I can >> clean that up into something I can share tomorrow. >> >> In my test scenario it happens after shutdown of a vnet jail with a >> few >> interfaces in it (including a pfsync interface which will disappear >> with >> the jail), and new jails are started. It’s pretty reliable. >> >> At a guess something’s wrong with the delayed cleanup of ifnets and >> vnet >> shutdown. >> >> I see this: >> >> Memory modified after free 0xfffff800623ab000(2040) val=0 @ >> 0xfffff800623ab398 >> panic: Most recently used by ifnet >> >> cpuid = 7 >> time = 1535199812 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfffffe008c8e13c0 >> vpanic() at vpanic+0x1a3/frame 0xfffffe008c8e1420 >> panic() at panic+0x43/frame 0xfffffe008c8e1480 >> mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe008c8e14a0 >> uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfffffe008c8e1510 >> malloc() at malloc+0x9a/frame 0xfffffe008c8e1560 >> if_alloc() at if_alloc+0x23/frame 0xfffffe008c8e1590 >> epair_clone_create() at epair_clone_create+0x239/frame >> 0xfffffe008c8e1610 >> if_clone_createif() at if_clone_createif+0x4a/frame >> 0xfffffe008c8e1660 >> ifioctl() at ifioctl+0x852/frame 0xfffffe008c8e1750 >> kern_ioctl() at kern_ioctl+0x2ba/frame 0xfffffe008c8e17b0 >> sys_ioctl() at sys_ioctl+0x15e/frame 0xfffffe008c8e1880 >> amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe008c8e19b0 >> fast_syscall_common() at fast_syscall_common+0x101/frame >> 0xfffffe008c8e19b0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = >> 0x7fffffffe208, rbp = 0x7fffffffe250 --- >> KDB: enter: panic >> [ thread pid 1426 tid 100466 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> db> >> >> It does require a couple of bug fixes in pfsync to trigger. You can >> get >> them from the pfsync_vnet branch in >> https://github.com/kprovost/freebsd/tree/pfsync_vnet >> >> After that: >> kldload pfsync >> pkg install scapy >> cd /usr/tests/sys/netpfil/pf >> kyua test >> >> It should panic reliably. >> >> Regards, >> Kristof >> From owner-freebsd-current@freebsd.org Sat Aug 25 19:12: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 D394F1093C4A for ; Sat, 25 Aug 2018 19:12:15 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 837197E58B; Sat, 25 Aug 2018 19:12:15 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 3F8C6121B7; Sat, 25 Aug 2018 19:12:15 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f170.google.com with SMTP id l7-v6so9725014iok.6; Sat, 25 Aug 2018 12:12:15 -0700 (PDT) X-Gm-Message-State: APzg51CtaHMdUEt6azWxAxgz3liL1NrXgECkEqNToZ2o2waEl/xD5bKN 6GrU7jfswWYUp48AvuFCcjkCtyo9YvO83P9iHU4= X-Google-Smtp-Source: ANB0VdbQPXOqRj4gMtAsRyTqve7MlRBeTJQjhLc7E1balkOfhcY0ZgtDn5TJTufZZHm9Jk2S5g3m8Lqiq2IRL3XdPPQ= X-Received: by 2002:a5e:dd4b:: with SMTP id u11-v6mr5250297iop.237.1535224334595; Sat, 25 Aug 2018 12:12:14 -0700 (PDT) MIME-Version: 1.0 References: <20180824221955.7hkftov25otk6bjc@mutt-hbsd> <7A724399-B264-41A9-B85F-A49D3B0B4730@FreeBSD.org> <2287F455-EDFD-4065-BB83-33DDDF74D027@FreeBSD.org> <3B8F3112-6DD3-4461-9256-ECB044FA6D44@FreeBSD.org> In-Reply-To: <3B8F3112-6DD3-4461-9256-ECB044FA6D44@FreeBSD.org> From: Matthew Macy Date: Sat, 25 Aug 2018 12:12:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ifnet use after free To: Kristof Provost Cc: Shawn Webb , freebsd-current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 19:12:16 -0000 On Sat, Aug 25, 2018 at 12:10 PM Kristof Provost wrote: > You may be right about that. With memguard (on ifnet) it implicates pf: > > pfi_cleanup_vnet() at pfi_cleanup_vnet+0xa4/frame 0xfffffe084f775320 > vnet_pf_uninit() at vnet_pf_uninit+0x85f/frame 0xfffffe084f7757c0 > vnet_destroy() at vnet_destroy+0x12c/frame 0xfffffe084f7757f0 > prison_deref() at prison_deref+0x29d/frame 0xfffffe084f775830 > sys_jail_remove() at sys_jail_remove+0x28a/frame 0xfffffe084f775880 > amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe084f7759b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe084f7759= b0 > --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip =3D 0x8003130da, r= sp > =3D 0x7fffffffe848, rbp =3D 0x7fffffffe8d0 --- > > I=E2=80=99ll investigate that. Sorry for the noise. > Thanks for the pointer to memguard. Very useful. > > And thank you for updating me. -M > Kristof > > On 25 Aug 2018, at 19:44, Matthew Macy wrote: > > I'll take a look. But it's likely to not be the OP's issue. For future > reference memguard on the memory type in question is extremely useful in > catching use after free. > > -M > > On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: > >> On 25 Aug 2018, at 0:47, Kristof Provost wrote: >> >> On 25 Aug 2018, at 0:26, Matthew Macy wrote: >> >> On Fri, Aug 24, 2018 at 15:25 Shawn Webb >> wrote: >> >> Hey All, >> >> Somewhere in the last month or so, a use after free was introduced. I >> don't have the time right now to bisect the commits and figure out >> which commit introduced the breakage. Attached is the core.txt (which >> seems nonsensical because the dump is reporting on a different >> thread). If the core.txt gets scrubbed, I've posted it here: >> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a >> >> Do you have any guidance on how to reproduce? The hardenedbsd rev isn=E2= =80=99t >> useful - the svn commit that it=E2=80=99s based against is what is neede= d. >> >> For what it=E2=80=99s worth, it=E2=80=99s not a hardenedbsd thing. I=E2= =80=99ve been chasing the >> same one (same offset, same allocation size, same most recent user). >> Something gets set to zero/NULL. 8 bytes on amd64, so presumably a point= er. >> >> I currently only trigger it on a development branch, but I=E2=80=99ll se= e if I >> can clean that up into something I can share tomorrow. >> >> In my test scenario it happens after shutdown of a vnet jail with a few >> interfaces in it (including a pfsync interface which will disappear with >> the jail), and new jails are started. It=E2=80=99s pretty reliable. >> >> At a guess something=E2=80=99s wrong with the delayed cleanup of ifnets = and vnet >> shutdown. >> >> I see this: >> >> Memory modified after free 0xfffff800623ab000(2040) val=3D0 @ 0xfffff800= 623ab398 >> panic: Most recently used by ifnet >> >> cpuid =3D 7 >> time =3D 1535199812 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008c= 8e13c0 >> vpanic() at vpanic+0x1a3/frame 0xfffffe008c8e1420 >> panic() at panic+0x43/frame 0xfffffe008c8e1480 >> mtrash_ctor() at mtrash_ctor+0x81/frame 0xfffffe008c8e14a0 >> uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfffffe008c8e1510 >> malloc() at malloc+0x9a/frame 0xfffffe008c8e1560 >> if_alloc() at if_alloc+0x23/frame 0xfffffe008c8e1590 >> epair_clone_create() at epair_clone_create+0x239/frame 0xfffffe008c8e161= 0 >> if_clone_createif() at if_clone_createif+0x4a/frame 0xfffffe008c8e1660 >> ifioctl() at ifioctl+0x852/frame 0xfffffe008c8e1750 >> kern_ioctl() at kern_ioctl+0x2ba/frame 0xfffffe008c8e17b0 >> sys_ioctl() at sys_ioctl+0x15e/frame 0xfffffe008c8e1880 >> amd64_syscall() at amd64_syscall+0x28c/frame 0xfffffe008c8e19b0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe008c8e1= 9b0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x80047b74a, rsp =3D= 0x7fffffffe208, rbp =3D 0x7fffffffe250 --- >> KDB: enter: panic >> [ thread pid 1426 tid 100466 ] >> Stopped at kdb_enter+0x3b: movq $0,kdb_why >> db> >> >> It does require a couple of bug fixes in pfsync to trigger. You can get >> them from the pfsync_vnet branch in >> https://github.com/kprovost/freebsd/tree/pfsync_vnet >> >> After that: >> kldload pfsync >> pkg install scapy >> cd /usr/tests/sys/netpfil/pf >> kyua test >> >> It should panic reliably. >> >> Regards, >> Kristof >> > From owner-freebsd-current@freebsd.org Sat Aug 25 19:48: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 557721094A47 for ; Sat, 25 Aug 2018 19:48:58 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mx0b-0010f301.pphosted.com (mx0b-0010f301.pphosted.com [148.163.153.244]) (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 DCD4E7FF1E; Sat, 25 Aug 2018 19:48:57 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (m0102859.ppops.net [127.0.0.1]) by mx0b-0010f301.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7PJkIXA025854; Sat, 25 Aug 2018 14:48:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rice.edu; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=ricemail; bh=jNVHBhz5dNZ4yLNVlbuQXWZGoYIV26BBz4g7CTnKRbI=; b=Kp5xVYOVxtjRp0c+4YGLAwr/8tYaiCOfghpAEGSMVcgK8BzorPdjzT87EyxzxUb8wdst vub9+Y/Hsa3SuGdAFCMSzT/9EbROhkMKMGBA0qrAQ2gKPW4Ax74qnGVFZCIBJN3p6MvS pAlHbOOOVMMgvfl63aSArZd0ZUHVPS/LVO//IHt7Z51mkAYwiiZpYGFEjETfvTkB0Cmj 3Z92tTj1ykWRXFnugFrhQ8ziDAnRJSgQ5rm1PXBBi6bJzpNeW7rfdYIuRwUgWcR5FwhM EIa2neCuQg2k71HbR2k/DjO/ciyRrt8aketaKYzHIDnOEnnFRIYCSM+767SV3w8aEzFN sw== Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx0b-0010f301.pphosted.com with ESMTP id 2m32fu0fx8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 25 Aug 2018 14:48:56 -0500 Received-X: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 4EDD1460C2C; Sat, 25 Aug 2018 14:48:56 -0500 (CDT) Received-X: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 4D82F460BB2; Sat, 25 Aug 2018 14:48:56 -0500 (CDT) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received-X: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id DiMEUqbTw3EZ; Sat, 25 Aug 2018 14:48:56 -0500 (CDT) Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id C1610460B9F; Sat, 25 Aug 2018 14:48:55 -0500 (CDT) Subject: Re: nvidia-driver build error (last ports, FreeBSD-HEAD) From: Alan Cox To: tech-lists , Manfred Antar , Alexey Dokuchaev Cc: "Alex V. Petrov" , freebsd-current , alc@freebsd.org References: <20180822022343.GA60855@FreeBSD.org> <4925AAFC-0D43-4DC3-9E41-61F44359255A@gmail.com> <60982d01-7d08-25b7-97c5-009a6be13b88@zyxst.net> <44324f5e-5146-7525-7a60-1b774fc5d85a@rice.edu> Openpgp: preference=signencrypt Autocrypt: addr=alc@rice.edu; prefer-encrypt=mutual; keydata= xsBNBFG8q4IBCADBE55F7sX+cKhEadxhNkXrbtVSJhw3TQDPvc3nBWxsfdMAhPWozhpLczV/ hr8mDJV5tirit0qhw4ANPwtsn7i/xlcSdC9p8Jvkcpp/AfiA5B78Y08AsC6K6tbNHZ06qPq3 eCXDNbPzsUXyvyt25A+ZnQj4HbW4FpA6C5ITG1eeJPGO8WV9vhBQ4X/BWI61RXaJw68Jxtwo c9eovzdxbWTd5po/oGHL2ganYoBMu1OGpGFWvTDwy2ARCV7i+fSkfKXUPaQm17AuVVbZu8OU Ig6caCEA5MlZVsMpwuJQp7xdEQzPaDML3drkl32l3Rb09g5vKjjLHb+LXx/7PyeEWsG1ABEB AAHNGkFsYW4gQ294IDxhbGNARnJlZUJTRC5vcmc+wsB4BBMBAgAiBQJRvK14AhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCFEwQ8M+KJO7tKB/462f5Zzygqera1acLTIrIfdDXp cfyq3+OhFzbBh91b2Jw+CVKvH+hVpCUSW86Sgfv4sSvgsqdS9nMwN82MZDchNROfkkoY1Nkl 0EgayOmOoYroRp1bM65OZAMrw7qK/iG8FeJ1s6ex4wSSfeRETmFNhK0KMfTeLiKlIjW+KhIQ h+trVIWt9ZlvHI3xw6RUuEQ1CFvzETcwj/+YxLd8aha0Mr6qW/4VDw0G9g+YnqR8jnm1dOsO x8s+vJt2QmRuWGSsj5nk9Dc+Tpzytbvrv3rOCsEwuadWZU53/wL576XnqliWwkte3njN+BwI LoDuKBoqxIvdqI7lqTzYdww5BPd3zsBNBFG8q4IBCAC0hrybH/nTPvIeQm5qa5ZzwThdjb6y otBFjl/5LnMNfa2yhhJp0tQkr/WsJ/RiaYEmp7bGKnowbKR+6X7MF6qcRHwEPpibN8fpxKFg JlvhQhQWmU7nuBWqt8I1/y8aVLci7BPLRk6IKaMQJWWk18Wetijnao5gGEFu/iF9CzbYmJ/U ijVMJj08WlhQCiPnKFkirV8XjAOER5F2ecfLtfPLL/bZ+/Wm6xM+eo1ipc30oRf1Z7Rkcg94 RjiRpVacSnBQEFMXukD33w6WaKYT18B4rwN27tJfzTmGKRKggWEc3EWeQgzi3rD7x35owBJ7 x+G6lIjdSG4o9ytB3qTVazo3ABEBAAHCwF8EGAECAAkFAlG8q4ICGwwACgkQhRMEPDPiiTuH kAgAo3MUNRzGplyvgPezfnLgnwtlDYMF1HWp+67IIvY3WwcC51FQNHWmGis+H7Bor+aeSAfo KREw9l4U0Tu2YC9uiWKZzA4zer2WMhsB4VGMQ8GPuE2R2sFob5n293FsLWDSWM4Midory9zN EAYQ+Ijpv8WaATS217YYygA+iFlfMmQSKDS1G6HBnUjzQe23sX/06JAAxAvwmOI7OjwLlOCU Q5FaHPz6s8UjdHpZ/OUTElc7URPTr/KramlLhwuTRC2p8XyBrzYqz3Kfl42jEcOuxeHy07DG dm1Euqa5/CKTNBhMWjcujz11TUeI9+f5J2xUSlbj7nGJsnL5P34+SvtsKg== Message-ID: <4a20ff49-9dc7-736f-9339-2bbbfae1e360@rice.edu> Date: Sat, 25 Aug 2018 14:48:55 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <44324f5e-5146-7525-7a60-1b774fc5d85a@rice.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-25_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=11 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808250216 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 19:48:58 -0000 On 08/22/2018 10:29, Alan Cox wrote: > On 08/22/2018 08:48, tech-lists wrote: >> On 22/08/2018 05:29, Manfred Antar wrote: >>>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev >>>> wrote: >>>> >>>> On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: >>>>> -------- Перенаправленное сообщение -------- >>>>> Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) >>>>> Дата: Tue, 21 Aug 2018 16:41:42 +0700 >>>>> От: Alex V. Petrov >>>>> Кому: FreeBSD Ports >>>> Should be fixed as of r477761. >>>> >>>> ./danfe >> It's not fixed, seems to error elsewhere now: >> >> context: 12.0-ALPHA1 #0 r337886 / ports r477782 / empty /etc/make.conf >> >> This is a bare metal installation. >> >> root@desktop:/usr/ports/x11/nvidia-driver# make distclean && make >> clean && make MAKE_JOBS_UNSAFE=yes >> >> [...] >> >> cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" >> -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 >> -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-compare >> -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef >> -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. >> -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common >> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD >> -MF.depend.nvidia_subr.o -MTnvidia_subr.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 -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-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c >> nvidia_subr.c -o nvidia_subr.o >> nvidia_subr.c:1131:41: error: too many arguments to function call, >> expected 7, have 8 >> sc->dma_mask, PAGE_SIZE, 0, attr); >> ^~~~ >> /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here >> vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, >> ^ >> nvidia_subr.c:1269:45: error: too many arguments to function call, >> expected 7, have 8 >> sc->dma_mask, PAGE_SIZE, 0, attr); >> ^~~~ >> /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here >> vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, >> ^ >> 2 errors generated. >> *** Error code 1 >> >> Stop. >> make[4]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia >> *** Error code 1 >> >> Stop. >> make[3]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src >> *** Error code 1 >> >> Stop. >> make[2]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/ports/x11/nvidia-driver >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/x11/nvidia-driver >> root@desktop:/usr/ports/x11/nvidia-driver# >> > All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should > have their first parameter, typically kernel_arena, but sometimes > kmem_arena, removed in FreeBSD 12. > > There is still one more pending change to kmem_free() that has not hit > HEAD yet. That change will be the last. The last change in this series has been committed to HEAD. With that change, you will want to remove the first argument, which should be an arena pointer, from kmem_free() calls. Alan From owner-freebsd-current@freebsd.org Sat Aug 25 20:07: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 8BD42109501D for ; Sat, 25 Aug 2018 20:07:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (mail.nomadlogic.org [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DFAB8082E for ; Sat, 25 Aug 2018 20:07:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.190] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id a3942672 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Sat, 25 Aug 2018 13:07:01 -0700 (PDT) Subject: Re: issues with usb mouse detection on 12.0-ALPHA3 To: Warner Losh Cc: Yuri Pankov , FreeBSD Current References: <62afdc77-b247-fd78-d848-55b3b609660d@nomadlogic.org> <173b9e42-9b38-340b-5fee-45188ef1fbfb@nomadlogic.org> From: Pete Wright Message-ID: Date: Sat, 25 Aug 2018 13:06:57 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 20:07:04 -0000 On 8/25/18 11:51 AM, Warner Losh wrote: > On Sat, Aug 25, 2018, 12:17 PM Pete Wright wrote: > >> >> On 8/25/18 11:10 AM, Yuri Pankov wrote: >>> Pete Wright wrote: >>>> howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed >>>> that my usb mouse is not being detected. i made sure to do a proper >>>> mergemaster after building my kernel and world, and verified that >>>> updates to devd configs were picked up as per UPDATING. >>>> >>>> i am seeing the following in my dmesg console: >>>> ugen0.2: at usbus0 (disconnected) >>>> ugen0.2: at usbus0 >>>> >>>> >>>> this seems to happen every 60secs or so. starting moused also >>>> reports the following: >>>> $ sudo service moused start >>>> Starting default mousedmoused: unable to open /dev/psm0: No such file >>>> or directory >>>> >>>> not really sure what the best way to debug this is as i'm a bit >>>> uncertain about devd and devmatch's recent changes, so let me know if >>>> more info is needed or if i'm just missing something obvious. >>> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. >> d'oh - didn't even think to check bugzilla. >> > Just committed a change to devmatch. It looks like I committed from the > wrong tree, dropping a new line.:( > > Warner > > thanks! yep that fix 'er up on my end.  initially i thought it didn't work because i had only installed an updated kernel.  once i realized my mistake, rebuilding devmatch with your latest patch applied fixed everything up. cheers! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Sat Aug 25 23:23:28 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 7DBCC1098CA0; Sat, 25 Aug 2018 23:23:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CE45858BB; Sat, 25 Aug 2018 23:23:28 +0000 (UTC) (envelope-from gurenchan@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id l7-v6so9971399iok.6; Sat, 25 Aug 2018 16:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2A2ABcxHpi2b+hEh0wAblF4Aioy0yaAasnFOQ193TZw=; b=cU69nsVSUIAqmyEwkH6HqdmVZ2oesMbIwyD5AKwEsbYPC+MMLWGfMJLhFR3EJGFcpV Ka6US8a3s0TySGPNJgSvk6aa/Nz6fhJ2ICxyii7tF+RWlEF3LDDA9HNT8xqBeCjiIxGR 2kYZyMvR+Z3U4L25dfwDl1edVZLSIlUBv1vfRNWlk2GMmp2zTKr/l38X/wg7ioUxp+my eE7yu49tHrGbqFrE9QFZL06+sOClt0BVWwEQtxwSrXfhz9Zxt2IAuxi4b2jHQFjeIwvF zdH+sQxBCROcymZ8U3FeqfCF6HHD6atWjNqZNiDpNpMRR2fQDURmBn7NtMqEOZRc4ei+ zBBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2A2ABcxHpi2b+hEh0wAblF4Aioy0yaAasnFOQ193TZw=; b=j7E9A8lr8YmhB3p74iRLBa6wborMBq+XBmPgbGgWXaPgjz1G88YzpSWre4WIZmQ8zH Dj2GQ6MJSgH7qsIZpSspbwJoA8SGowJ9p+fFFW10NCncAZqM5ZeBnHAoGDiofABQ5vFI 2lxqWKl2wVTfXcZiFKH7lKg3B+9+LsUh8gmfP2I5ngLIrCWNg6amyF0xDkMmQe7GmpRy u3aiFcjXpM3ObuytPmqLBU+BL9vs6kka1VSra4ze2ALtOdBNRW1E8NPjDJj7jXWZlOQv /hTto+Jg+lPbTfZX5NTCRSpAM4ziNGRwosYQ6xm2aHWZezheTd88UW0s/PLvp4sSTqlO 6Wkg== X-Gm-Message-State: APzg51AeJm6JhKps0aqO8a9lZdaC2bNfCWjM+6RvnwMolqKd9WmwfgkX Lc5S+Tk4AS/vdQNFu2mIrpRmbnsSKwyXprERT1c= X-Google-Smtp-Source: ANB0Vdas6fR9RJaBSIIGVIS/AIN27bAxrep8CcokyQ4B3V5iW4nlu4kqssA40oUPEVQieg+I/tfpxCY8BdeDZdi3KVQ= X-Received: by 2002:a5e:890c:: with SMTP id k12-v6mr5528851ioj.136.1535239407318; Sat, 25 Aug 2018 16:23:27 -0700 (PDT) MIME-Version: 1.0 References: <20180824215302.ivfna55jtrtc5trg@freebsd480.station> <86k1oepbdr.fsf@next.des.no> In-Reply-To: <86k1oepbdr.fsf@next.des.no> From: blubee blubeeme Date: Sun, 26 Aug 2018 07:23:15 +0800 Message-ID: Subject: Re: drm / drm2 removal in 12 To: des@des.no Cc: mmacy@freebsd.org, Warner Losh , Ali Abdallah , FreeBSD current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2018 23:23:28 -0000 On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Sm=C3=B8rgrav wrote= : > blubee blubeeme writes: > > True on both points my tone is just a reflection of attitudes of the > > individuals that I am currently addressing. > > Well, congratulations on alienating absolutely everybody you have > interacted with on this topic. > > > Some people enjoy making contributions w/o waving a banner constantly > > wanting acknowledgement, a pat on the head and good job from everyone. > > The only person I see constantly craving attention and validation from > others here is you. > > > How far will core FreeBSD bend over backwards to accommodate these > > devs. > > The core team does not decide what goes into the tree or not. The > developers do. > > > This is the beauty of an open source project, we bring the best to the > > table, [...] > > Who exactly is =E2=80=9Cwe=E2=80=9D here? You are not a member of the pr= oject, you do > not speak for the project, and after seeing how you treat our fellow > developers, our friends, most of us want nothing to do with you. If > can't live with that, I'm sure you can figure out how to install Linux. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? ---- A little background ---- Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. ----------------------------------- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work?