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" >