From owner-freebsd-arch@FreeBSD.ORG Wed Oct 15 07:37:12 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 85A8D298 for ; Wed, 15 Oct 2014 07:37:12 +0000 (UTC) Received: from server.tmk.com (server.tmk.com [204.141.35.63]) (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 5E186BEA for ; Wed, 15 Oct 2014 07:37:11 +0000 (UTC) Received: from tmk.com by tmk.com (PMDF V6.6 #37010) id <01PDRGCXWT4G000821@tmk.com> for freebsd-arch@freebsd.org; Wed, 15 Oct 2014 03:36:53 -0400 (EDT) Date: Wed, 15 Oct 2014 03:35:45 -0400 (EDT) From: Terry Kennedy Subject: Re: [rfc] Add boot-time warning messages to PAE kernels To: freebsd-arch@freebsd.org Message-id: <01PDRGFBJ8CO000821@tmk.com> 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: Wed, 15 Oct 2014 07:37:12 -0000 Well, that didn't go over well at all. Makes me wonder if I was being set up by somebody... Personally, I have nothing in this either way. My only experience with the subject area is seeing repeated questions about this on the forums and mailing lists. To address a number of the points raised: > No no no no no. People who are smart enough to build themselves a > different kernel should not get their noses rubbed in your idea of > what's right every time they boot. I run a PAE kernel for my own > reasons, and they are good reasons for me regardless of what you think > about it. They generally show up asking how to build a PAE kernel, because they were led somehow into thinking that PAE was the answer to their problem. Or they managed to build a PAE kernel, but it didn't fix whatever the meta-issue was that led them to PAE in the first place. This wasn't helped by the fact that various documents described the FreeBSD amd64 support as "experimental" until quite recently. For example r248857 finally took it out of the hardware notes. Perhaps if we can find out where users are obtaining incorrect advice to use a PAE kernel instead of amd64, those sources can be corrected as well? > And can we finally lose the mythology that PAE is somehow experimental > or inadequate? I've never encountered a driver that doesn't work with > PAE (I'm sure they exist, but again, people smart enough to build a > custom kernel should be smart enough to deal with testing it with the > devices they use). Well, a "grep nodevice /sys/i386/conf/PAE | wc -l" reports 46 "nodevice" statements disabling hardware which is not supported by the PAE kernel, as well as a complete disabling of module building. > PAE is the way to get NX bit on 32bit kernels. Educate me here - is this non-amd64-capable hardware being used in a production environment, or amd64-capable hardware being run in i386 mode for some reason? I haven't run into any i386 user code that wouldn't run on a FreeBSD amd64 kernel, so I'm trying to see why PAE is the desired solution here. Feel free to go "Because I do, the reasons are none of your business", but I'm genuinely interested. In particular, the several replies saying that for business reasons there can be no warnings would seem to be incompatible with running long out-of- production / out-of-warranty hardware (for the non-amd64-capable case). > The real issue with PAE is that auto-tuning easily makes non-working > configuration due to small KVA (1 or 2 GB) comparing with the available > physical RAM installed on the machine. It is more or less fine for 4GB > machine, but AFAIR, is on the edge for 8GB, and breaks afterward. > Lowering the user/kernel VA split helps somewhat. > > The solution for PAE issues is to implement separate address space for > kernel. It would add some overhead on each mode switch, but this is the > cost of being able to run what you need. This would seem to be an area in need of improvement. But if it doesn't affect the experienced people who are running PAE kernels for good reason, it just becomes another pitfall new users will have to learn about the hard way. > 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. Well, it's only 18 months too late if we start when the errant "amd64 is experimental" was excised from the hardware notes. I agree that a tunable in loader.conf makes perfect sense. That's why I prefaced this part of my original post with "[Possibly]". Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA