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 >