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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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@]
>>
>> 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.
>>
>> 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:
>>
>> 1) Boot PAE kernel on any amd64-capable processor - display a warning
>> message stating that the user should consider using the amd64 kernel
>> instead.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>
> I actually think we should consider doing this for all i386 kernels regardless
> of the 4GB of RAM check. Something like this:
>
> 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)
> }
>
> #endif /* KDB */
> +
> +static void
> +warn64(void *arg __unused)
> +{
> +
> + if ((cpu_vendor_id == CPU_VENDOR_INTEL ||
> + cpu_vendor_id == CPU_VENDOR_AMD ||
> + cpu_vendor_id == 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’s warn64_2 defined :)
I’d add a && !stfu_warn64 in there somewhere that’s 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’s 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
[-- Attachment #2 --]
-----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-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BB035582-27C3-47B7-A288-70A4C0F65629>