Date: Mon, 13 Oct 2014 09:27:44 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Terry Kennedy <TERRY@tmk.com>, freebsd-arch@freebsd.org Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <BB035582-27C3-47B7-A288-70A4C0F65629@bsdimp.com> In-Reply-To: <5523023.h2nJCgOPoX@ralph.baldwin.cx> References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Oct 13, 2014, at 8:57 AM, John Baldwin <jhb@freebsd.org> wrote:
> 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 =
questions
>> 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 =
could be
>> addressed:
>>=20
>> 1) Boot PAE kernel on any amd64-capable processor - display a =
warning
>> message stating that the user should consider using the amd64 =
kernel
>> instead.
>>=20
>> 2) Boot PAE kernel on any processor - display a warning message that
>> driver support is limited on PAE kernels and that they receive =
less
>> 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 =
using
>> 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 =
kernel.
>> 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 =
optimal
>> kernel. I mention this because I was having a conversation with a =
user 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 subset =
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 =
regardless=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);
Where=92s warn64_2 defined :)
I=92d add a && !stfu_warn64 in there somewhere that=92s set as a =
tunable. It
is a good seat belt for the newbie running the wrong thing (though maybe
7 years too late), but experienced users may wish to stifle it for =
organizational
reasons. Some organizations have a no warning policy where they have to
do something about the warnings, even if there=92s nothing to do. =
Providing
an easy way to STFU the warning would allow them to run with a stock =
kernel
or perhaps (if done as a config option instead) a custom kernel config.
Warner
--Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJUO+9wAAoJEGwc0Sh9sBEAIj0P/0noRLNVVIA3MjATgM4griDQ
NuCOtocflpisAiluWvmcKbPoaeen22sFKxoqaY2cYz4T4szhCdDEZe63vShlZIpW
N1QlnArfP4gu3Aijcf6oxgTkqEnzHn0PZmXUopS/60dqSLWft8Q8ZzBOX7o+fP1s
gvRmL5vaf8W5w2yzOEFVCIbZNk5rykKb1cNKqmxU8GYuAQWXWniJPRm9J+9NftFG
sKKqDJHo+Sjj4NW7MwuhQDktV6XhKuLvoDSi4UgYGb87JvFV3EOJmitjaebGMoNI
Yx80Ch1QJ4ki9mLFTmBWak9JjJ1MbuNO/nd8B1vS8yOZrmJq38ecu3s9QZD9Y2QU
zmTxJPxMM+vovQtM7dCD5446xAf5+TdHJVihVUuQ5Q8MZ07IsUc1Z/BB8u3kHj15
rNoIxA+jjqcHain8ub9SrbUtsSb8xswRXuSZL8c7yAhyoOM+pGmzCKCZmDHYxZdN
P6R+HHzLJgR4LAIlfqs14W3S7wyBPmgbmG6lXFu3qU3LoqxMTRphKG5SQqN94AMa
nENNmVcGaP+a6PsSXPybt4XLB9JWezBFFGiizt6Jg3ncHhpy1nPhV8/DVwVngDec
BgB2X0DDRtPHyVrwh7xsw+WOxUmSAHdHWca1bL23ecvLYAH2VsszS9vMPDzX4ho2
X95akGqpYYWhWJ9oCCAA
=Luaj
-----END PGP SIGNATURE-----
--Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BB035582-27C3-47B7-A288-70A4C0F65629>