From owner-freebsd-current@freebsd.org Thu Feb 28 19:21:27 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA680151495E for ; Thu, 28 Feb 2019 19:21:27 +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 5D3D583891; Thu, 28 Feb 2019 19:21:26 +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 x1SJLOpl018518 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 11:21:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1SJLOnC018517; Thu, 28 Feb 2019 11:21:24 -0800 (PST) (envelope-from sgk) Date: Thu, 28 Feb 2019 11:21:24 -0800 From: Steve Kargl To: Cy Schubert Cc: cem@freebsd.org, John Baldwin , freebsd-current Subject: Re: r343567 aka PAE vs non-PAE merge breaks i386 freebsd Message-ID: <20190228192124.GB18089@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190222033924.GA25285@troutmask.apl.washington.edu> <20190222060410.GA25817@troutmask.apl.washington.edu> <20190223032644.GA14058@troutmask.apl.washington.edu> <20190223163947.GB18805@troutmask.apl.washington.edu> <20190228183214.GA17372@troutmask.apl.washington.edu> <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <866D86B4-6E47-46BA-BC4C-6E98DA94403E@cschubert.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 5D3D583891 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.04 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.05)[-0.046,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.80)[0.798,0]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; NEURAL_SPAM_MEDIUM(0.54)[0.544,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:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.05)[ip: (0.10), ipnet: 128.95.0.0/16(0.16), asn: 73(0.06), country: US(-0.07)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 19:21:28 -0000 On Thu, Feb 28, 2019 at 11:14:51AM -0800, Cy Schubert wrote: > On February 28, 2019 11:06:46 AM PST, Conrad Meyer wrote: > >On Thu, Feb 28, 2019 at 10:32 AM Steve Kargl > > wrote: > >> This is interesting as well. Does this mean that amd64 is now > >> the only tier 1 platform and all other architectures are after > >> thoughts? > > > >This has been the de facto truth for years. i386 is mostly only > >supported by virtue of sharing code with amd64. There are efforts to > >promote arm64 to Tier 1, but it isn't there yet. Power8+ might be > >another good alternative Tier 1 candidate eventually. None have > >anything like the developer popularity that amd64 enjoys. > > > > We deprecated and removed support for 386 and 486 processors. We should consider removing support for low end Pentium as well. I'm specifically thinking of removing the workarounds like F00F. Are there any processors that are still vulnerable to this? > Ahem, sys/i386/conf/GENERIC contains "cpu I486_CPU". Is that a typo? -- Steve