Date: Wed, 15 Oct 2014 03:35:45 -0400 (EDT) From: Terry Kennedy <TERRY@tmk.com> To: freebsd-arch@freebsd.org Subject: Re: [rfc] Add boot-time warning messages to PAE kernels Message-ID: <01PDRGFBJ8CO000821@tmk.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01PDRGFBJ8CO000821>