From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:35:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1792834; Mon, 13 Oct 2014 15:35:16 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60C402E4; Mon, 13 Oct 2014 15:35:15 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XdheU-000Hrr-Qb; Mon, 13 Oct 2014 15:35:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9DFZDvZ044271; Mon, 13 Oct 2014 09:35:13 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+sgQZf+CqlfROLcpOQ9r4t X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Ian Lepore To: Warner Losh In-Reply-To: References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> Content-Type: text/plain; charset="iso-8859-13" Date: Mon, 13 Oct 2014 09:35:13 -0600 Message-ID: <1413214513.12052.327.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s9DFZDvZ044271 Cc: Terry Kennedy , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:35:16 -0000 On Mon, 2014-10-13 at 09:27 -0600, Warner Losh wrote: > On Oct 13, 2014, at 8:57 AM, John Baldwin 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