[rfc] Add boot-time warning messages to PAE kernels

[Warner Losh]

On Oct 13, 2014, at 8:57 AM, John Baldwin <jhb at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141013/2f2e7463/attachment.sig>