From owner-freebsd-arch@freebsd.org Sun Oct 6 03:23:11 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 38492F9110 for ; Sun, 6 Oct 2019 03:23:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.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 46m87x6stxz4V8n for ; Sun, 6 Oct 2019 03:23:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x963MwBf065733; Sat, 5 Oct 2019 20:22:58 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x963Mwo1065732; Sat, 5 Oct 2019 20:22:58 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> Subject: Re: New CPUTYPE default for i386 port In-Reply-To: To: Warner Losh Date: Sat, 5 Oct 2019 20:22:58 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 46m87x6stxz4V8n X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.73 / 15.00]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.62)[0.619,0]; NEURAL_HAM_LONG(-0.83)[-0.830,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.04), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 03:23:11 -0000 > On Sat, Oct 5, 2019, 11:03 AM Rodney W. Grimes < > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > For a variety of reasons, the time has come to change the default code > > > generation arch from i486 to i686 on our i386 port. No actual code > > removal > > > is planned as part of this effort. Only the default is doing changed for > > > clang. > > > > > > The practical upshot of this for our i386 users will be zero for almost > > > everybody. For the tiny sliver of people planning to deploy FreeBSD on a > > > i486 or i586 core, a simple addition of CPUTYPE=xxxx to /etc/make.conf is > > > all that is needed for the src side of things. They will need to setup > > > their own poudriere instance and create their own pkg repo to build > > > whatever packages are required for their deployment. > > > > > > It's my belief that even in the trailing edge long tail embedded > > deployment > > > segment of our user base this will cause no issues. All deployments there > > > I'm aware of have moved of i486 class CPUs and the one 586 class core > > > deployment I know of has no plans to update that to FreeBSD 11, let alone > > > newer. > > > > > > There are a number of advantages to doing this which have been > > articulated > > > at length in other discussions. Briefly we get better code generation for > > > CPUs people use and we avoid some test failures in llvm 9.0 because i486 > > > doesn't have 64-bot atomics. > > > > > > Comments? > > > > Please provide some type of eol statement in the next release cycle release > > notes that base and packages are no longer usable on the class of i386 > > lower > > than i686, with the above rationale and work around. > > > > Sure. Of course. > > >From the above it does sound as if you plan to MFC this back as far as 11? > > > > No plans to MFC. Ok, so this is an issue at 13 and later, so people could update legacy stuff into stable/12 in the future, thats lots of head room looking forward. > > > What is the error condition one sees if you try to boot release media > > built i686 on a i386/i486 system? It needs to be something sinceable > > and preferable some direction to work around, not just some random illegal > > instruction panic, PLEASE! > > > > We should remove 486 and 586 CPU support from GENERIC and then the kernel > would say the CPU was unsupported. But only if there were no illegal > instructions. That is my concern, that we are going to end up with some crazy fault or panic that is cryptic and leaves the user with little clue as to what went wrong. > However, GENERIC already requires 128MB or 256MB or more to > boot, which is beyond what 486 and 586 could have on them so it may be a > moot point. 586 == Pentium I, almost all, if not all chipsets in the family support 128MB, and many supported 192 to 512MB. > Other than those 2 issues and 1 question I have no objection to doing this. > > Regards, > > -- > > Rod Grimes > > rgrimes@freebsd.org > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Sun Oct 6 03:37:15 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4DC02F93DC for ; Sun, 6 Oct 2019 03:37:15 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from muon.bsdio.com (muon.bluestop.org [65.103.231.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46m8SB1X29z4Vhj for ; Sun, 6 Oct 2019 03:37:13 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from muon.bsdio.com (localhost [127.0.0.1]) by muon.bsdio.com (Postfix) with ESMTP id F0D351D7FB; Sat, 5 Oct 2019 21:37:17 -0600 (MDT) Received: from muon.bsdio.com ([127.0.0.1]) by muon.bsdio.com (muon.bsdio.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZlO94pxNlozx; Sat, 5 Oct 2019 21:37:17 -0600 (MDT) Received: from [10.0.10.197] (unknown [10.0.10.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by muon.bsdio.com (Postfix) with ESMTPSA; Sat, 5 Oct 2019 21:37:17 -0600 (MDT) From: Rebecca Cran Mime-Version: 1.0 (1.0) Subject: Re: New CPUTYPE default for i386 port Date: Sat, 5 Oct 2019 21:37:04 -0600 Message-Id: <3E928CA4-91EF-47CF-9728-4E98789AC18E@bsdio.com> References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> Cc: Warner Losh , freebsd-arch@freebsd.org In-Reply-To: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: iPhone Mail (17A861) X-Rspamd-Queue-Id: 46m8SB1X29z4Vhj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of rebecca@bsdio.com has no SPF policy when checking 65.103.231.193) smtp.mailfrom=rebecca@bsdio.com X-Spamd-Result: default: False [-2.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.874,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdio.com]; AUTH_NA(1.00)[]; URI_COUNT_ODD(1.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.991,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:209, ipnet:65.100.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.76)[ip: (-8.82), ipnet: 65.100.0.0/14(-4.84), asn: 209(-0.08), country: US(-0.05)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 03:37:15 -0000 > On Oct 5, 2019, at 9:23 PM, Rodney W. Grimes wrote: >=20 > 586 =3D=3D Pentium I, almost all, if not all chipsets in the family suppor= t > 128MB, and many supported 192 to 512MB. Though many couldn=E2=80=99t cache more than 64MB.=20 =46rom https://www.vogonswiki.com/index.php/Socket_7_Builds =E2=80=9CIt's a common mistake to load up 430FX, 430VX and 430TX chip sets w= ith maximum amount of memory supported by the chipset. With these chip sets,= the use of more than 64MB of RAM results in a significant performance drop,= as memory bandwidth over 64MB is considerably reduced resulting in about 40= % system performance compared to working with L2-cached RAM. To avoid this, e= ither remove extra RAM, or change motherboard for a 430HX based one. If spec= ific applications require more RAM, it could be worthwhile to cover the RAM a= bove 64 MB when using DOS by loading a RAM drive to the remaining top memory= area. Some chip sets from other manufacturers are also known to cache more t= han 64 MB RAM.=E2=80=9D =E2=80=94=20 Rebecca Cran= From owner-freebsd-arch@freebsd.org Sun Oct 6 03:54:24 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5D4BEF9816 for ; Sun, 6 Oct 2019 03:54:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46m8qz2BXyz4WKD for ; Sun, 6 Oct 2019 03:54:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id d16so14442319qtq.8 for ; Sat, 05 Oct 2019 20:54:22 -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=rdkYVpYWsCN/ud3sRyNdMG3bQdGxxKXNG5as3gRr3rI=; b=SatoQ53Liy/CgB+Q3jCmFdamXUyCxvOKYfPkcuQ79/FoNODmJfS6l2tOsEB0JSWL8C 6vmZfTCe3TdC0r4Rdc4RRuMcUcJS52rLcfGgFP/ivvOYhEvyQQi3ipPBz32oA+WgbvIM pvq+TcHBdxLpJIPY9ThZEGphwkRcd95e3ahliQjIANJp7kKODqy2rJiKd3LGencxsbXG F15kVhOgUXyEUQVYxp3jV6DzukWKwEDsKapk9/pRysWSuSiLFPLr62W0sXYtBjtAji1g OKIaRL31Mh9xDuOMxg4X7Ldq4kMcMtHLlEL2rLiqwnvKNuTauqsgTso40d2bR22mZmkt 7vYQ== 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=rdkYVpYWsCN/ud3sRyNdMG3bQdGxxKXNG5as3gRr3rI=; b=CbBO34JFlpJj+gtp/6Pc3yenIAnH5wbV2cEDpNpLavNlxkAzSideTxuK3GBgG8w3tV eFBDLek2DxIaAEe+Orxh2aeZQi6vt4zDUErOyUpheyYeFcVYshniAU374hOYGiKXjN17 AAGuTkd3DBT3E/nPdZzbjBYpCqT+2FtnFaQ8Sdy31BHjnJgcdwlNauaNVmT+WnrPy6Td qNsPvTjo/9oInzp7i4qikLWqKZwuPe8kNSc28bVRjhLh8V8sIBwZM9PshvtNxPhUMHrX HzQulHCxz9QzgeqSrEBD5M8kVpHF1xPtfOBXxRF38gMC1gfDii1yiDIdkgucOM7QSsJC eHSA== X-Gm-Message-State: APjAAAX9sIf0dSiupujc8XDmrrljj3/0R9ltpjxUPJbrIQzAhaKMiNYl pIPT2K2lWZ1dw/DYzV9mlYKwsMJN3p/mE1iDrysvGg== X-Google-Smtp-Source: APXvYqwnBf/XOzUE/aKaDdb7fH1oK08kJV0zu+HCXOcMP5PV/VZS1H3EG5pM9f5dyiNVQHwbftpDFxbF/2MZg417I68= X-Received: by 2002:a0c:9ba8:: with SMTP id o40mr21901895qve.125.1570334061657; Sat, 05 Oct 2019 20:54:21 -0700 (PDT) MIME-Version: 1.0 References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> In-Reply-To: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> From: Warner Losh Date: Sat, 5 Oct 2019 21:54:09 -0600 Message-ID: Subject: Re: New CPUTYPE default for i386 port To: "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 46m8qz2BXyz4WKD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=SatoQ53L; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::841) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.46)[ip: (2.45), ipnet: 2607:f8b0::/32(-2.56), asn: 15169(-2.15), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 03:54:24 -0000 On Sat, Oct 5, 2019, 9:23 PM Rodney W. Grimes wrote: > > On Sat, Oct 5, 2019, 11:03 AM Rodney W. Grimes < > > freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > > > > > For a variety of reasons, the time has come to change the default > code > > > > generation arch from i486 to i686 on our i386 port. No actual code > > > removal > > > > is planned as part of this effort. Only the default is doing changed > for > > > > clang. > > > > > > > > The practical upshot of this for our i386 users will be zero for > almost > > > > everybody. For the tiny sliver of people planning to deploy FreeBSD > on a > > > > i486 or i586 core, a simple addition of CPUTYPE=xxxx to > /etc/make.conf is > > > > all that is needed for the src side of things. They will need to > setup > > > > their own poudriere instance and create their own pkg repo to build > > > > whatever packages are required for their deployment. > > > > > > > > It's my belief that even in the trailing edge long tail embedded > > > deployment > > > > segment of our user base this will cause no issues. All deployments > there > > > > I'm aware of have moved of i486 class CPUs and the one 586 class core > > > > deployment I know of has no plans to update that to FreeBSD 11, let > alone > > > > newer. > > > > > > > > There are a number of advantages to doing this which have been > > > articulated > > > > at length in other discussions. Briefly we get better code > generation for > > > > CPUs people use and we avoid some test failures in llvm 9.0 because > i486 > > > > doesn't have 64-bot atomics. > > > > > > > > Comments? > > > > > > Please provide some type of eol statement in the next release cycle > release > > > notes that base and packages are no longer usable on the class of i386 > > > lower > > > than i686, with the above rationale and work around. > > > > > > > Sure. Of course. > > > > >From the above it does sound as if you plan to MFC this back as far as > 11? > > > > > > > No plans to MFC. > Ok, so this is an issue at 13 and later, so people could update > legacy stuff into stable/12 in the future, thats lots of head > room looking forward. > > > > > > What is the error condition one sees if you try to boot release media > > > built i686 on a i386/i486 system? It needs to be something sinceable > > > and preferable some direction to work around, not just some random > illegal > > > instruction panic, PLEASE! > > > > > > > We should remove 486 and 586 CPU support from GENERIC and then the kernel > > would say the CPU was unsupported. But only if there were no illegal > > instructions. > > That is my concern, that we are going to end up with some crazy > fault or panic that is cryptic and leaves the user with little > clue as to what went wrong. > > > However, GENERIC already requires 128MB or 256MB or more to > > boot, which is beyond what 486 and 586 could have on them so it may be a > > moot point. > > 586 == Pentium I, almost all, if not all chipsets in the family support > 128MB, and many supported 192 to 512MB. > There are two issues here. First, the pentiums under ~200mhz don't support booting off of CDROM. Second, most of the Pentium chipsets couldn't use more than 64MB, so often that was the max you could get. Pentium Pro in that era did more memory, but it was the first i686. Pentium II were a different story as well. Both often were provisioned with 128MB or more. Plus, the desktop / server versions of this stuff is over 20-25 years old. While the embedded 586 lived a bit longer, it stopped being produced a decade ago.... All this strongly suggest a warning in the release notes is all we need. I'd be curious what today's snapshot does on these machines... Warner > Other than those 2 issues and 1 question I have no objection to doing > this. > > > Regards, > > > -- > > > Rod Grimes > > > rgrimes@freebsd.org > > > > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-arch@freebsd.org Sun Oct 6 10:55:18 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5195C13CF41 for ; Sun, 6 Oct 2019 10:55:18 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 46mL9d0hT2z43GR; Sun, 6 Oct 2019 10:55:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] ([194.32.164.30]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id x96AtADx092543; Sun, 6 Oct 2019 11:55:11 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New CPUTYPE default for i386 port From: Bob Bishop In-Reply-To: <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org> Date: Sun, 6 Oct 2019 11:55:10 +0100 Cc: Cy Schubert , freebsd-arch@freebsd.org, Warner Losh , Shawn Webb Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd> <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com> <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 46mL9d0hT2z43GR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[250.164.32.194.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.65)[ip: (-2.32), ipnet: 194.32.164.0/24(-1.16), asn: 42831(0.31), country: GB(-0.08)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 10:55:18 -0000 > On 5 Oct 2019, at 23:50, Ian Lepore wrote: >=20 > On Sat, 2019-10-05 at 14:20 -0700, Cy Schubert wrote: >> On October 5, 2019 11:19:41 AM PDT, Warner Losh >> wrote: >>> On Sat, Oct 5, 2019, 11:34 AM Shawn Webb < >>> shawn.webb@hardenedbsd.org> >>> wrote: >>>=20 >>>> On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote: >>>>>=20 > [...] >>>> I'm curious about the possibilities regarding 64-bit time_t on >>>> 32-bit >>>> Intel systems. >>>>=20 >>>=20 >>> Beyond the scope of this discussion. However, feel free to start a >>> thread on this. It's quite difficult to switch if you want binary >>> compat. It would affect system calls on the upgrade path and is >>> among the hardest types to change if you have any kind of legacy to >>> support... >>>=20 >>> Warner >>>=20 >>>=20 >>=20 >> This is one of the two reasons I believe we should deprecate 32-bit. >> Even supporting 32-bit compatibility long term is unsustainable. It >> is not worth the effort. >>=20 >> Putting a stake in the ground to say we no longer support 32-bit >> after 2038 would be desirable. (Sooner the better though.) >>=20 >>=20 >=20 > Only i386 has a 32-bit time_t. Other 32-bit arches either began life > with 64-bit time_t or have been switched to it. >=20 > For i386, if its current users (and I am one, for $work) have a choice > between "As of date X there will be no more i386" and "As of date X we > switch time_t to 64 bits and you will not be able to run old binaries > after that" I suspect people would choose the latter. >=20 > =E2=80=94 Ian Obvious casualties of total i386 deprecation would be Soekris 45xx (AMD = Elan (i486)) and 55xx (AMD Geode (i586)), we have small numbers of those = running recent HEAD. We are only still using them because they are more = or less indestructible (especially compared with a lot of the ARM-based = offerings). I don=E2=80=99t think we=E2=80=99d complain if i386 support = ceased on a reasonable timescale. -- Bob Bishop rb@gid.co.uk From owner-freebsd-arch@freebsd.org Sun Oct 6 10:51:33 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3387713C587 for ; Sun, 6 Oct 2019 10:51:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 46mL5H0d7Tz42bx; Sun, 6 Oct 2019 10:51:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 854C236245A; Sun, 6 Oct 2019 21:51:26 +1100 (AEDT) Date: Sun, 6 Oct 2019 21:51:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore cc: Cy Schubert , freebsd-arch@freebsd.org, Warner Losh , Shawn Webb Subject: Re: New CPUTYPE default for i386 port In-Reply-To: <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org> Message-ID: <20191006203059.H863@besplex.bde.org> References: <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd> <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com> <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=D+Q3ErZj c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=7Qk2ozbKAAAA:8 a=ypVJL4-jAAAA:8 a=mUqToFXoNYs5UDRkVOEA:9 a=CjuIK1q_8ugA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=khIbc0fXALFIcTpOSxgJ:22 X-Rspamd-Queue-Id: 46mL5H0d7Tz42bx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.249 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-5.14), ipnet: 211.28.0.0/14(-3.22), asn: 4804(-2.37), country: AU(0.01)]; RCVD_NO_TLS_LAST(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[249.132.29.211.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 10:51:33 -0000 On Sat, 5 Oct 2019, Ian Lepore wrote: > On Sat, 2019-10-05 at 14:20 -0700, Cy Schubert wrote: >> On October 5, 2019 11:19:41 AM PDT, Warner Losh >> wrote: >>> On Sat, Oct 5, 2019, 11:34 AM Shawn Webb < >>> shawn.webb@hardenedbsd.org> >>> wrote: >>> >>>> On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote: >>>>> > [...] >>>> I'm curious about the possibilities regarding 64-bit time_t on >>>> 32-bit >>>> Intel systems. A good source of bloat and bugs. >>> Beyond the scope of this discussion. However, feel free to start a >>> thread on this. It's quite difficult to switch if you want binary >>> compat. It would affect system calls on the upgrade path and is >>> among the hardest types to change if you have any kind of legacy to >>> support... >> >> This is one of the two reasons I believe we should deprecate 32-bit. >> Even supporting 32-bit compatibility long term is unsustainable. It >> is not worth the effort. >> >> Putting a stake in the ground to say we no longer support 32-bit >> after 2038 would be desirable. (Sooner the better though.) > > Only i386 has a 32-bit time_t. Other 32-bit arches either began life > with 64-bit time_t or have been switched to it. Linux compat has even more 32-bit types and even 16 bit types, for types that FreeBSE enlarged 26 years ago with 4.4BSD-Lite.. Better axe that too. Also COMPAT_FREEBSD*. > For i386, if its current users (and I am one, for $work) have a choice > between "As of date X there will be no more i386" and "As of date X we > switch time_t to 64 bits and you will not be able to run old binaries > after that" I suspect people would choose the latter. I would choose to actually use 32-bit (unsigned) time_t. This works unitl 2106. Unfortunately, it doesn't work before or soon after the Epoch (1970). POSIX doesn't require physical times before the Epoch to work, but FreeBSD userland (tzcode) supports such times, and even for POSIX small times that want to be negative occur after adding negative timezone offsets. Data structures are affected too. All ffs1 file systems (on all arches in FreeBSD) break in 2038 since file times are int32_t in ffs1. Delaying this breakage by changing to uint32_t is relatively trivial since there are no offsets and few instances of the error value -1 to worry about. Only support for times before the Epoch would be lost. Bruce From owner-freebsd-arch@freebsd.org Mon Oct 7 12:27:38 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C6A9812DEF5 for ; Mon, 7 Oct 2019 12:27:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n09k4cTFz3x29; Mon, 7 Oct 2019 12:27:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4F3431EEFE; Mon, 7 Oct 2019 12:27:38 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id A0CE5A0FB; Mon, 7 Oct 2019 15:27:34 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: New CPUTYPE default for i386 port To: Warner Losh , "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABtCFMZXYgU2VyZWJy eWFrb3YgPGxldkBGcmVlQlNELm9yZz6JAlYEEwEIAEACGwMHCwkIBwMCAQYVCAIJCgsEFgID AQIeAQIXgBYhBPltHKC19DGLZ0szCuqwPFi/3EePBQJb/TeXBQkPBbfGAAoJEOqwPFi/3EeP LtEQANQLS89OCDSnLDZLyCj7sH5GZbTikJp9Or2McqEOpjgtfY/OgqCe7lfo8f71tTN3gL2t VGtNEtsl6CqKeBdm6fqsetCAed2+waJfbXLZWReLRSFQJ/cbof8MB3h/uEw8Zng1ZbyEU0eG rc41Mhk8bTfxjNRjkXDbp0+2xug+eRr2RYhiY2SxH+iy57AbRIu9gkjfL05VztfvsV5dPxt7 +reHf2Vhtu+qCRtCytGQqDvYWGpVZ8U5fHJxFdsJpn66LAe8w+iRGCbppB5TKeHkqWqDb++u sd5ZHzwep/7qcLBeKggi8+a2C3J1J4TpYBwdPgusrGtBPf2EYSTc/0mW5j86g1l8UDN9qXAI FvWbKf22p5SlYUzf5qRLny4ZdDl1mH13lmJV7ZkZGMKnt0IjJ2x0LRgLGhiSm/D4Lh8yc/MX uhj9BB020XbWcMUPpA7S7YaWeIXbnK3NrPU0yk77prFJblfskOwuaxJIwa2mX+cCAQA95As5 2talifo4Kh8OLSvS1gpbMo64LllTzuGbCWuKecH3fpMlZlD7/10z9lBvkSXA7KgadDfN0yHO xGCK8KE9gXXmEVRlbgGDYOJw9FLWHuSZHUvQTkmr4goXrmMIKa9A4BKO3s9vowP4pJ0vp3kz MIBeEwKSvAeZZfgKbIKggKUuQ5gsAqvF360sG3+UuQINBFKbGksBEAC0a9wfjo2P3JyT7Lc+ QlbFVshGbSbazb4ma7QYG5IZZD5vfLBFkePoG6cnrn3WCXp4A43hszAynCwe4eXyAkv4+gPF 3ZSeNE5Wz3zYG+jh2nm2iGCkyaVykfbA+2chor2DKH5tHpuNMBlF+wSJHZKJmlo/sFIktAnV 1NBVg4/cL+9/hIpvl82cl3hYCD7/e7/qRE+w38CpAAzn65FvbODn7xlY3fsJt+cHPBJ4EBM9 KnTwcce+F+72RQMZQEl7vIAwSRmLdgZHN0MFC533l62SVoKjT0eaOOIBrvesmojhWjfwugib Xr+WRF/tGcW77Bxwe2eQLbEVESqWeMORxRxocx7Q7aACoHmf4G4U1Vzx7zUEfNfHjfjZeQVf AURf/MoUelZSW/BmMIfKCg3lRlWAt+Pq2h2UADPVqAZze45beE/c8z8LZsOZiGoRhYL8NSg6 +ziLTdmYLWdtFGAuZhqOtNp5h6tGj21OksBotcaIa5YjbCmmnImIjGlSBkUKvIhq/RXth5b2 gNwaQdu+Yv4AlZVHRsuVywL/skDFL5+We11bDK6MQ5PzvmntRJcgbyoisn1hiV04OV1LpJJM kJn1j8VlBqDQNT/z+BjB0ru/0anv+5uLj7v0ck06rEo4yiXT/ZAcBM76j7V7FaGbkoba6bUU CQ2H5YYBOKpikjCnpwARAQABiQI8BBgBCAAmAhsMFiEE+W0coLX0MYtnSzMK6rA8WL/cR48F Alv9N7IFCQ8Ft+cACgkQ6rA8WL/cR49wpw//W7QrZHKYUWEVHtPLVMlcM1f7MgwnYlIRe/I6 gykwvt87sqxSYu7eHxfX6JZR2M9UYuUYscSR57gxXKu2Uzqaz2KjvEIXJCwCTsuXZjkQ19oL hAPsucw2AcMI6YqPXbZ7hO0Mh8jMeJzD6vDvx3zvunQxGQoZKxr3BvRUyO7NCYbA7N8ccI3E Tmdjj9JTbtue9WaUeGLszFDiITmkASBdsK07y4ylLAJzUGCvYLBU3gx0bBOB2S8SbxHYmQlj ewjovbp+MbT+CoXNxZp+gDRModGyIMdRIotkRiDbgNl0VWIT0SS1GUUlUHKzQ/ZPUvpvk6Gq s/SYBS7rBQNSoXXmJxNW6I6atVNW7JhInC1tkHxBlbpik4FK07J6NHFTx+9ygyCxbxwNA/Le FGkL3kU0VFXR2dNiAVbeueUPF6tU5Bye5ftgpLKOSAbo1g++EKUkc8335/4oYRBMcGEk4xUr NAvzoFPhA2W3KtklruJ9ThrFt9+//NB5ySlVgTwGWMuBJoskEmNOTBv34/UQPUIuE4xSwy6y H+nRQJooiMFo5QCosslJPlwyV63NS9lYXB6n3QWOCP6sFdWACNUCOFv4uk7LQdY9BsCmt2Tk cLuHmoS+fvUesQXnYV2aQi9HciriPIj2gvJ6WjgiaC/PpePil0fzyrfG/JMyHL0qcgmYoj0= Organization: FreeBSD Message-ID: <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> Date: Mon, 7 Oct 2019 15:27:28 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eQXKxTOS838i5jK00ACo08KHk8jB2f57e" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 12:27:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eQXKxTOS838i5jK00ACo08KHk8jB2f57e Content-Type: multipart/mixed; boundary="4t0zTev5V9wTkV14kOcW5eknphzDlNiEq"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Warner Losh , "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org Message-ID: <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> Subject: Re: New CPUTYPE default for i386 port References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> In-Reply-To: --4t0zTev5V9wTkV14kOcW5eknphzDlNiEq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06.10.2019 6:54, Warner Losh wrote: > There are two issues here. First, the pentiums under ~200mhz don't supp= ort > booting off of CDROM. Second, most of the Pentium chipsets couldn't use= > more than 64MB, so often that was the max you could get. Pentium Pro in= > that era did more memory, but it was the first i686. Pentium II were a > different story as well. Both often were provisioned with 128MB or more= =2E There are embedded devices, like AMD Geode, which could be loaded with enough memory, but is not fully i686. Soekris Net5501, anyone? --=20 // Lev Serebryakov --4t0zTev5V9wTkV14kOcW5eknphzDlNiEq-- --eQXKxTOS838i5jK00ACo08KHk8jB2f57e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAl2bLzRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R481BxAAwHBZT/yKMSe/yeoVr5YdWEly//7pqzU6dwsnN2cdnoXGAS6ZZLPmINyC nXkstrxJj7xurDxZ0wMVCP7XTeuByLkvasxrEtQPn2WzLDwv2l1eNt6LRyylhR+/ cKzbOG1VoIsKwp9NLZDwx/89Xp+/Brb3o6Qg//lOP5s3wvIW2NWd//6N51Cmhkee j+LQ/9Wn7uUdjNkHJtYiRN1WY6nbL10sGGhasNtvKGEK3YJF1hFIaQ5deFxGXUdK 8ODZrzdbfLQqmsAGg61Lz28/7OulHdYOoCaYBNamxKZd4fAtcJ5H8YewVme08Oqi v88GGuzG/M1YHMpjszW0+abndq88Sdtd9KfS6ZYpHskkMoYQNZqW6TTgd4bg6fT7 JCuq4ncCsQcDGTPFf/eEhOyF3HhXOewQbSh3Rr4bVmKIEPX+R/HmJJ6nYcG1DGb8 /LzSKbeJGEhb5UtrmrOL7127QF8pPJ3cIDGx1OzaAKg/2RQ9NUvYkefGkRcMtxFg OR4MP0sFRSWfaJxMyJS5rsdcK2bRc+NSus+dENqMQrUnQqwjFEcHMl/BsEzSgm3J oyvAm6kM9UUQOmzCDGIPp66BCFtahq9kWqY+89VkDE25hCwt/vnn0SIhnhSrZKXO WA8wdwTIci0qUw67HcLFv4mhaHHZcJFkgSUYCAdNyv0bKPuLVHo= =+2uh -----END PGP SIGNATURE----- --eQXKxTOS838i5jK00ACo08KHk8jB2f57e-- From owner-freebsd-arch@freebsd.org Mon Oct 7 13:18:48 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2179212F2E9 for ; Mon, 7 Oct 2019 13:18:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n1Jk3zjsz41Hr for ; Mon, 7 Oct 2019 13:18:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x833.google.com with SMTP id w14so19014308qto.9 for ; Mon, 07 Oct 2019 06:18:46 -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=E810rhpdUPzd8mMa1CAmKLGziMVbw44I33FAvePQGho=; b=mGShQicQCfL6cKhYnORH8lUBUp/Q6TQorsxjWOjvMxEOjocKDeb8TVzGyevgOIAj5C UPYk2nkrSRc6w0e3G98v5stzn6wtwzW2Eb4FJ/n+riZwRWWsTFl99FnP+njAYTUPWncV aYsaynn2zkxYHVjME0hllFHwciOAUDzXGJ43iWFhchDXp1aOKLYgMGmBOv2Jd2o9Bl2Q uvo8rA/ISngvoHRJ+UNSp34Pmk5YC+TvwIKelb9nu566EEpkFW6HN4s7sT4f9g7qBOKj kGXgObF8htGC7a3vXVV8CwlqQJwkHHSLRwHfD5S7SEt0XHIu0oLXmmKQ3rO7rHKd4HKd 3w0Q== 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=E810rhpdUPzd8mMa1CAmKLGziMVbw44I33FAvePQGho=; b=UCFJIHJa0aTz08/Vb4E+86YvR+WGWtaexxp2hiWgmiuOvcmEX5G5wwabUyzWJBtT/3 ckavlUTLCv9UgEPjkQhuXfO5gTIO/dEPPIKbeFwLOX6uzBDr2KaJzZbeUmebkKc3tZot xHQOl9SixA5j9ZASXnUByUCizANxI1FIWgarok5xwzG3l7OBSP31LVYQo3ViknDk+B1F qK7HcSRIL3Cf8DgbnS5H3la/SX4JJ4ne5dada2KwqwnuELogPTOSON23ivyCZfoQ+rzK ukpvYiVi3gt/tVlu27DgaVvXFZZUQ5jJ4SoJDt8ojBoOO/cehm/r4WKQFRlsH8zdmmXa r2hQ== X-Gm-Message-State: APjAAAWNZptdJLkpBGUGrLn2R9PzBvqKafEwNoW8BJni+1NMkWc+p+lf ZwOVUNSXtL4GcyTnhex07OaCzQd1i71EEtMIRJqcDg== X-Google-Smtp-Source: APXvYqwZEqkTYgpW8acw+1DgkZ/AFbEkVCBPVWdZHdWGrDD6GIZpputMFllKUSxSIJ9vvrbuGuVytB4Bmt0ZDyUtHgQ= X-Received: by 2002:ac8:44c9:: with SMTP id b9mr29654372qto.175.1570454324891; Mon, 07 Oct 2019 06:18:44 -0700 (PDT) MIME-Version: 1.0 References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> In-Reply-To: <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> From: Warner Losh Date: Mon, 7 Oct 2019 07:18:33 -0600 Message-ID: Subject: Re: New CPUTYPE default for i386 port To: Lev Serebryakov Cc: "Rodney W. Grimes" , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 46n1Jk3zjsz41Hr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=mGShQicQ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::833) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.81 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[3.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.81)[ip: (-9.29), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-2.14), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 13:18:48 -0000 On Mon, Oct 7, 2019, 6:27 AM Lev Serebryakov wrote: > On 06.10.2019 6:54, Warner Losh wrote: > > > There are two issues here. First, the pentiums under ~200mhz don't > support > > booting off of CDROM. Second, most of the Pentium chipsets couldn't use > > more than 64MB, so often that was the max you could get. Pentium Pro in > > that era did more memory, but it was the first i686. Pentium II were a > > different story as well. Both often were provisioned with 128MB or more. > There are embedded devices, like AMD Geode, which could be loaded with > enough memory, but is not fully i686. > > Soekris Net5501, anyone > Yes. There are a few exceptions to the rule of thumb I gave. And for the old embedded gear that people still have knocking around, the won't be able to use released images but will need to roll your own. The support isn't being removed, just the default target is being upped. Can we still boot the release images on these boxes anyway? When I built my Solaris box, I used nanobsd... Warner -- > // Lev Serebryakov > > From owner-freebsd-arch@freebsd.org Mon Oct 7 14:09:08 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54BD113038B for ; Mon, 7 Oct 2019 14:09:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46n2Qq1N35z43lQ; Mon, 7 Oct 2019 14:09:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id DE2BA1AF403; Mon, 7 Oct 2019 14:08:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x97E8w3l018252 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Oct 2019 14:08:58 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x97E8veQ018251; Mon, 7 Oct 2019 14:08:57 GMT (envelope-from phk) To: lev@FreeBSD.org cc: Warner Losh , "Rodney W. Grimes" , freebsd-arch@freebsd.org Subject: Re: New CPUTYPE default for i386 port In-reply-to: <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> From: "Poul-Henning Kamp" References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18249.1570457337.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 07 Oct 2019 14:08:57 +0000 Message-ID: <18250.1570457337@critter.freebsd.dk> X-Rspamd-Queue-Id: 46n2Qq1N35z43lQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.975,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.08), ipnet: 130.225.0.0/16(0.11), asn: 1835(0.15), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 14:09:08 -0000 -------- In message <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org>, Lev Serebry= akov writes: > Soekris Net5501, anyone? Not much longer I think. I only have one 5501 left in production and that is slated for replacement in a matter of weeks. All the other ones have been replaced once they started getting unreliable. The 4801s, on the other hand, seems to be indestructible... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Mon Oct 7 16:30:41 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F8C613378A for ; Mon, 7 Oct 2019 16:30:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n5Z82Mhhz4FXq for ; Mon, 7 Oct 2019 16:30:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id o12so20097099qtf.3 for ; Mon, 07 Oct 2019 09:30:40 -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=ffT5/TSmAyKq/DkusCaiFvAyq92TWO856pmWHUxE4O0=; b=A4rZ1UUAFKRcVfNpfkK8NT8jSZ7oExdipDVF4Xygu0hDELnsnazA9+CrlQBErKusMa C34ObLjWnB+mgxlsuScO4+59FmPwOYjzwwdWRQuNDrNEBVsGU+Wm6NJyGpZayPuWsQEO BDGHN33hSPs9qUxRUhs89KFUrWF2TphiuLhA08aRcgkTjwgApz+kISEi5fqdvDw/hCQp XGALPf35M42u6UR9hHyTcZnYkZGTOq7A9KzYjjVy8tAbRjcGEGzJ61H148pn+ElSamJ8 /6R3CXGPtxQ3xVDJirbd4jkl70qCXIXN9MIsIrzJFcC2s518xrDRoSDajb31panBdiSQ xZyA== 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=ffT5/TSmAyKq/DkusCaiFvAyq92TWO856pmWHUxE4O0=; b=NqbmveH5JBsYrpWdgVLnnQ2eHi0Zps5aIfLV5w7c4OWaJEAMOsgRkoV5Bwqv5DdsKz ZwbgT7nOD/oU0MWpPsdYijCDHwsObnqoqQw4M9wMSjd6Tz94McP+Aha+jQDMJ3ecOwaI iyfPYBxRs0FmCG67RnImOyoF2FyzwUY8TcEXJILTB3Aw+1lgV89Vafrvj0VlogEQt1O8 EcuV0pfoo7VJ2Jm4jSeYgGvTSqIIR7n2IK4ZF27tk7JTJFDWKgRc+VUvwAWnMkRV8DPa 90B77VmOdRpxFLQw6Jm6xKrmUWh3ybx1Br0BOlGdZAHxe0ggGe5cWEIG74AnAY26gC/1 rTPA== X-Gm-Message-State: APjAAAV0FtHpyPZ1Bi42FtSf1+7hWGGxxXTufi8GVPr+u8ytRT7JxNaF rhS4i3lu0aP9LYecBGbERlSSKlPafoF3v1uBIm7HCw== X-Google-Smtp-Source: APXvYqxDbrrNVwik/4gh8St5Q+Nzl+vgPvnQBLYZSXcVSdxJF2akvOm0RcgEdDGTYOCTwJhavFpYeX/EsDaYTXrDdkA= X-Received: by 2002:a0c:9952:: with SMTP id i18mr16109464qvd.202.1570465838350; Mon, 07 Oct 2019 09:30:38 -0700 (PDT) MIME-Version: 1.0 References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> In-Reply-To: <18250.1570457337@critter.freebsd.dk> From: Warner Losh Date: Mon, 7 Oct 2019 10:30:27 -0600 Message-ID: Subject: Re: New CPUTYPE default for i386 port To: Poul-Henning Kamp Cc: Lev Serebryakov , "Rodney W. Grimes" , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 46n5Z82Mhhz4FXq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=A4rZ1UUA; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.81 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.81)[ip: (-9.31), ipnet: 2607:f8b0::/32(-2.54), asn: 15169(-2.14), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 16:30:41 -0000 On Mon, Oct 7, 2019 at 8:09 AM Poul-Henning Kamp wrote: > The 4801s, on the other hand, seems to be indestructible... > So the question we need to answer, that Rod brought up, is "Are there enough machines that can boot FreeBSD release images that would otherwise fail with some weird error that we need to deploy counter measures"? I did a survey of the old 'desktop / server' hardware available on EBAY. If you look at all Pentiums, then the number of machines that (a) are new enough to support CDROM booting and (b) have enough memory are << 1% (I found 1 out of 250 that I looked at). So from that perspective, things are fine: machines that might be able to boot today's 13 snapshots are quite rare in this space.... rare enough to not worry apart from release notes. There's likely some level of error in this survey, but the bound of uncertainty here is such that more accurate data likely wouldn't change the conclusion. However, there's a number of embedded products that were so popular in the community that there might be people that want to run 13.0 when it is released. That's a fair point that I'd not considered. The question becomes: are people using only the release images on these boxes? Or are they rolling their own? If they are rolling their own, release notes is all that's needed. If they are using the release images, then we may want to give at least some warning. These machines are MBR/GPT BIOS booted. So we could put a warning into boot2 (maybe room), gptboot (plenty of room) or cdboot (has room) that would trigger on 486 and 586 machines. I'd want to turn it off were I deploying these machines, or off in general outside the release env. It would limit the amount of code we'd have to compile specially, but would be the most reliable way of getting a message to any affected user. That's likely the best we could do here. Warner From owner-freebsd-arch@freebsd.org Mon Oct 7 16:50:29 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE4EA133ECF for ; Mon, 7 Oct 2019 16:50:29 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n6110ypZz4H2X; Mon, 7 Oct 2019 16:50:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id x97GoJte053857 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Oct 2019 09:50:20 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: New CPUTYPE default for i386 port To: Warner Losh , Poul-Henning Kamp Cc: "Rodney W. Grimes" , Lev Serebryakov , "freebsd-arch@freebsd.org" References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> From: Julian Elischer Message-ID: <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> Date: Mon, 7 Oct 2019 09:50:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.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-Rspamd-Queue-Id: 46n6110ypZz4H2X X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.69 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.69)[-0.689,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 16:50:29 -0000 On 10/7/19 9:30 AM, Warner Losh wrote: > On Mon, Oct 7, 2019 at 8:09 AM Poul-Henning Kamp wrote: > >> The 4801s, on the other hand, seems to be indestructible... >> > So the question we need to answer, that Rod brought up, is "Are there > enough machines that can boot FreeBSD release images that would otherwise > fail with some weird error that we need to deploy counter measures"? > > I did a survey of the old 'desktop / server' hardware available on EBAY. If > you look at all Pentiums, then the number of machines that (a) are new > enough to support CDROM booting and (b) have enough memory are << 1% (I > found 1 out of 250 that I looked at). So from that perspective, things are > fine: machines that might be able to boot today's 13 snapshots are quite > rare in this space.... rare enough to not worry apart from release notes. > There's likely some level of error in this survey, but the bound of > uncertainty here is such that more accurate data likely wouldn't change the > conclusion. > > However, there's a number of embedded products that were so popular in the > community that there might be people that want to run 13.0 when it is > released. That's a fair point that I'd not considered. > > The question becomes: are people using only the release images on these > boxes? Or are they rolling their own? > > If they are rolling their own, release notes is all that's needed. > > If they are using the release images, then we may want to give at least > some warning. These machines are MBR/GPT BIOS booted. So we could put a > warning into boot2 (maybe room), gptboot (plenty of room) or cdboot (has > room) that would trigger on 486 and 586 machines. I'd want to turn it off > were I deploying these machines, or off in general outside the release env. > It would limit the amount of code we'd have to compile specially, but would > be the most reliable way of getting a message to any affected user. That's > likely the best we could do here. I think the answer is that as long as we can still generate the images, the default is not so important. But the size of system needed to actually generate such a system with the modern compiler etc may make self hosting a bit of an issue. Unfortunately I deleted the very first post in the thread, so I can't remember the reason he gave but I presume that the usual reasons apply.  Compiling as a pre-pentum results in reduced performance for any machine built inthe last 20 years. The only comment that I haven't seen made is that pre-686 class machines are possibly not dropping as a percentage f 32 bit chipsets as nearly all machines sold for desktop/taptop use these days are 64 bit, meaning that 32 bit is limited to embedded, and I can not say what percentage of modern 32 bit systems are the ultra-low power pre-686 types, as I have not been following that market. I run a soekris 5501 but i do have alternatives, and it is running 9.1 I think. I have no real plans to massively upgrade it, and if I did I would not compile on that.. it would take a month including ports. Julian > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Mon Oct 7 17:20:18 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A00D134BDD for ; Mon, 7 Oct 2019 17:20:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n6gP43LCz4Jg5 for ; Mon, 7 Oct 2019 17:20:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id r5so20389378qtd.0 for ; Mon, 07 Oct 2019 10:20:17 -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=ha0xRko8pTfa/KkFgHaBmtdvfvbuSXqYQAkiqgJYOPM=; b=YyQoUXj7om+wYUfbqw+JQYkiDycQgptiiZjsr7QYs+TcGl3+MXjHiZZVAJGv6ir11T b0DTLnUIsZc9vC8wiJOE2Ha1z9fXhLg2vrUF8cHPcqNWBbs9wkoz9RWOsJttGC8WsXPE MVxy+kqodA4CJiBzhBGvx7y8/HhtGf/FFiAnFIcbcW8HflMcepoQiJ7e2Gx7nm3sv3iN u8Z26XHjHtQfsqOVQyzmAKAiXoPsyMheYXRtSsqYx2u+MVqpcI3cjjI6EivX68m3STS4 L+gDWedoao9Jsn3sl/QoApGYAPL7kkfJo36VKFuSwTmWR9P0ZQr50WlgklJvuCZkKTDL NjxA== 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=ha0xRko8pTfa/KkFgHaBmtdvfvbuSXqYQAkiqgJYOPM=; b=Ro17KNC6SExWcXJNFK9wzm0RY4kZjT59ydupXO87jg1KC4nCG2GFMoRvvNG2uSfhAY D1vbam4MePV4SrrGkU7V3nhlG3e2X0gBeZIStx2JXWEm5GOVIrsn6qF9Ew9EJM2orKsE x/ubLTMSaxY7tCWxjItU0uvXLrbF7/4G4Vd46y5wQLI3F6YWlmUDg2hs4uaHq/afRJXg 5uBlm4yYBjQsovoN0eD0hk/uu7r7ZXlYGhsWZkGK3WZrMxjF0G2nAKag3/YJfQrOYSFV X2FbtXg8r0uPAKsxoPmjz5kBz9gGPsEI+J16UCNbe0CpesuiGqY2+sc81SOXjVSBr5cg TNyQ== X-Gm-Message-State: APjAAAVRswNQJAzFwWCSHSCko0zKVy57hOUTFtvTwhn3sisuGzycGmIh Ss+rzEci6hsO6onWylCzL5yOYbeaTeeQS2zZI5bn6Q== X-Google-Smtp-Source: APXvYqzrzskgJ5OrZFg61LXXxq83XzzadDHB+ymrNyQGguE/33k9g9nuTshzqrRdWy/p4pW+qqyOFfrY2fln36mndSg= X-Received: by 2002:ac8:44c9:: with SMTP id b9mr31074338qto.175.1570468816341; Mon, 07 Oct 2019 10:20:16 -0700 (PDT) MIME-Version: 1.0 References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> In-Reply-To: <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> From: Warner Losh Date: Mon, 7 Oct 2019 11:20:05 -0600 Message-ID: Subject: Re: New CPUTYPE default for i386 port To: Julian Elischer Cc: Poul-Henning Kamp , "Rodney W. Grimes" , Lev Serebryakov , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 46n6gP43LCz4Jg5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=YyQoUXj7; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.81 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.81)[ip: (-9.31), ipnet: 2607:f8b0::/32(-2.54), asn: 15169(-2.14), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 17:20:18 -0000 On Mon, Oct 7, 2019 at 10:50 AM Julian Elischer wrote: > On 10/7/19 9:30 AM, Warner Losh wrote: > > On Mon, Oct 7, 2019 at 8:09 AM Poul-Henning Kamp > wrote: > > > >> The 4801s, on the other hand, seems to be indestructible... > >> > > So the question we need to answer, that Rod brought up, is "Are there > > enough machines that can boot FreeBSD release images that would otherwise > > fail with some weird error that we need to deploy counter measures"? > > > > I did a survey of the old 'desktop / server' hardware available on EBAY. > If > > you look at all Pentiums, then the number of machines that (a) are new > > enough to support CDROM booting and (b) have enough memory are << 1% (I > > found 1 out of 250 that I looked at). So from that perspective, things > are > > fine: machines that might be able to boot today's 13 snapshots are quite > > rare in this space.... rare enough to not worry apart from release notes. > > There's likely some level of error in this survey, but the bound of > > uncertainty here is such that more accurate data likely wouldn't change > the > > conclusion. > > > > However, there's a number of embedded products that were so popular in > the > > community that there might be people that want to run 13.0 when it is > > released. That's a fair point that I'd not considered. > > > > The question becomes: are people using only the release images on these > > boxes? Or are they rolling their own? > > > > If they are rolling their own, release notes is all that's needed. > > > > If they are using the release images, then we may want to give at least > > some warning. These machines are MBR/GPT BIOS booted. So we could put a > > warning into boot2 (maybe room), gptboot (plenty of room) or cdboot (has > > room) that would trigger on 486 and 586 machines. I'd want to turn it off > > were I deploying these machines, or off in general outside the release > env. > > It would limit the amount of code we'd have to compile specially, but > would > > be the most reliable way of getting a message to any affected user. > That's > > likely the best we could do here. > > I think the answer is that as long as we can still generate the > images, the default is not so important. > That's my position :) > But the size of system needed to actually generate such a system with > the modern compiler etc may make self hosting a bit of an issue. > Unfortunately I deleted the very first post in the thread, so I can't > remember the reason he gave but I presume that the usual reasons > apply. Compiling as a pre-pentum results in reduced performance for > any machine built inthe last 20 years. The only comment that I haven't > seen made is that pre-686 class machines are possibly not dropping as > a percentage f 32 bit chipsets as nearly all machines sold for > desktop/taptop use these days are 64 bit, meaning that 32 bit is > limited to embedded, and I can not say what percentage of modern 32 > bit systems are the ultra-low power pre-686 types, as I have not been > following that market. > We've seen a *HUGE* drop-off in the 32-bit i386 vs 64-bit amd64 kernels as reported to external databases I can query in the past few years. It's clear that a substantial majority have been replaced in the past 5 years. It's to the point that i386 is in the ~10% of amd64 range and falling fast. Getting more nuance than that, however, is hard given we have no good data sources. I've not done a CPU analysis over time, but I suspect that the percentage of 586 class CPUs in that shrinking sliver is <<1% and likely <0.1%, with 486 class machines being 100x rarer (1 machine in 2018 running 4.3 and the other machines are > 10 years old: 2 whistles running 7.0, 1 soekris 4511 and one 486 frankenstein in 2004). Quick numbers show 8 586 dmesgs (ALX or Soekris) in the last 3 years in nycbug database, and maybe 70-80 i386 machines and maybe 800-1000 amd64 boxes (didn't actually count, but estimated). NYCBUG data tends to exaggerate the snowflakes popularity due to its nature of being a place to upload the weird and unique machines (rather than all of them). But even so, these machines are somewhat rare among the rarities. The data suggests that we could turn off 486 entirely and nobody would notice. > I run a soekris 5501 but i do have alternatives, and it is running 9.1 > I think. I have no real plans to massively upgrade it, and if I did I > would not compile on that.. it would take a month including ports. > Yea. We've not been quickly self-hosting on this class of machines since the move to clang. I have a 32-bit laptop with a ~1GHz Pentium-M and 512MB of ram that takes ~36 hours to do a buildworld and another 2 hours or more to do a build-kernel. And that machine is quite a bit beefier than the Soekris 5501... :( Warner Julian > > > > > Warner > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > > From owner-freebsd-arch@freebsd.org Mon Oct 7 17:36:17 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1E1C1351AA for ; Mon, 7 Oct 2019 17:36:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46n71r1Q5Rz4KpS; Mon, 7 Oct 2019 17:36:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id DFDAD1AF403; Mon, 7 Oct 2019 17:36:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x97HaDCJ019311 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Oct 2019 17:36:13 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x97HaCHZ019310; Mon, 7 Oct 2019 17:36:12 GMT (envelope-from phk) To: Warner Losh cc: Julian Elischer , "Rodney W. Grimes" , Lev Serebryakov , "freebsd-arch@freebsd.org" Subject: Re: New CPUTYPE default for i386 port In-reply-to: From: "Poul-Henning Kamp" References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19308.1570469772.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 07 Oct 2019 17:36:12 +0000 Message-ID: <19309.1570469772@critter.freebsd.dk> X-Rspamd-Queue-Id: 46n71r1Q5Rz4KpS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.88 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.07)[ip: (0.08), ipnet: 130.225.0.0/16(0.11), asn: 1835(0.15), country: EU(-0.01)]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 17:36:17 -0000 -------- In message , Warner Losh writes: >Yea. We've not been quickly self-hosting on this class of machines since >the move to clang. I have a 32-bit laptop with a ~1GHz Pentium-M and 512M= B >of ram that takes ~36 hours to do a buildworld and another 2 hours or mor= e >to do a build-kernel. And that machine is quite a bit beefier than the >Soekris 5501... :( Last I tried on a 5501 bw+iw+a couple of trivial sized ports took 10 days, and that was with a good SSD, most of that time were spent on clang compiling C++ code. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Mon Oct 7 18:08:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4BE80135DBE for ; Mon, 7 Oct 2019 18:08:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n7l01LXLz4N4y; Mon, 7 Oct 2019 18:08:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id x97I8OV0054105 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Oct 2019 11:08:25 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: New CPUTYPE default for i386 port To: Poul-Henning Kamp , Warner Losh Cc: "Rodney W. Grimes" , Lev Serebryakov , "freebsd-arch@freebsd.org" References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> <19309.1570469772@critter.freebsd.dk> From: Julian Elischer Message-ID: <6c05c108-f002-4116-2953-f8c11695fe66@freebsd.org> Date: Mon, 7 Oct 2019 11:08:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <19309.1570469772@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 46n7l01LXLz4N4y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.68 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.68)[-0.684,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 18:08:28 -0000 On 10/7/19 10:36 AM, Poul-Henning Kamp wrote: > -------- > In message , Warner Losh writes: > >> Yea. We've not been quickly self-hosting on this class of machines since >> the move to clang. I have a 32-bit laptop with a ~1GHz Pentium-M and 512MB >> of ram that takes ~36 hours to do a buildworld and another 2 hours or more >> to do a build-kernel. And that machine is quite a bit beefier than the >> Soekris 5501... :( > Last I tried on a 5501 bw+iw+a couple of trivial sized ports took 10 days, > and that was with a good SSD, most of that time were spent on clang > compiling C++ code. > > my 5501 has just an SD card :-)   so.. possibly a month is conservative. I sort of like the linux configurator that asks you questions so that you don't need to know the magic incantations to do all the options.  But certainly the default can go as long as it's really easy to find the right way to make it. No-one runs a standard build on those machines. Or at least not a CURRENT standard build. From owner-freebsd-arch@freebsd.org Mon Oct 7 18:10:00 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 230DB135E8C for ; Mon, 7 Oct 2019 18:10:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46n7mm09l8z4N9R; Mon, 7 Oct 2019 18:09:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id x97I9upt054113 (version=TLSv1.2 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Oct 2019 11:09:57 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: New CPUTYPE default for i386 port To: Warner Losh , Poul-Henning Kamp Cc: "Rodney W. Grimes" , Lev Serebryakov , "freebsd-arch@freebsd.org" References: <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> From: Julian Elischer Message-ID: Date: Mon, 7 Oct 2019 11:09:51 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.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-Rspamd-Queue-Id: 46n7mm09l8z4N9R X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.68 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.68)[-0.684,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 18:10:00 -0000 On 10/7/19 9:30 AM, Warner Losh wrote: > On Mon, Oct 7, 2019 at 8:09 AM Poul-Henning Kamp wrote: > >> The 4801s, on the other hand, seems to be indestructible... >> > So the question we need to answer, that Rod brought up, is "Are there > enough machines that can boot FreeBSD release images that would otherwise > fail with some weird error that we need to deploy counter measures"? SO we'd be "demoting" then to the same situation as the ARM64 port where one has to build it yourself. not so bad > > I did a survey of the old 'desktop / server' hardware available on EBAY. If > you look at all Pentiums, then the number of machines that (a) are new > enough to support CDROM booting and (b) have enough memory are << 1% (I > found 1 out of 250 that I looked at). So from that perspective, things are > fine: machines that might be able to boot today's 13 snapshots are quite > rare in this space.... rare enough to not worry apart from release notes. > There's likely some level of error in this survey, but the bound of > uncertainty here is such that more accurate data likely wouldn't change the > conclusion. > > However, there's a number of embedded products that were so popular in the > community that there might be people that want to run 13.0 when it is > released. That's a fair point that I'd not considered. > > The question becomes: are people using only the release images on these > boxes? Or are they rolling their own? > > If they are rolling their own, release notes is all that's needed. > > If they are using the release images, then we may want to give at least > some warning. These machines are MBR/GPT BIOS booted. So we could put a > warning into boot2 (maybe room), gptboot (plenty of room) or cdboot (has > room) that would trigger on 486 and 586 machines. I'd want to turn it off > were I deploying these machines, or off in general outside the release env. > It would limit the amount of code we'd have to compile specially, but would > be the most reliable way of getting a message to any affected user. That's > likely the best we could do here. > > Warner > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Tue Oct 8 09:28:12 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5DEC71413B6 for ; Tue, 8 Oct 2019 09:28:12 +0000 (UTC) (envelope-from 0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com) Received: from b230-172.smtp-out.eu-west-1.amazonses.com (b230-172.smtp-out.eu-west-1.amazonses.com [69.169.230.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46nX8B1lZFz4fD5 for ; Tue, 8 Oct 2019 09:28:10 +0000 (UTC) (envelope-from 0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=3cplnviw2evbq5mtsigkvse7zwbsh5h3; d=yuman.us; t=1570526888; h=Message-ID:Date:Subject:From:To:MIME-Version:Content-Type:List-Unsubscribe; bh=eWlTBx6BrL1TmtoZ6QZqM+7xuSNuJhriCJ6L1vCWUNg=; b=Eka7k0e20sx60sl1WyybEZ8dPLJ1x2A4WZ7Hwz6drA94mXi43zOR7LJEQLXClMjd B5VmUDnsqxH403ENR4jDRVFiU43Nw2EDUaSGcjoxVfhg25mq8U/b5DHt/J131o0lw73 0eW8BBjBR2z+7qihtui7LL1l57/wEXr0uH0sJr20= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1570526888; h=Message-ID:Date:Subject:From:To:MIME-Version:Content-Type:List-Unsubscribe:Feedback-ID; bh=eWlTBx6BrL1TmtoZ6QZqM+7xuSNuJhriCJ6L1vCWUNg=; b=fDF6uwYQfj/PnSV7dUaqg63d9j6jyWWBcHFR0Ifmr8rPK6HVh69dagCKmhhF66Jg eqVxMioqCTRLfjTCU2RlMWNfi/8kXeWcMYCITko0dQBd0J/SaqvNjFd0QzRapw9cRVi eSPYGWpQCp2LCk/k5Cnn2oj4kMpQWYSBTExWgFIo= Message-ID: <0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com> Date: Tue, 8 Oct 2019 09:28:08 +0000 Subject: Invitation for YUMAN From: Vincent To: freebsd-arch@freebsd.org MIME-Version: 1.0 X-EmailOctopus-Version: 3 X-EmailOctopus-Started-Preparing-At: 2019-10-08T09:27:04+00:00 X-EmailOctopus-Ses-Configuration-Set-Name: emailoctopus-92ac08625b86fcb74e8dc6e633188d55 X-EmailOctopus-Sent-At: 2019-10-08T09:28:08+00:00 X-EmailOctopus-Parent-Type-Id: campaign X-EmailOctopus-Parent-Id: c20dc832-e9ad-11e9-be00-06b4694bee2a X-EmailOctopus-List-Id: 7f1bc218-e9ad-11e9-be00-06b4694bee2a X-EmailOctopus-List-Contact-Id: 88371413-e9ad-11e9-be00-06b4694bee2a X-SES-Outgoing: 2019.10.08-69.169.230.172 Feedback-ID: 1.eu-west-1.JI6BXWUnqSuL5cSR/HsaAGkJDrJ+yb1niJ5h//2yBCc=:AmazonSES X-Rspamd-Queue-Id: 46nX8B1lZFz4fD5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuman.us header.s=3cplnviw2evbq5mtsigkvse7zwbsh5h3 header.b=Eka7k0e2; dkim=pass header.d=amazonses.com header.s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn header.b=fDF6uwYQ; dmarc=pass (policy=none) header.from=yuman.us; spf=pass (mx1.freebsd.org: domain of 0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com designates 69.169.230.172 as permitted sender) smtp.mailfrom=0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com X-Spamd-Result: default: False [0.62 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yuman.us:s=3cplnviw2evbq5mtsigkvse7zwbsh5h3,amazonses.com:s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:69.169.224.0/20:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; HTML_SHORT_LINK_IMG_1(2.00)[]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.94)[-0.936,0]; MANY_INVISIBLE_PARTS(0.10)[2]; DKIM_TRACE(0.00)[yuman.us:+,amazonses.com:+]; DMARC_POLICY_ALLOW(-0.50)[yuman.us,none]; RCVD_IN_DNSWL_NONE(0.00)[172.230.169.69.list.dnswl.org : 127.0.15.0]; NEURAL_SPAM_MEDIUM(0.46)[0.458,0]; FORGED_SENDER(0.30)[vincent@yuman.us,0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.29)[asn: 16509(-1.40), country: US(-0.05)]; ASN(0.00)[asn:16509, ipnet:69.169.230.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[vincent@yuman.us, 0102016daab2827a-43a39952-c199-4263-9abc-b7af427ff56f-000000@eu-west-1.amazonses.com] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 09:28:12 -0000 [https://www.yuman.io/?mail=3Dfreebsd-arch@freebsd.org]=20 Yuman redefines what a CMMS should be=E2=80=8B =09=09 Start Free Trial [https://www.yuman.io/pricing?trial=3Dtrue?mail=3Dfreebsd-arch@freebsd.org] _Invitation to Yuman Advanced for 60 days _ =09=09 [https://www.yuman.io?mail=3Dfreebsd-arch@freebsd.org]=20 Plan your interventions, manage your maintenance! Mobile First, YUMAN allows managers to instantly communicate with technicians on the field and, technical teams to better deal with urgent problems, solve complex cases, collect information and share it directly. Our platform integrates PREDICTIVE, PREVENTIVE AND CURATIVE TOOLS to fully deliver the value promised by the digitalization of maintenance operations=C2=A0=E2=80=8B =09=09 [https://www.yuman.io/planning_interventions?mail=3Dfreebsd-arch@freebsd.or= g] Planning & Cartography =09=09 [https://www.yuman.io/technician_interventions?mail=3Dfreebsd-arch@freebsd.= org] Curative, Preventive, Predictive Operations =09=09 [https://www.yuman.io/maintenance_management?mail=3Dfreebsd-arch@freebsd.or= g] Maintenance & Contracts=20 _100% of Yuman customers have increased their turnover in less than 6 months=20 _ =09=09 Book a Demo [https://www.yuman.io?contact&mail=3Dfreebsd-arch@freebsd.org]=20 =09=09 [https://www.facebook.com/yuman.io/]=20 =09=09 [https://twitter.com/HelloYuman]=20 =09=09 [https://www.linkedin.com/company/yuman-io/]=20 Questions before starting ? Don't hesitate to answer to this email or contact us on=C2=A0hello@yuman.io Unsubscribe [https://arborescens.eomail1.com/unsubscribe?l=3D7f1bc218-e9ad-11e9-be00-06= b4694bee2a&lc=3D88371413-e9ad-11e9-be00-06b4694bee2a&p=3Dc20dc832-e9ad-11e9= -be00-06b4694bee2a&pt=3Dcampaign&spa=3D1570526824&t=3D1570526888&s=3D387194= a0f7e49ab9f3c7bc5f206e1499a1656c45b5b591e0cbf7258d1a97aa3e]. From owner-freebsd-arch@freebsd.org Tue Oct 8 11:33:42 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E4ABD144BFA for ; Tue, 8 Oct 2019 11:33:42 +0000 (UTC) (envelope-from leonard@thingsforsell.com) Received: from thingsforsell.com (thingsforsell.com [46.21.249.65]) (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 46nZx16H81z3K8n for ; Tue, 8 Oct 2019 11:33:41 +0000 (UTC) (envelope-from leonard@thingsforsell.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thingsforsell.com; s=default; h=Content-Type:List-Unsubscribe:Message-ID: Sender:From:Date:MIME-Version:Subject:To:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Subscribe:List-Post:List-Owner:List-Archive ; bh=rahu+zmmjA7eY9NEEsIg62qagKqZNYrO75p10qzjcr0=; b=lN5r0A7L9SpMhdkKKqinJ9rQ nMvVk6JWESa1zcBfXxmAEjLisQiSa62iPPQ28HVXieuWhvWdhCXrw0XtCaAK1RXKi4ZjWoFWhpGZh OVcvXR1RBBi3MrPvcNO9jU7u9pQ/mk3PR1RDHAqAUf2sF/TUfxrvCVwcZJ8Y7MCmA22Hlg=; To: freebsd-arch@freebsd.org Subject: New Payment Information MIME-Version: 1.0 Date: Tue, 8 Oct 2019 14:33:32 +0300 From: Perkins William Sender: leonard@thingsforsell.com Message-ID: <19857570404.482658@thingsforsell.com> X-Priority: 3 X-Rspamd-Queue-Id: 46nZx16H81z3K8n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=thingsforsell.com header.s=default header.b=lN5r0A7L; dmarc=pass (policy=none) header.from=thingsforsell.com; spf=pass (mx1.freebsd.org: domain of leonard@thingsforsell.com designates 46.21.249.65 as permitted sender) smtp.mailfrom=leonard@thingsforsell.com X-Spamd-Result: default: False [-2.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.920,0]; R_DKIM_ALLOW(-0.20)[thingsforsell.com:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; MANY_INVISIBLE_PARTS(0.05)[1]; DKIM_TRACE(0.00)[thingsforsell.com:+]; MIME_BASE64_TEXT(0.10)[]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[thingsforsell.com,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(0.51)[ipnet: 46.21.249.0/24(0.97), asn: 50340(1.56), country: RU(0.01)]; ASN(0.00)[asn:50340, ipnet:46.21.249.0/24, country:RU]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 11:33:43 -0000 SGkNCg0KWW91IGNhbiBnZXQgdGhlIGxhc3QgcGF5bWVudCBpbiB5b3VyIHRyYWRpbmcgYWNjb3Vu dC4gWW91IG5lZWQgdG8gYWRkcmVzcyB0aGlzIGluc3RhbnRseSBvciBpdCB3aWxsIGJlIHJlbW92 ZWQuDQoNCkNsaWNrIEhFUkUgVG8gQ29uZmlybSBZb3VyIFBheW1lbnQgSW5mb3JtYXRpb24gSXMg Q29ycmVjdC4gDQoNCsKgDQoNClJlZ2lzdGVyZWQgZW1haWw6IGZyZWVic2QtYXJjaEBmcmVlYnNk Lm9yZw0KDQpVc2VyIElEOiBBWTdEVFNWMkNHDQoNCg0KRW5qb3kgJiBwbGVhc2UgbGV0IG1lIGtu b3cgaG93IHlvdSBkby4NCg0KSGF2ZSBhIGdvb2QgZGF5IA0KDQpQZXRyYQ0KDQrCoA0KDQpFIE1h cmtldGVyDQoyMDIgTG93ZXIgSGlnaCBTdHJlZXQNCldhdGZvcmQNCldEMTcgMkVIIFVuaXRlZCBL aW5nZG9tDQoNCllvdSByZWNlaXZlZCB0aGlzIGVtYWlsIGJlY2F1c2UgeW91IGFyZSByZWdpc3Rl cmVkIHdpdGggTyBNYXJrZXRlci4gVW5zdWJzY3JpYmUgaGVyZQ0KDQpzd2luZyBsZWFr From owner-freebsd-arch@freebsd.org Tue Oct 8 14:46:41 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2D94112B2E3 for ; Tue, 8 Oct 2019 14:46:41 +0000 (UTC) (envelope-from dutaxe@academiadeinversionistas.org) Received: from academiadeinversionistas.org (li1538-57.members.linode.com [139.162.253.57]) (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 46ngCh1Lr1z42nN for ; Tue, 8 Oct 2019 14:46:39 +0000 (UTC) (envelope-from dutaxe@academiadeinversionistas.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=academiadeinversionistas.org; s=default; h=Content-Type:List-Unsubscribe: Message-ID:Sender:From:Date:MIME-Version:Subject:To:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Subscribe:List-Post:List-Owner:List-Archive ; bh=02JUk0pl88g4+L86B+yKjVfJaaKSa11YF0ZRFOxmY30=; b=daG1py+EN/AyIwpyxdBKw0Tn fe80ir3cp7WCFh00gRn84qRLRg/b4KZKzVeIShJ+J4a+15BlrSXRI2ubXFvCdIlixAvOl2WlLp6D9 6DsvlH8Ih//mI2Q0cXKSF1f8vW4uQPEbmvu2E1x+pB/GrROzZ8CBsBFG+W3uYwO4wQikXY=; To: freebsd-arch@freebsd.org Subject: =?UTF-8?Q?=E2=9C=8F=EF=B8=8F_Hello._I_posted_my_secret_pictures_special_f?= =?UTF-8?Q?or_you.?= MIME-Version: 1.0 Date: Tue, 8 Oct 2019 14:46:31 +0000 From: Agathe Sender: dutaxe@academiadeinversionistas.org Message-ID: <19860095793.482810@academiadeinversionistas.org> X-Priority: 3 X-Rspamd-Queue-Id: 46ngCh1Lr1z42nN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=academiadeinversionistas.org header.s=default header.b=daG1py+E; dmarc=pass (policy=none) header.from=academiadeinversionistas.org; spf=pass (mx1.freebsd.org: domain of dutaxe@academiadeinversionistas.org designates 139.162.253.57 as permitted sender) smtp.mailfrom=dutaxe@academiadeinversionistas.org X-Spamd-Result: default: False [-2.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.950,0]; R_DKIM_ALLOW(-0.20)[academiadeinversionistas.org:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[academiadeinversionistas.org:+]; MIME_BASE64_TEXT(0.10)[]; HAS_X_PRIO_THREE(0.00)[3]; DMARC_POLICY_ALLOW(-0.50)[academiadeinversionistas.org,none]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(0.29)[ipnet: 139.162.224.0/19(2.54), asn: 63949(-1.02), country: US(-0.05)]; ASN(0.00)[asn:63949, ipnet:139.162.224.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 14:46:41 -0000 aGV5LWhleSxkZWFyLiBpIHdhcyBzZWVuIHlvdSAgaW4gWHZpZGllb3MgbGFzdCBzb21lIGRheXMg YW5kIHNvIEkgd291bGQgbGlrZSB0byBtZWV0IHlvdS4NCk15IE5hbWUgTWVsaW5kYQ0KSSBDcmVh dGUgbXkgcGFnZSB3aXRoIG15IGNvb2wgcGljcy4NCklgbGwgIHdhaXRpbmcgeW91ciBwaG90b3Mu DQpteSBzZWNvbmQgbmFtZSA6IEV2YW5zNTY3Lg0KDQpDdW1tIG9uIG1lIEZpbmQgbWUgdGhlcmUu Lg== From owner-freebsd-arch@freebsd.org Tue Oct 8 15:22:12 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1F0612CFDD for ; Tue, 8 Oct 2019 15:22:12 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46nh0g74TMz463x for ; Tue, 8 Oct 2019 15:22:11 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f52.google.com with SMTP id y127so12312626lfc.0 for ; Tue, 08 Oct 2019 08:22:11 -0700 (PDT) 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:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=lwWomSUFaf+5RqXqs1b3HEV9eMcuwJnGMACcZFRQr3M=; b=IOkBPPUTV208N/6d+W+R3kZm+MEvtA5B7wdEekv7HzuqsKACzOUefmDZYaZatt1EUA HXWOGG/dEl3HkLpWQcMtL9XmPIH8JlaVISlOkfNsk/UcxP+woIFXgwycrnsREVctDb19 lGLCeVwdv01shlNKj0I7V98CvK4dIpE58qGxpOfBjsJNhbi7lKQX/IT9U9bljJ4+c6as tkUGjtwmvOaop2ItUbQ2cF8pRju8iznVfsxS1r+3K3zNAeOMY113XbOhAtz/akXMojk2 3BGwMXUU/tZVKmnQHoQuesk4B6bJSdeVpzWzShznK/I5phpbTg/afH21VHbPzj+ZNFON JLQg== X-Gm-Message-State: APjAAAWeMB+ysyN64xBRHr4/KiOvE6C6xlcdvNMXTnN8PPeRC+b4y3lu FziKCGfXI0MPRFKH0FeeAdRZ5qf3/0w= X-Google-Smtp-Source: APXvYqzVfg1gvvFTgbfi9zPtJ+XI2i5yEQsdzA9rYftWVr/gNXRf044H+NiV4R2s+N/KrwdBOlRSKw== X-Received: by 2002:a19:2313:: with SMTP id j19mr20623129lfj.138.1570548129714; Tue, 08 Oct 2019 08:22:09 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id 207sm4742796lfn.0.2019.10.08.08.22.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Oct 2019 08:22:08 -0700 (PDT) To: freebsd-arch@FreeBSD.ORG From: Andriy Gapon Subject: illumos membar_producer emulation (zfs, dtrace) Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: <28c5d9c1-740f-7832-873f-3cf03c6d94a4@FreeBSD.org> Date: Tue, 8 Oct 2019 18:22:07 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46nh0g74TMz463x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.20)[ip: (-0.55), ipnet: 209.85.128.0/17(-3.26), asn: 15169(-2.14), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[52.167.85.209.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[52.167.85.209.rep.mailspike.net : 127.0.0.17]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 15:22:12 -0000 I have got a passing interest in cleaning up of the atomic and related illumos compatibility (and contrib) code. At the moment I am looking at membar_producer. >From Oracle Solaris documentation it follows that membar_producer is a store to store barrier. https://docs.oracle.com/cd/E88353_01/html/E37855/membar-producer-9f.html I do not think that we have an MI abstraction for that, so it seems that atomic_thread_fence_rel could be the closest thing that we have. It also affects loads which is redundant but not a big deal (IMO). As of now, we have membar_producer implemented in assembly for several platforms (aarch64, amd64, i386, powerpc64, sparc64) and it's a no-op for the rest. I think that the latter is a problem as it can affect correctness of the code. Also, the assembly implementations seem to be closer to wmb() although not always the same. E.g., on amd64 both are sfence, while on sparc64 membar_producer is "membar #StoreStore" while wmb is "membar #MemIssue". I think that those implementations, maybe except for sparc64, are a bit of an overkill as the code that uses membar_producer only deals with "normal" memory. Maybe illumos uses membar_producer for access ordering of both normal memory and memory (or instructions) with special caching properties. The relevant code is in: - sys/cddl/compat/opensolaris/sys/atomic.h - sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c - sys/cddl/contrib/opensolaris/common/atomic/*/opensolaris_atomic.S So, what do you think, would it be safe to emulate membar_producer with atomic_thread_fence_rel? Or is it better to leave the current code (copied from illumos for amd64, i386, sparc64 and home-grown for aarch64, powerpc64) alone? In that case, we still need to add something for the rest of the platforms (arm-s, mips-es, riscv). P.S. A bit offtopic. I noticed a couple of uses of wmb() with stores to regular memory. I think that they are either not needed or better be "release barriers". vm_set_rendezvous_func() in sys/amd64/vmm/vmm.c rendezvous_func is checked and modified under rendezvous_mtx anyway. cpu_reset() in sys/x86/x86/cpu_machdep.c I do not see a need for a store-store barrier here. pmc_initialize() in sys/dev/hwpmc/hwpmc_mod.c I think that a store_rel or fence_rel would be more appropriate. Note sure about all uses of wmb in xen code, seems like at least some of them should be release operations or fences as well. -- Andriy Gapon From owner-freebsd-arch@freebsd.org Tue Oct 8 16:43:38 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B87A5130656 for ; Tue, 8 Oct 2019 16:43:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46njpb3JScz4Dxg; Tue, 8 Oct 2019 16:43:35 +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 x98GhRvn040840 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Oct 2019 19:43:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x98GhRvn040840 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x98GhRdK040839; Tue, 8 Oct 2019 19:43:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Oct 2019 19:43:27 +0300 From: Konstantin Belousov To: Andriy Gapon Cc: freebsd-arch@FreeBSD.ORG Subject: Re: illumos membar_producer emulation (zfs, dtrace) Message-ID: <20191008164327.GH44691@kib.kiev.ua> References: <28c5d9c1-740f-7832-873f-3cf03c6d94a4@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28c5d9c1-740f-7832-873f-3cf03c6d94a4@FreeBSD.org> User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46njpb3JScz4Dxg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 16:43:38 -0000 On Tue, Oct 08, 2019 at 06:22:07PM +0300, Andriy Gapon wrote: > > I have got a passing interest in cleaning up of the atomic and related illumos > compatibility (and contrib) code. > > At the moment I am looking at membar_producer. > >From Oracle Solaris documentation it follows that membar_producer is a store to > store barrier. > https://docs.oracle.com/cd/E88353_01/html/E37855/membar-producer-9f.html > > I do not think that we have an MI abstraction for that, so it seems that > atomic_thread_fence_rel could be the closest thing that we have. It also > affects loads which is redundant but not a big deal (IMO). > > As of now, we have membar_producer implemented in assembly for several platforms > (aarch64, amd64, i386, powerpc64, sparc64) and it's a no-op for the rest. > I think that the latter is a problem as it can affect correctness of the code. > > Also, the assembly implementations seem to be closer to wmb() although not > always the same. E.g., on amd64 both are sfence, while on sparc64 > membar_producer is "membar #StoreStore" while wmb is "membar #MemIssue". > I think that those implementations, maybe except for sparc64, are a bit of an > overkill as the code that uses membar_producer only deals with "normal" memory. > Maybe illumos uses membar_producer for access ordering of both normal memory and > memory (or instructions) with special caching properties. > > The relevant code is in: > - sys/cddl/compat/opensolaris/sys/atomic.h > - sys/cddl/compat/opensolaris/kern/opensolaris_atomic.c > - sys/cddl/contrib/opensolaris/common/atomic/*/opensolaris_atomic.S > > So, what do you think, would it be safe to emulate membar_producer with > atomic_thread_fence_rel? > Or is it better to leave the current code (copied from illumos for amd64, i386, > sparc64 and home-grown for aarch64, powerpc64) alone? > In that case, we still need to add something for the rest of the platforms > (arm-s, mips-es, riscv). > > P.S. > A bit offtopic. > > I noticed a couple of uses of wmb() with stores to regular memory. > I think that they are either not needed or better be "release barriers". > > vm_set_rendezvous_func() in sys/amd64/vmm/vmm.c > rendezvous_func is checked and modified under rendezvous_mtx anyway. > > cpu_reset() in sys/x86/x86/cpu_machdep.c > I do not see a need for a store-store barrier here. > > pmc_initialize() in sys/dev/hwpmc/hwpmc_mod.c > I think that a store_rel or fence_rel would be more appropriate. > > Note sure about all uses of wmb in xen code, seems like at least some of them > should be release operations or fences as well. SFENCE on x86 WB memory is NOP for all practical reasons. The only use of SFENCE known to me is to brace instructions like CLFLUSH(OPT) or CLZERO which list SFENCE as the requirements. So use of atomic_thread_fence_rel() might be more optimal if the semantics fit. From owner-freebsd-arch@freebsd.org Tue Oct 8 17:40:35 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9B55B131BF9 for ; Tue, 8 Oct 2019 17:40:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46nl4L1L1nz4JGW for ; Tue, 8 Oct 2019 17:40:34 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f68.google.com with SMTP id z19so38487130ior.0 for ; Tue, 08 Oct 2019 10:40:34 -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=LE8BiqsmH+2jj9gdU0mJ+m+dOmtO2BgE9v7A8j8owug=; b=F66tq7rthyemRuLyY3X8cUCBs7x1pU3YXOx3nF4NsVeL/e5kdNv0UfktGEMCr17nFL ja0P2fKfuv4f4e1JCDl1ZASTIk9i6gDHD4tcNrhmgbLTe2ur2Sm+VlLBmfdUEnhGw6xb MeLfxrLHsZ3L407d+6qRny/xC0r8vpX1ZwSShFu3qYvXnfjeTEPJ52ELGWCfNKLLMlS1 9N19x8Fqen8NhmYGptXQ2c4S7tqPwl6DHBHmW4X8WoHviW4ZxWZFmWm7JTd5HGUWxhdN GQ/vwjZ2ZP/nqi7NOVJMEsRDBtOdJKe5tUwMaIgFhuNa8TykywMuxzWbmHMc6CB9jGcu HSMg== X-Gm-Message-State: APjAAAW+98R+o2m6OB69oyvjjY8bBT97fdlKrygPS0ch/qWyJEY/U8Uz 99xA72XBEBhP9lNB7ZcTObakLeBNOMKrjdxdj8w= X-Google-Smtp-Source: APXvYqxI/l8nwfu8S9RhFrHe0zW0TS/F78/nOFRNtJTIkuu8m6iq9R3Y93Ou/RXoQJ1PT6MEXMYSsPj0QOIYohFmM3U= X-Received: by 2002:a92:995a:: with SMTP id p87mr37093225ili.115.1570556430405; Tue, 08 Oct 2019 10:40:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 8 Oct 2019 13:40:16 -0400 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Warner Losh Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46nl4L1L1nz4JGW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.68 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.54 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.54)[ip: (-2.27), ipnet: 209.85.128.0/17(-3.26), asn: 15169(-2.14), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[68.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 17:40:35 -0000 On Tue, 13 Aug 2019 at 12:00, Warner Losh wrote: > > Greetings, > > As promised for almost the past decade or so, gcc 4.2.1 will be removed > from the tree before FreeBSD 13 is branched. > > I propose the following timeline for its removal: > > 2019-08-31: disconnect gcc 4.2.1 from CI build > > Turn off -Werror on gcc 4.2.1 platforms > > Turn off all gcc 4.2.1 from universe by default (can be turned on) I paid most attention to the later dates in the original email (end of year and end of next March) and was caught a bit off guard by this when it was recently mentioned on IRC. Thus I wanted to refresh this topic on the list, and remind everyone that this is imminent - soon a default `make universe` without external toolchain will not include GCC 4.2.1 archs (mips, powerpc, sparc64). Warner's patch is in progress in review D21942. From owner-freebsd-arch@freebsd.org Tue Oct 8 18:02:05 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 34458132679 for ; Tue, 8 Oct 2019 18:02:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46nlY81VpMz4Kr9 for ; Tue, 8 Oct 2019 18:02:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x836.google.com with SMTP id v52so3869934qtb.8 for ; Tue, 08 Oct 2019 11:02:03 -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=r/poEzkxM5zqgB6h6C4JTeYAdUvhcTzji/zVun6jY/U=; b=NIoYn7VLye/97ZKgAULweG3AnpIWFMjdpsDEApdsuz4Kw4fJ+A3xDEkUupHxuu6pSB ICf1ISyJBIKOlESewzNIVA8hw3hdCY8C71xy2EcQGv5f+SorFiRlH0IiAcXe9JzW66aF WurC4k4FpLKk4tCg89gDzSdrrqfvgLhpX1zFClErjxfsNG6XQuBgaPnCbDm30Ag/0Uri x0y6Fn/sCDhxEWshfAaPQ25wpoFi8QStlh8qTccuUtDFj2n50p3nYFcebzjCfnnIDwJw SJG4u0TEiNAdF7Di1QuRC5dYtjUs35VgEjMUWg+WP4WTBm+M2Fd6V9BNFjqclbLILi64 3dQw== 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=r/poEzkxM5zqgB6h6C4JTeYAdUvhcTzji/zVun6jY/U=; b=m5SChJt75934IZIunM8cDP6Df819i8EgvJLdgIIKirflhg3UEl7T0SG0qokDdF1z77 wVkebuR36z/LUBj4Qf0nmeX2skZ3BAVeLWNysQ+kCSul3AtsaAVmo21ADuvP+U/99MdR MABOcZhaoPETbI6V2DFRnZadpau0Ucq669PLpNLZHfe4nAvPh1ciZ0qy/25LmEx1zWNk BoUDXl7sKpWmDtzcjbC6nJ5pRPRGD3mTJpdfgZuDSfGIXsx4yNCMLrVf/dPWarAwtbEH k8tS3kxspeyeKuXyKT72YC+3+/7/ijSLQv/d86ZwSbWQI4Qg/+zyrScbn55jyIUK7dNL +Hlw== X-Gm-Message-State: APjAAAWOvE4BvIOb+38OtsirWoqBhE4Tll92KS24/D/XmVFYiB5LVdJp J7/qYcRwZJ4bx+PK9amLOAaJcyN2nf2s9Ypv5dSWRfVZxd8= X-Google-Smtp-Source: APXvYqylCo1x0FZDXKVmZTx410mcCLLkjCoVB+Bb0KLMY30fCuBlfqGdA8x7LQxhwuEA5iIv8baZUj6F5ojpiqM4tZU= X-Received: by 2002:ac8:3564:: with SMTP id z33mr37314323qtb.291.1570557723129; Tue, 08 Oct 2019 11:02:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 8 Oct 2019 12:01:52 -0600 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Ed Maste Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 46nlY81VpMz4Kr9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=NIoYn7VL; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::836) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[6.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.80)[ip: (-9.25), ipnet: 2607:f8b0::/32(-2.54), asn: 15169(-2.14), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 18:02:05 -0000 On Tue, Oct 8, 2019 at 11:40 AM Ed Maste wrote: > On Tue, 13 Aug 2019 at 12:00, Warner Losh wrote: > > > > Greetings, > > > > As promised for almost the past decade or so, gcc 4.2.1 will be removed > > from the tree before FreeBSD 13 is branched. > > > > I propose the following timeline for its removal: > > > > 2019-08-31: disconnect gcc 4.2.1 from CI build > > > > Turn off -Werror on gcc 4.2.1 platforms > > > > Turn off all gcc 4.2.1 from universe by default (can be turned on) > > I paid most attention to the later dates in the original email (end of > year and end of next March) and was caught a bit off guard by this > when it was recently mentioned on IRC. Thus I wanted to refresh this > topic on the list, and remind everyone that this is imminent - soon a > default `make universe` without external toolchain will not include > GCC 4.2.1 archs (mips, powerpc, sparc64). > > Warner's patch is in progress in review D21942. > I've updated the patch to have a check for external toolchain for mips, powerpc and sparc64, and skip the build if they aren't installed. The old behavior is enabled by setting MAKE_OBSOLETE_GCC so if you want, you can build the universe with the old soon-to-be-deleted in-tree 4.2 gcc, as outlined in this thread. I'd held off a little thinking that llvm 9.0 will have landed by now, but it hasn't due to exp-run issues. Rather than stall until it's in the tree, I'm planning on committing the review by the end of the week, assuming testing is all green. When it lands in the tree, we can rejigger with the new mips and/or powerpc support. https://reviews.freebsd.org/D21942 is a handy link to the review. Warner From owner-freebsd-arch@freebsd.org Wed Oct 9 05:33:48 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 53AD21416A5 for ; Wed, 9 Oct 2019 05:33:48 +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 46p2vH4vWPz3xTm; Wed, 9 Oct 2019 05:33:47 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 3AFE62A7C8; Wed, 9 Oct 2019 05:33:46 +0000 (UTC) Date: Wed, 9 Oct 2019 05:33:44 +0000 From: Mark Linimon To: Warner Losh Cc: Ed Maste , "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20191009053342.GA21030@lonesome.com> References: 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-Rspamd-Queue-Id: 46p2vH4vWPz3xTm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-1.54 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.26)[ip: (0.02), ipnet: 18.220.0.0/14(0.13), asn: 16509(-1.40), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 05:33:48 -0000 On Tue, Oct 08, 2019 at 12:01:52PM -0600, Warner Losh wrote: > I'd held off a little thinking that llvm 9.0 will have landed by now, but > it hasn't due to exp-run issues. Rather than stall until it's in the tree, > I'm planning on committing the review by the end of the week, assuming > testing is all green. The following is not an argument for or against the timeline, just some more info. tl:dr; yes it's a long message, the gist of which is "we're not quiiiite ready on powerpc64." If people don't have some time to sit down and go through all of the gory details, I won't blame them ... The exp-run test Warner cites above covers and only covers "test all port builds against llvm9.0 in base, on amd64". What it does *not* cover is "test all port builds against llvm. in base, on powerpc64". I have been leading the charge on the latter, on the machine IBM has loaned to us via OSU, "ppcdevref". This is the testbed for "powerpc64 with clang as the base compiler." Right now its base compiler is 8.0.1. (This is due to a: we have not gotten around to 9.x yet, b: we are still only ~95% of the way to identifying *just* the regressions in that configuration.) As of today, the early-adopter developers running powerpc64/llvm9x are battling errors that are (for purposes of brevity) the union of the ppcdevref errors and the above exp-run. (Actually, there are some disjoint entries -- let me elide that for now.) So the list of regressions as of *today* on ppcdevref has just been re-uploaded to: https://people.freebsd.org/~linimon/poudriere/blacklist.powerpc64.ppcdevref Let me note, I am updating this file *rapidly*, sometimes more than once per day. It is full of sharp edges and snarky comments :-) Anyone who wants to poke at the above data, please contact me off-list or join us on #powerpc64 on EFNet, rather than replying here. But, of particular concern are: databases/mariadb55-client databases/mysql55-client databases/percona55-client devel/kyra graphics/drm-legacy-kmod lang/rust net/samba410 www/node* (I have patches for these) x11-toolkits/qt5-declarative And, I'm sorry, I used to have a set of poudriere results uploaded to www.lonesome.com that corresponed to the above, so that you could view the #blocked. But that VM instance has died and I don't have the cycles to fix it right now. But in brief, the kyra, rust, and samba failures are problematic. So, that's the list of things that will break immediately as soon as the pylon.nyi.FreeBSD.org package builder is switched over to gcc-less. Also, anyone who is on powerpc64-CURRENT-less-than-that-commit will have to immediately update, if they want to use the new packages. There is no way to mix-and-match. The problem I am facing is that "people keep moving my cheese". There have been infrastructure changees, a default ports compiler change, changes that affect big projects like kde, and even a few sweeping changes that I have not yet fully accounted for -- and that's all within the last month. This week I am not as much "fighting my way up the hill" as I am "crawling up the hill on hands and knees while pulling arrows out of my back." So, my pace of testing and fixing has slowed down. Also, there are some patches (especially linker) that I have not yet tested. Finally, yes, I know, I've been told more than once that "tier-2 considerations cannot affect what is committed to -CURRENT". So, I get that. But, if we switched today, there would still be a pain-point, and that's the point of all the above text. fwiw. mcl From owner-freebsd-arch@freebsd.org Wed Oct 9 06:02:35 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 120E3141D3D for ; Wed, 9 Oct 2019 06:02:35 +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 46p3XV523fz3yWF; Wed, 9 Oct 2019 06:02:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 72D622A7C8; Wed, 9 Oct 2019 06:02:33 +0000 (UTC) Date: Wed, 9 Oct 2019 06:02:31 +0000 From: Mark Linimon To: Warner Losh Cc: Ed Maste , "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20191009060230.GB21030@lonesome.com> References: <20191009053342.GA21030@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191009053342.GA21030@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 46p3XV523fz3yWF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of linimon@lonesome.com has no SPF policy when checking 18.222.6.11) smtp.mailfrom=linimon@lonesome.com X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(-0.26)[ip: (0.02), ipnet: 18.220.0.0/14(0.13), asn: 16509(-1.40), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.989,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.6.222.18.list.dnswl.org : 127.0.5.2]; NEURAL_HAM_MEDIUM(-0.98)[-0.978,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 06:02:35 -0000 "way to bury the lede, Mark" A more succinct summary of my message is at: https://wiki.freebsd.org/powerpc/ports/PortsOnClang mcl From owner-freebsd-arch@freebsd.org Wed Oct 9 20:31:24 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5C03E12E9C1 for ; Wed, 9 Oct 2019 20:31:24 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46pQpz1w3Tz3ymm; Wed, 9 Oct 2019 20:31:23 +0000 (UTC) (envelope-from jlehen@gmail.com) Received: by mail-io1-f43.google.com with SMTP id h144so8224518iof.7; Wed, 09 Oct 2019 13:31:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=GAn0phC4BVkN8vTYYlRsNCKOgif8xfEyr6AvMdtxmfI=; b=jnXEjPXWPo5bUSUuLgmay8Sdte8jP1neGjW7Zv1IJ2xeH9WKngQR/aC9x301IDhJu1 4Wx9GQ8VCJqdLYzV6xh80wq8xg/AZfq8FQ577kLSs43H3yPQxVbJhLfW8PMv8JaJymNC JDoRQr8oSk+swFUtGcLlfrOJL+1YjNYI4DqvY+yg392SpJppEaZNky7itwbSy6ZWaLDT PX1dzkMM0OZKEOu6/afSxX0SbzrVHAAuLHkhil8lVV/npIFEAqh9MSXr+tHhPLRI4ttA MefU9XZND9PgeYZzpe9evFk7Wq3fKMgldgSh77oBejccUWwRRBufCFvtNRUi5UHWVRTZ AQPA== X-Gm-Message-State: APjAAAXw/6Ov6fdR7sH8vGzFNVYFFumsBRjj0lDW3kQnc2Qtr3ZavutL er9j5Hf3FQxOaxcZRmPeZUMaZOhnc6V6Jk5ZM8RZnRT8 X-Google-Smtp-Source: APXvYqyzQyMEsVnr4P9t+hOyD1KsZMeLea4x3LxUfFAl0XjMhxr/C8OizheIqW8G70GRXGFIxUXCif+88AnCLXWJFJ4= X-Received: by 2002:a6b:e411:: with SMTP id u17mr5178327iog.253.1570653081803; Wed, 09 Oct 2019 13:31:21 -0700 (PDT) MIME-Version: 1.0 From: Jeremie Le Hen Date: Wed, 9 Oct 2019 22:30:30 +0200 Message-ID: Subject: Removal of rmt(8)? rcmd(3)? To: freebsd-arch@freebsd.org Cc: Edward Napierala Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46pQpz1w3Tz3ymm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jlehen@gmail.com designates 209.85.166.43 as permitted sender) smtp.mailfrom=jlehen@gmail.com X-Spamd-Result: default: False [-2.91 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.91)[ip: (-4.11), ipnet: 209.85.128.0/17(-3.25), asn: 15169(-2.14), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[43.166.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[jlh@freebsd.org,jlehen@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[43.166.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[jlh@freebsd.org,jlehen@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 20:31:24 -0000 Hi, In August 2017 I removed FreeBSD rcmd tools (rsh, ruptime, etc). trasz@ (cc'ed) reached out to me asking if we should remove rmt(8). It relies on rcmd(3) which, as I understand it, is a libc function which implements protocol used by rshd(8). This looks like me these two should have been removed in 2017 as well. Pardon my ignorance but I've just discovered about these two. Are there any other commands/libraries like this which are candidates to be removed? Other thoughts? -- Jeremie Le Hen jlh@FreeBSD.org From owner-freebsd-arch@freebsd.org Wed Oct 9 20:46:22 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9503612EFE1 for ; Wed, 9 Oct 2019 20:46:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46pR8G3CSHz40mj; Wed, 9 Oct 2019 20:46:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x99KkDIJ055838 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 9 Oct 2019 13:46:13 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x99KkDOZ055837; Wed, 9 Oct 2019 13:46:13 -0700 (PDT) (envelope-from sgk) Date: Wed, 9 Oct 2019 13:46:13 -0700 From: Steve Kargl To: Jeremie Le Hen Cc: freebsd-arch@freebsd.org, Edward Napierala Subject: Re: Removal of rmt(8)? rcmd(3)? Message-ID: <20191009204613.GA55772@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 46pR8G3CSHz40mj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 20:46:22 -0000 On Wed, Oct 09, 2019 at 10:30:30PM +0200, Jeremie Le Hen wrote: > Hi, > > In August 2017 I removed FreeBSD rcmd tools (rsh, ruptime, etc). I seem to have ruptime. % ruptime ruptime: no hosts in /var/rwho > trasz@ (cc'ed) reached out to me asking if we should remove rmt(8). It > relies on rcmd(3) which, as I understand it, is a libc function which > implements protocol used by rshd(8). This looks like me these two > should have been removed in 2017 as well. > > Pardon my ignorance but I've just discovered about these two. Are > there any other commands/libraries like this which are candidates to > be removed? > > Other thoughts? There is rdump and rrestore. dumprmt.c seems to use rcmd(3). -- Steve From owner-freebsd-arch@freebsd.org Wed Oct 9 21:24:04 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C469C12FD93 for ; Wed, 9 Oct 2019 21:24:04 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (tunnel82308-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::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 46pRzl25NXz431F for ; Wed, 9 Oct 2019 21:24:02 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.15.2/8.15.2) with ESMTP id x99LNsQA071412; Wed, 9 Oct 2019 17:23:54 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.15.2/8.15.2/Submit) id x99LNsaB071411; Wed, 9 Oct 2019 17:23:54 -0400 (EDT) (envelope-from wollman) Date: Wed, 9 Oct 2019 17:23:54 -0400 (EDT) From: Garrett Wollman Message-Id: <201910092123.x99LNsaB071411@hergotha.csail.mit.edu> To: sgk@troutmask.apl.washington.edu Subject: Re: Removal of rmt(8)? rcmd(3)? References: <20191009204613.GA55772@troutmask.apl.washington.edu> Organization: none Cc: freebsd-arch@freebsd.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 09 Oct 2019 17:23:54 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hergotha.csail.mit.edu X-Rspamd-Queue-Id: 46pRzl25NXz431F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of wollman@hergotha.csail.mit.edu uses mechanism not recognized by this client) smtp.mailfrom=wollman@hergotha.csail.mit.edu X-Spamd-Result: default: False [-2.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[mit.edu]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.60)[ipnet: 2001:470::/32(-4.57), asn: 6939(-3.40), country: US(-0.05)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 21:24:04 -0000 In article <20191009204613.GA55772@troutmask.apl.washington.edu> you write: >On Wed, Oct 09, 2019 at 10:30:30PM +0200, Jeremie Le Hen wrote: >> Hi, >> >> In August 2017 I removed FreeBSD rcmd tools (rsh, ruptime, etc). > >I seem to have ruptime. > >% ruptime >ruptime: no hosts in /var/rwho rwho and ruptime are not part of the rcmd suite; they use link-local broadcast or multicast communications, but supply only general system information, not individual user access, and runs as an unprivileged user. I still run rwhod (in multicast mode). -GAWollman From owner-freebsd-arch@freebsd.org Wed Oct 9 21:41:10 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C676C13041F for ; Wed, 9 Oct 2019 21:41:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46pSMT6Whzz43rx for ; Wed, 9 Oct 2019 21:41:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82d.google.com with SMTP id c21so5593040qtj.12 for ; Wed, 09 Oct 2019 14:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=5/IBr8w4V17J1GhLx73XvQiUjPh5he3Wk5cJ9l9Lsyk=; b=biC6ABHYjdWC+fnkHgOlqZMITxTnuGWn9t2NJvknC5UufsgeHuFFfXNAnfVPQ/6zTR CRu1CweTsWophIArYoQaYyg9cUycgotkI3sij9ZB2sk4AWVMhR6LWL64lkfBzQnDwNEw TW9C5UrwMpG/kQ+ZGekXNIzOP6Cs+oKsqrn9X3DqHaivzZNH+e5CDnQbEPw35Ivj18g0 DbNS5VxrzeiKuiuLq9GnfiZJreVPteuDZpdwz0j7tEnaPFi3taDmEDnMEgTSClGk99eE buJcdf/eFv3fCl3tJkB/orf2FV7gs9cj3kZb9qexJzn1Yjhnp4qj0vFzUFWQIGV2D77Q inqw== 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=5/IBr8w4V17J1GhLx73XvQiUjPh5he3Wk5cJ9l9Lsyk=; b=Wkcrve9pjlvm/eehp4RPJnAspA4Y9IxDxu+FnHs4hWKdN0Hew2R13gkbS4zUpkHAhq Lg0zZUIdspIG3/vC7TwQfDHeuUKiHagVD+0IaI2BCHXdOAFO4A0MND9v04HJ1GDXennV OuLMrwRI1hbfjIjvtNyyaKOaOLIi9xvFZ9h7dQ/VWjXCqV2C4YwVRk5TkO0HlOLDTd4E Tsq/fwRFmVEVVbeIHy8VsRm8dN8+WNQ8Fj/FExL/rAwzvxyCGQ/b71RZxlEx3huaPbl/ 70aFI38aUkYaFv0av5XtXGkiN7/Nwggj3sumNhewiyJ8uvi9M3f6hSqMcUx4MEyimlQP cdxw== X-Gm-Message-State: APjAAAXbOVeXGZ6VcW8arQfs3ovUAqMLz4EsOswj6tvPN2kOZow4RdvS 9/R9L0wE0+y2gyL61N3ldo+CMlJlKeTA0aRMtmP0s9FJ X-Google-Smtp-Source: APXvYqx9UuIAGLINItxKqwMbwLLBVX6wsr0wTy/Rx0YKve4/6KH/xs7a6WI+CtlixblvFS5axm8Oi38QCfYk64jsQ5A= X-Received: by 2002:ac8:29c8:: with SMTP id 8mr5976070qtt.32.1570657268290; Wed, 09 Oct 2019 14:41:08 -0700 (PDT) MIME-Version: 1.0 From: Warner Losh Date: Wed, 9 Oct 2019 15:40:57 -0600 Message-ID: Subject: firm date: armv5 support removal scheduled for 2019-12-31 To: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 46pSMT6Whzz43rx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=biC6ABHY; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[d.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.82)[ip: (-9.37), ipnet: 2607:f8b0::/32(-2.53), asn: 15169(-2.14), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 21:41:10 -0000 Greetings, There's been much talk of removing armv5 support from FreeBSD in FreeBSD 13. This talk has been ongoing since before 12 was branched among the key arm developers. The compromise for the FreeBSD 12 was to have one final FreeBSD armv5 release for a few straggling users that needed (or think they needed) this release and it would be removed before FreeBSD 13. The reason to remove this is due to the increased burden armv5 has presented on the system. We have a separate pmap for v5 which has known or suspected bugs relating to unaligned I/O. No developers have the armv5 boards in service anymore. They have ceased being relevant to FreeBSD's success with the plethera of armv7 boards that are on the market. No new armv5 boards have been made in a long time. The FreeBSD project hasn't produce armv5 binaries for 12.x at all (the binaries produced earlier could not have possibly booted, though the userland binaries worked if you could otherwise install the system). Finally, llvm's lld doesn't support armv5. It would ease integration if we didn't have to worry about a fallback for armv5. It would be one fewer dependency on the old binutils toolchain in the tree. So, taking all these things together, the time has come to schedule removal of armv5 support from FreeBSD. The end of the year seems like a good date to select for planning this removal, getting whatever notices should be put into place and warning people about the next release in the most formal way possible (more informal warnings have been going on for over a year, starting with armv4 support removal in 12). I'm posting this now to gather feedback and, if necessary, create a checklist of things to do before removal. Warner From owner-freebsd-arch@freebsd.org Thu Oct 10 08:39:44 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2180B14E831 for ; Thu, 10 Oct 2019 08:39:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46pkzM6JFRz4nw2; Thu, 10 Oct 2019 08:39:43 +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 x9A8dVTS011285 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 10 Oct 2019 11:39:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x9A8dVTS011285 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x9A8dVCX011284; Thu, 10 Oct 2019 11:39:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Oct 2019 11:39:31 +0300 From: Konstantin Belousov To: Jeremie Le Hen Cc: freebsd-arch@freebsd.org, Edward Napierala Subject: Re: Removal of rmt(8)? rcmd(3)? Message-ID: <20191010083931.GL44691@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46pkzM6JFRz4nw2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 08:39:44 -0000 On Wed, Oct 09, 2019 at 10:30:30PM +0200, Jeremie Le Hen wrote: > Hi, > > In August 2017 I removed FreeBSD rcmd tools (rsh, ruptime, etc). > > trasz@ (cc'ed) reached out to me asking if we should remove rmt(8). It > relies on rcmd(3) which, as I understand it, is a libc function which > implements protocol used by rshd(8). This looks like me these two > should have been removed in 2017 as well. > > Pardon my ignorance but I've just discovered about these two. Are > there any other commands/libraries like this which are candidates to > be removed? > > Other thoughts? Note that you cannot remove a symbol from symver-ed library. Look at what was done recently for gets(3) to have an idea how this could be handled. From owner-freebsd-arch@freebsd.org Thu Oct 10 11:36:35 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ED6481303E5; Thu, 10 Oct 2019 11:36:35 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 46ppvQ411Vz3JLl; Thu, 10 Oct 2019 11:36:34 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Thu, 10 Oct 2019 13:36:31 +0200 (CEST) From: Ronald Klop To: Warner Losh Cc: "freebsd-arm@freebsd.org" , "freebsd-arch@freebsd.org" Message-ID: <829263445.69.1570707391813@localhost> In-Reply-To: References: Subject: Re: firm date: armv5 support removal scheduled for 2019-12-31 MIME-Version: 1.0 X-Mailer: Realworks (479.1333.8d416e802c4) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 46ppvQ411Vz3JLl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 194.109.157.24 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws X-Spamd-Result: default: False [-0.30 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.50)[-0.503,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-0.95)[-0.953,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[klop.ws]; TO_DN_SOME(0.00)[]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[24.157.109.194.list.dnswl.org : 127.0.15.0]; HAS_X_PRIO_THREE(0.00)[3]; IP_SCORE(-0.05)[ipnet: 194.109.0.0/16(-0.16), asn: 3265(-0.09), country: NL(0.02)]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MIME_TRACE(0.00)[0:+,1:+,2:~] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 11:36:36 -0000 Axe it! See mails from may/june "boot 11.3-BETA1 hangs om armv5". This did not boot on my Sheevaplug. I stopped trying. A new RPI is cheaper than one hour of work on armv5. But it was fun while it worked. :-) Thanks. Regards, Ronald. Van: Warner Losh Datum: woensdag, 9 oktober 2019 23:40 Aan: "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Onderwerp: firm date: armv5 support removal scheduled for 2019-12-31 > > Greetings, > > There's been much talk of removing armv5 support from FreeBSD in FreeBSD > 13. This talk has been ongoing since before 12 was branched among the key > arm developers. The compromise for the FreeBSD 12 was to have one final > FreeBSD armv5 release for a few straggling users that needed (or think they > needed) this release and it would be removed before FreeBSD 13. > > The reason to remove this is due to the increased burden armv5 has > presented on the system. We have a separate pmap for v5 which has known or > suspected bugs relating to unaligned I/O. No developers have the armv5 > boards in service anymore. They have ceased being relevant to FreeBSD's > success with the plethera of armv7 boards that are on the market. No new > armv5 boards have been made in a long time. The FreeBSD project hasn't > produce armv5 binaries for 12.x at all (the binaries produced earlier could > not have possibly booted, though the userland binaries worked if you could > otherwise install the system). Finally, llvm's lld doesn't support armv5. > It would ease integration if we didn't have to worry about a fallback for > armv5. It would be one fewer dependency on the old binutils toolchain in > the tree. > > So, taking all these things together, the time has come to schedule removal > of armv5 support from FreeBSD. The end of the year seems like a good date > to select for planning this removal, getting whatever notices should be put > into place and warning people about the next release in the most formal way > possible (more informal warnings have been going on for over a year, > starting with armv4 support removal in 12). > > I'm posting this now to gather feedback and, if necessary, create a > checklist of things to do before removal. > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arch@freebsd.org Thu Oct 10 10:35:30 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 679FB12CB70 for ; Thu, 10 Oct 2019 10:35:30 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh605-vm11.bullet.mail.ssk.yahoo.co.jp (nh605-vm11.bullet.mail.ssk.yahoo.co.jp [182.22.90.84]) by mx1.freebsd.org (Postfix) with SMTP id 46pnXv3g2bz3D6G for ; Thu, 10 Oct 2019 10:35:26 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.104] by nh605.bullet.mail.ssk.yahoo.co.jp with NNFMP; 10 Oct 2019 10:35:23 -0000 Received: from [182.22.91.205] by t602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 10 Oct 2019 10:35:23 -0000 Received: from [127.0.0.1] by omp608.mail.ssk.yahoo.co.jp with NNFMP; 10 Oct 2019 10:35:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 189505.62941.bm@omp608.mail.ssk.yahoo.co.jp X-YMail-OSG: lLeurSMVM1lf9Pz6gFFzfIVAlGUpS_qctCmvs__n59uFNaRIC6urG80DQTfLFud IRRxkhYNi2fyCAjL5_xNgsuuB38CmAJWRyhYWYp7DYlbN92skGpgXEToJE7vdFygamFnf5M1rxZN HkU5cIt_NDg9.EwbTscRcBlFABPG2YTrYNExKpaJ0AqhaLzMXSPaY0f3_uJmiY.HvJkYQTncqE_n 7urinwbtIUEj_LI47jCSaTRmX7SNtICZc0_67U39wCNnosXZd7h2eHIL4qvMMgXnYFj2CdzgnJ9l svxU3b3u2FLkJDEOUFQhjw6K1vEE27zZjY7lif2TjRVv6MuS9JkmMlxBY5pjrgX4JHqAb9h5tUG9 RMGFtThnxEgXhY6yCFAouUo.rEs51uyyDtHOe4vD1hv_KPqRqssR0UitAlfQreNNET9qY2gMblwP dJeh1RAEXJWHdk3n_GBMiFTMEyG7E2xnt2w07BoTS6ymwTnILfSxr7qtIzyoHtb3ZMXz8VYYhuEZ s2IWM9pWSbFjSJlmjKmlqdhcnaU9NEbY.D2EoqgN8HGzI8Y6BZ6SALxl4mesKszCyoqFJ.OdQln0 J7lHpLzBCNs32P7DyBbTYJ0rbCIZbm69Jt6cdaCHKrDlD31cDqXn2Gg5_rtYoI_RA7NCEl4grpDD 2OvM7QytxfTV8cgBanOPhQvi2CxBtJlJB0vjF95QYtzvL Received: from jws700103.mail.ssk.yahoo.co.jp by sendmailws615.mail.ssk.yahoo.co.jp; Thu, 10 Oct 2019 19:35:22 +0000; 1570703722.696 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1570703723; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=1ZLU/+dqfyZv5OFhZA5YWkZZ/2hdBupfrg83pJFe6D8=; b=hQFoF3qGO02E7Ja0P1EmNugPDA4Ccd4x5IccGdIeq+razGZpRlPwBDYvGgxGjTDX MikGdmh/UTVPS/IdRj+dDbjuk/fYmDRJQDOfn7gUcCkstshxE9jbCnjcdlehhwIKC/z WUU0Bwtx+aOP03UBNkk3NUWMS4QTT0k3aV0dFEY4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Date:From:Reply-To:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=phlq4Q0jntbyfUicSPb0B3LEGDRZwTuOsS+RfQWvd22HcdnU4aubb+yS0LPcz9qF BGWwlezPNmv3VhObTGGbszQadH5qjpw6aLMB58kqA1P39b4rULFr5Ae8nceJDnCJ3Is kR3FpcAqfPBl8IFmaF77N+9QEz0i9tPYUqrRPRA8=; Date: Thu, 10 Oct 2019 19:35:22 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki To: Warner Losh , "freebsd-arch@freebsd.org" , "freebsd-arm@freebsd.org" Message-ID: <1818196815.3441463.1570703722086.JavaMail.yahoo@jws700103.mail.ssk.yahoo.co.jp> In-Reply-To: References: Subject: Re: firm date: armv5 support removal scheduled for 2019-12-31 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46pnXv3g2bz3D6G X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.co.jp header.s=yj20110701 header.b=hQFoF3qG; dmarc=pass (policy=none) header.from=yahoo.co.jp; spf=pass (mx1.freebsd.org: domain of yamori813@yahoo.co.jp designates 182.22.90.84 as permitted sender) smtp.mailfrom=yamori813@yahoo.co.jp X-Spamd-Result: default: False [-2.82 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[yamori813@yahoo.co.jp]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:182.22.90.0/23]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:23816, ipnet:182.22.0.0/17, country:JP]; IP_SCORE(0.00)[ip: (0.96), ipnet: 182.22.0.0/17(1.41), asn: 23816(1.13), country: JP(-0.01)]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.925,0]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; REPLYTO_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[yahoo.co.jp]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.90.22.182.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 10:35:30 -0000 Hi I have very angry. Because of this. One is Maverl soc is not right performance on FreeBSD now. Maverl FreeBSD is 10-30 times slow from Linux. I think armv5t support is not complete on FreeBSD. You say armv5t pmap have bug. But my RT1310(armv5t) work well half of year. I try ldd on armv5t one month ago. That is support for armv4 because of that don't know armv4t instruction by default. Hiroki Mori ----- Original Message ----- > From: Warner Losh > To: "freebsd-arch@freebsd.org" ; "freebsd-arm@freebsd.org" > Cc: > Date: 2019/10/10, Thu 06:40 > Subject: firm date: armv5 support removal scheduled for 2019-12-31 > >G reetings, > > There's been much talk of removing armv5 support from FreeBSD in FreeBSD > 13. This talk has been ongoing since before 12 was branched among the key > arm developers. The compromise for the FreeBSD 12 was to have one final > FreeBSD armv5 release for a few straggling users that needed (or think they > needed) this release and it would be removed before FreeBSD 13. > > The reason to remove this is due to the increased burden armv5 has > presented on the system. We have a separate pmap for v5 which has known or > suspected bugs relating to unaligned I/O. No developers have the armv5 > boards in service anymore. They have ceased being relevant to FreeBSD's > success with the plethera of armv7 boards that are on the market. No new > armv5 boards have been made in a long time. The FreeBSD project hasn't > produce armv5 binaries for 12.x at all (the binaries produced earlier could > not have possibly booted, though the userland binaries worked if you could > otherwise install the system). Finally, llvm's lld doesn't support > armv5. > It would ease integration if we didn't have to worry about a fallback for > armv5. It would be one fewer dependency on the old binutils toolchain in > the tree. > > So, taking all these things together, the time has come to schedule removal > of armv5 support from FreeBSD. The end of the year seems like a good date > to select for planning this removal, getting whatever notices should be put > into place and warning people about the next release in the most formal way > possible (more informal warnings have been going on for over a year, > starting with armv4 support removal in 12). > > I'm posting this now to gather feedback and, if necessary, create a > checklist of things to do before removal. > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Fri Oct 11 10:59:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A3D214821E for ; Fri, 11 Oct 2019 10:59:28 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [37.187.123.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (1024 bits) client-digest SHA256) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46qQ2614DCz4MSq for ; Fri, 11 Oct 2019 10:59:25 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver= DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 46qPvD4LJfzJf Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256 client-signature RSA-PSS (1024 bits) client-digest SHA256) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 46qPvD4LJfzJf for ; Fri, 11 Oct 2019 12:53:27 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id x9BArROM083874 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 11 Oct 2019 12:53:27 +0200 (CEST) (envelope-from hlh@restart.be) X-Authentication-Warning: norquay.restart.bel: Host morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1] claimed to be morzine.restart.bel To: "freebsd-arch@freebsd.org" From: Henri Hennebert Subject: PINE64+ 2GB - with U-Boot SPL 2019.10 - bootaa64.efi do not find UFS partition Message-ID: <1884e0d5-5294-9d15-43c7-8e7cac98f3b3@restart.be> Date: Fri, 11 Oct 2019 12:53:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46qQ2614DCz4MSq X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[restart.be:s=tignes]; NEURAL_HAM_MEDIUM(-0.98)[-0.975,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:37.187.123.11/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[restart.be:+]; DMARC_POLICY_ALLOW(-0.50)[restart.be,reject]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.45)[ipnet: 37.187.0.0/16(0.72), asn: 16276(1.55), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:37.187.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 10:59:28 -0000 U-Boot SPL 2019.10 (Oct 10 2019 - 18:05:29 +0200) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.0(release): >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403b,0x20000) Probing 3 block devices...... done ZFS found no pools UFS found no partitions Failed to load '/boot/loader.efi' panic: No bootable partitions found! ## Application terminated, r = 1 Revert to U-Boot SPL 2019.07 with the same bootaa64.efi boot OK Henri From owner-freebsd-arch@freebsd.org Fri Oct 11 11:29:08 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0EC58149796 for ; Fri, 11 Oct 2019 11:29:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [37.187.123.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (1024 bits) client-digest SHA256) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46qQhM1pdHz4PMs for ; Fri, 11 Oct 2019 11:29:07 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver= DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 46qQhK6rjBzJh Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256 client-signature RSA-PSS (1024 bits) client-digest SHA256) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 46qQhK6rjBzJh for ; Fri, 11 Oct 2019 13:29:04 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id x9BBT4kY085906 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 11 Oct 2019 13:29:04 +0200 (CEST) (envelope-from hlh@restart.be) X-Authentication-Warning: norquay.restart.bel: Host morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1] claimed to be morzine.restart.bel From: Henri Hennebert Subject: PINE64+ 2GB - with U-Boot SPL 2019.10 - bootaa64.efi do not find UFS partition To: "freebsd-arm@freebsd.org" Message-ID: Date: Fri, 11 Oct 2019 13:29:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46qQhM1pdHz4PMs X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.55 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[restart.be:s=tignes]; NEURAL_HAM_MEDIUM(-0.98)[-0.979,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:37.187.123.11/32:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[restart.be:+]; DMARC_POLICY_ALLOW(-0.50)[restart.be,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.43)[ipnet: 37.187.0.0/16(0.59), asn: 16276(1.55), country: FR(-0.00)]; ASN(0.00)[asn:16276, ipnet:37.187.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 11:29:08 -0000 U-Boot SPL 2019.10 (Oct 10 2019 - 18:05:29 +0200) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.0(release): >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x403b,0x20000) Probing 3 block devices...... done ZFS found no pools UFS found no partitions Failed to load '/boot/loader.efi' panic: No bootable partitions found! ## Application terminated, r = 1 Revert to U-Boot SPL 2019.07 with the same bootaa64.efi boot OK Henri