Date: Mon, 13 Oct 2014 09:35:13 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: Terry Kennedy <TERRY@tmk.com>, freebsd-arch@freebsd.org Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <1413214513.12052.327.camel@revolution.hippie.lan> In-Reply-To: <BB035582-27C3-47B7-A288-70A4C0F65629@bsdimp.com> References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> <BB035582-27C3-47B7-A288-70A4C0F65629@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2014-10-13 at 09:27 -0600, Warner Losh wrote:
> On Oct 13, 2014, at 8:57 AM, John Baldwin <jhb@freebsd.org> wrote:
>=20
> > On Monday, October 13, 2014 12:56:09 AM Terry Kennedy wrote:
> >> [Inspired by an unrelated email conversation with jhb@]
> >>=20
> >> On the FreeBSD forums and also elsewhere, people frequently ask que=
stions
> >> about enabling PAE. Generally, this is because they don't know that =
amd64
> >> kernels will run on their hardware.
> >>=20
> >> I initially proposed a static warning message, similar to the ones =
that
> >> happen when a kernel is built with INVARIANTS or WITNESS, with some =
sort
> >> of warning that "You probably don't want to do this". On thinking it=
over
> >> and discussing with jhb@, I think there are three scenarios that cou=
ld be
> >> addressed:
> >>=20
> >> 1) Boot PAE kernel on any amd64-capable processor - display a warni=
ng
> >> message stating that the user should consider using the amd64 ke=
rnel
> >> instead.
> >>=20
> >> 2) Boot PAE kernel on any processor - display a warning message tha=
t
> >> driver support is limited on PAE kernels and that they receive l=
ess
> >> testing than non-PAE kernels.
> >>=20
> >> 3) [Possibly] Boot i386 kernel on amd64-capable system w/ > 4GB of =
RAM -
> >> display an informational message that the user should consider u=
sing
> >> the amd64 kernel instead.
> >>=20
> >> This way, anyone that still needs to run a PAE kernel can, but the =
users
> >> who choose it by accident or mistake will be guided to the amd64 ker=
nel.
> >> Adding a similar message to i386 kernels on amd64-capable hardware w=
/ more
> >> than 4GB of RAM will likewise direct those users toward a more optim=
al
> >> kernel. I mention this because I was having a conversation with a us=
er who
> >> was trying to get ZFS going but "ran out of memory" on a 12GB system=
due
> >> to using the i386 kernel.
> >>=20
> >> All of this information (processor capability flags and memory size=
)
> >> is available early enough in the boot process that the messages can =
be
> >> displayed near the beginning of the kernel messages.
> >>=20
> >> Non-amd64-capable systems that have > 4GB were always a small subse=
t of
> >> the population, and that hardware has aged enough that much of it is=
no
> >> longer used in its original role as business servers. These are pre-=
Socket
> >> 604 systems, for example. amd64-capable hardware has been available =
for
> >> more than 10 years from both AMD and Intel at this point.
> >=20
> > I actually think we should consider doing this for all i386 kernels r=
egardless=20
> > of the 4GB of RAM check. Something like this:
> >=20
> > diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c
> > index 9d98f0e..6fbf419 100644
> > --- a/sys/i386/i386/machdep.c
> > +++ b/sys/i386/i386/machdep.c
> > @@ -4067,3 +4067,17 @@ outb_(u_short port, u_char data)
> > }
> >=20
> > #endif /* KDB */
> > +
> > +static void
> > +warn64(void *arg __unused)
> > +{
> > +
> > + if ((cpu_vendor_id =3D=3D CPU_VENDOR_INTEL ||
> > + cpu_vendor_id =3D=3D CPU_VENDOR_AMD ||
> > + cpu_vendor_id =3D=3D CPU_VENDOR_CENTAUR) &&
> > + amd_feature & AMDID_LM)
> > + printf("WARNING: 64-bit capable CPU, consider running "
> > + "FreeBSD/amd64 instead.\n");
> > +}
> > +SYSINIT(warn64, SI_SUB_COPYRIGHT, SI_ORDER_THIRD + 3, warn64, NULL);
> > +SYSINIT(warn64_2, SI_SUB_LAST, SI_ORDER_THIRD + 3, warn64, NULL);
>=20
> Where=FFs warn64_2 defined :)
>=20
> I=FFd add a && !stfu_warn64 in there somewhere that=FFs set as a tunabl=
e. It
> is a good seat belt for the newbie running the wrong thing (though mayb=
e
> 7 years too late), but experienced users may wish to stifle it for orga=
nizational
> reasons. Some organizations have a no warning policy where they have t=
o
> do something about the warnings, even if there=FFs nothing to do. Provi=
ding
> an easy way to STFU the warning would allow them to run with a stock ke=
rnel
> or perhaps (if done as a config option instead) a custom kernel config.
>=20
> Warner
Inded, if this (anti-)feature goes in, we need an option to squelch the
warning, preferably a compile-time option.
We've got customers who think it's their job to spelunk through logs and
raise a fuss about things they've never seen before or don't understand.
That generates complaints to support reps who complain to managers who
don't understand any of it except that a customer is complaining and
insist that "something be done". If we must be saddled with "You don't
know what you're doing" warnings, we have to at least be able to shut
them up when it turns out we do know what we're doing.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1413214513.12052.327.camel>