From owner-freebsd-arch@FreeBSD.ORG Mon Oct 13 15:27:49 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 5E095429 for ; Mon, 13 Oct 2014 15:27:49 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB9C1E1 for ; Mon, 13 Oct 2014 15:27:48 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id ey11so6060447pad.27 for ; Mon, 13 Oct 2014 08:27:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=EzQEjJycRTofBeRwB+n2wzDF2dxbYoPHh4D6zXPy1wk=; b=doqgWfCce4ncLMrEt+HgIgclDPGDn/HRNnkjrI8J9DBv6jXNSePYB2nMNnKAGwiCI5 K0PYCl/5XO/DzOQ5sjaMYDaxJLr8N/wMzZRhft++ZUZ/zc7uSJdQG9Qz0g2XQuMZ2KBl tiNWSYBbP63mTbh9p86VNTzk3amf5NXkZPRDF/9WOQJjZ0KzxJkxRa9p/Y7EzKsmON19 fNlBgUz/AGHSKi7yWADV5TEcqbXnu5TuvQ/7mO/1bkvv/zp+Idu34C+PDttTZYXLwFYN jNAB1JZjX94yM3b5NdyZEkecltYSEE41ULSy0LOvXtw2gxaSKrWrh5RZ1c2pr4qNYBU7 pJ1Q== X-Gm-Message-State: ALoCoQlyKw+rS2zDBgODbI73vbVGzkRqW19pADPZI7UVP7XnB6mnpa1+Z1ubbWGuvj6UaJAmKBx3 X-Received: by 10.68.178.97 with SMTP id cx1mr24448234pbc.25.1413214067792; Mon, 13 Oct 2014 08:27:47 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id k11sm7770525pbq.0.2014.10.13.08.27.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 08:27:46 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_620F4880-9C5B-47F5-ADD4-5AF82A7891A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [rfc] Add boot-time warning messages to PAE kernels From: Warner Losh In-Reply-To: <5523023.h2nJCgOPoX@ralph.baldwin.cx> Date: Mon, 13 Oct 2014 09:27:44 -0600 Message-Id: References: <01PDOI9M51BK0003PW@tmk.com> <5523023.h2nJCgOPoX@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) 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:27:49 -0000 --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 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--