New CPUTYPE default for i386 port

[Warner Losh]

On Sat, Oct 5, 2019, 9:23 PM Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net>
wrote:

> > On Sat, Oct 5, 2019, 11:03 AM Rodney W. Grimes <
> > freebsd-rwg at 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 at freebsd.org
> > >
>
> --
> Rod Grimes
> rgrimes at freebsd.org
>