Haswell CPU with more than 4 GiB RAM

[mounty1]

I'm sorry to ask what must be a FAQ but forum searches for "64 bit" are turned into searches for "64" which is unhelpful, and there are hundreds of hits.

I have an Intel NUC with the Haswell chipset and 8 GiB RAM. I don't particularly want to run 64-bit applications but I do want to use all the RAM so AIUI I just need a 64 bit kernel. So in makeconfig I set processor family to Core 2 / Newer Xeon, and 64 bit kernel to X. However, the kernel build fails with

[vaxbrat]

Anything after core2 can handle 64 bit (okay maybe a prescott class pentium 4 before that) and Haswell is quite current. I suspect your toolchain (ie @system) is 32 bit only. Did you start your install (whenever that was) with only an x86/32bit iso and then decided to go 64 bit? It's probably been 10+ years since I pulled a stunt like that.

[mounty1]

[vaxbrat]

Short of going full 64 bit you might research PAE mode. However I think that was more of an ugly hack for certain versions of "Winders"

[vaxbrat]

There might have been some Intel Atom versions that were 32 bit only. Historical though since I saw somewhere that Chipzilla has decided to put a bullet in the head of the family line.

Ok so you'll take more space and more processor time building two of everything with multilib. Are you working with a single board system setup or something?

[mounty1]

So let's be clear about this: are you stating quite definitely that to build a 64 bit kernel, I must use a x86_64 stage3? I find that a bit puzzling since gcc has the -m64 option to build 64 bit objects, and since the kernel is the bottom of the software stack, it doesn't depend on any existing libraries; i.e., the build is entirely self-contained.
_________________
Michael Mounteney

[vaxbrat]

I had one of those little atom based laptops from dell. It's around here somewhere. It was a 9" display so might even be smaller than some of those phablets that have been coming out for android Anyway, the thing was dog slow staying up to date with the gentoo I put in the place of the dell supplied ubuntu, so I set up a 32 bit chroot environment on one of my AMD boxes to build for the poor thing. You might set up the essentials on your box for 64 bit and then have a 32 bit chroot for your userland stuff.

[vaxbrat]

MAYBE you could do something with a 64 bit initrd on /boot pivoting into a 32 bit userland root fs, but I wouldn't hold my breath.

[The Doctor]

You have to reinstall. You can't change a 32 bit system into a 64 bit system. PAE is a dead end so I wouldn't bother. In fact, x86 itself is dead. 64 bit is the way everything is going.

There isn't any point to trying to cling to a 32 bit paradigm. 64 bit programs are not that much larger than 32 bit ones and in many cases they actually run faster.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[krinn]

there's the x32 arch that you can use also. while i know gentoo have a x32 support, i don't know its level of maturity.

[NeddySeagoon]

mounty1,

Look in /proc/cpuinfo at the FLAGS line. If you have the lm flag (long machine), your hardware is 64 bit capable.
Its game over if that's missing.

Using PAE and the highmem jiggery pokery in the kernel should be avoided. Its a RAM paging mechanism. As its still 32 bit, ecah process still only has a 4G address range. Its considered a very bad thing to switch the kernel out, since it can't switch itself back in again. That weans each process gets less than 3G. Consider it like having swap in RAM.

I haven't heard much about x32 for a while. It gives you the 64 bit instruction set, along with the extra registers but pointers are only 32 bits.
The idea was to mimimise RAM use while keeping the other 64 bit goodies.

If you really want a 64 bit kernel under your 32 bit userland, you will need to cross compile it elsewhere. SPARC used to do that. It had a special compiler called kgcc that was only used to build the 64 bit kernel on the 32 bit userland.
Hmm ... I wonder if that works on i686 too?
The ebuild for 5.3.0 says ...

[mounty1]

OK OK, thanks all, I have to make a decision now. For the time being, I've gone ahead anyway and switched-in PAE so I can at least use all the memory I paid-for, even if sub-optimally. Frankly I just want to try out my new hardware. I'm a bit apprehensive of going to 64 bits because inevitably it increases data and code size so PAE seemed like a better idea. I accept what various people have said about it. So I'll probably just get it all up and running, have a play and once the novelty has worn off, I'll do it all again with x86_64. There's enough disk space to leave the 32 bit system intact while I build the 64 bit system.

Oh, the other problem with a 64 bit system is running Skype*, which regrettably I have to do. For that reason alone, I'll have to run a dual-wordsize system, which is another complication with which I've not previously had to deal. Still, if I didn't like dealing with build challenges, I'd be using Ub#$&u.

____
* -- only available pre-compiled.
_________________
Michael Mounteney

[krinn]

i myself got bored by pae, once you reach 4g, the app gets oom and call oom killer (you don't swap out the app, that is running).
but oom killer is not (yeah really not) always picking up the right app to kill, and randomly kill the "suppose" good candidate for that.

and while Z goes oom, Y is killed, Z eat Y space, then H, Z eat H space, then K... until it finally decide to kill Z (but in between you've lost Y, H, K...).

It works pretty fine if Z never try to get the whole 4G else.
And if you wonder why cares about Y,H or K, it's because generally X (this time really X and not X as a random app name) is quiet a good candidate to gets killed. And oom killer do see X as a tasty thing to kill to gets memory back.

[frostschutz]

go with 64bit multilib (which allows running individual 32bit apps such as skype, zsnes, various games, ...) unless you have very good reason not to. It's what everyone uses and what sees the most testing... and you're not the only one using skype in such an environment, if you have specific problems, maybe you should ask.

I'm not sure how to build a 64bit kernel from 32bit userland but if you're not tight on storage space, you could keep a 64bit chroot around just for that or just build it with a 64bit livecd.

With OOM I think that should be a misunderstanding, that only happens when the system runs out of memory as a whole. If an individual process hits its individual 3GB limit, but the system itself still has memory, it will only affect that single process and not involve the global (KAB-)OOM

[The Doctor]

The size increase in 64 bit is negligible. You won't notice.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[vaxbrat]

FWIW when I "upgraded" from 32 bit to 64 bit on my main box 10+ years ago, gentoo still had the old "bootstrap" procedure where you started with a stage1. IIRC it was a matter of flipping the arch flags in make.conf and then going through the bootstrap process on the 32bit stage3 2 times or so before you had a stable toolchain.

If you really feel reckless maybe try dropping a 64 bit multilib autobuild into the middle of your 32 bit system (sans portage) to see what happens before you wipe and re-install root.

[NeddySeagoon]

vaxbrat,

It will break horribly.

To do the switch, you need a 64 bit toolchain all in one go and that 64 bit toolchain can only run on top of a 64 bit kernel.
Not even a stage 1 allows a change from 32 bit to 64 bit.

The adventurous could use crossdev to build a kernel and bits of a 64 bit install (including a kernel), then contine from there.
Its not that simple and its not documented.

A 64 bit multilib reinstall is the way ahead.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Buffoon]

Actually, since kernel build does not use your CFLAGS (unless you go experimental) you can use liveCD in 64 bit mode and build 64 bit kernel. When it breaks you get to keep the pieces ...

[NeddySeagoon]

Buffoon,

The liveCD does not provide a toolchain - that needs a stage3.
As you say, you get to keep the pieces.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Buffoon]

Whoops. In another Gentoo machine then.

[NeddySeagoon]

Buffoon,

Well, in a chroot at least. If you were to do it in another partition, it would be a new install :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Buffoon]

Actually I do it for some weak nettops in NFS chroot.

[mounty1]

So I want to dual-boot this NUC with the following:

• the 32-bit PAE system as already installed from a i686 stage3.
• the recommended hybrid 64-bit system installed from a x86_64 stage3.

Is it possible to get Grub2 to set up the required two boot-menu entries?
_________________
Michael Mounteney

[vaxbrat]

I haven't need to do a multiplatform boot with grub2 yet but I think there was a faq on the upstream website for pretty much any contingency. You will be doing a lot of script fragment work in /etc/grub.d to set it up. Don't know about having it scan both root partitions, but you can at least probably put the second boot entr(y|ies) into /etc/grub.d/40_custom by hand.

[Tony0945]

Can't you chain load with grub2? https://wiki.gentoo.org/wiki/GRUB2/Chainloading
I chain load XP and Ubuntu (grub2) with grub legacy all the time. Also, I chain load 32-bit Gentoo from the 64-bit Gentoo /boot partition.