# 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 

```
CPU you selected does not support x86_64 instruction set
```

.  Changing processor family to Generic x86_64 doesn't help.  What should I be doing to use all the RAM?

----------

## 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 wrote:*   

> 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?

 

Yes;  this is my first installation on a system with more than 4 GiB RAM.  So there's no way round it; I have to use the x86_64 stage3?  I do only want a 32 bit userland.

----------

## 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.

----------

## 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   :Very Happy:   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.

----------

## 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 ... 

```
DESCRIPTION="64bit kernel compiler"

# Works on mips and sparc; all other archs, refer to bug #228115

KEYWORDS="~hppa ~mips"
```

----------

## 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.

----------

## 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.  :Laughing: 

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.

----------

## 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.

----------

## 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.

----------

## Buffoon

Whoops. In another Gentoo machine then.   :Embarassed: 

----------

## NeddySeagoon

Buffoon,

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

----------

## 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?

----------

## 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.

----------

