# RAM, and two physical i386 CPUs



## GROND (May 10, 2014)

Hey all, I have a SuperMicro SuperWorkstation 7033A-TB, with two physical 32 bit Xeons. I wanted to max out the memory on it, so I got four 2G DIMMs, PC2-2100R ECC dual rank. I'm aware of the memory limitations of the i386 arch, but I figured 4G per CPU with two CPUs would work out. The SuperMicro documentation specifies 8G of RAM as the supported maximum, corroborating my assessment.  However, the system is only recognizing 4G of RAM.

I figure the problem could be one of several things: A) the DIMMs are dual rank and the system might only recognize 4 ranks, but there is no mention of a rank limit on SuperMicro's documentatiom; B) the system might not even be recognizing the second CPU, and I'm not aware of how to check this (BIOS sees it, and dmidecode lists it); or C) there is some other configuration I need to perform to get it all to work.

I'm using the machine to host several different services, using jails, so having the RAM is pretty essential. Any thoughts or guidance? And what tools could I use to troubleshoot these sort of issues in the future?


----------



## kpa (May 10, 2014)

How are you going to divide the RAM between the two CPUs? I'm not aware of any method of doing that with a standard i386 architecture where the memory is shared between the multiple CPUs by design.


----------



## GROND (May 10, 2014)

I figured each of the two memory channels would map to a single CPU. I'm no expert, that's just what I had figured. Why would the documentation list 8G as supported then?


----------



## kpa (May 10, 2014)

The memory channels are for parallel access to the memory to increase performance but the CPUs will still share the memory. The full 8GBs can be used with a 32-bit OS if PAE is used:

https://en.wikipedia.org/wiki/Physical_Address_Extension

However, the FreeBSD's implementation of PAE never really matured unlike in some other OSes, it's not recommended to use in production. Better to get hardware that supports the 64-bit version of FreeBSD.


----------



## GROND (May 10, 2014)

It's not production (it's running Minecraft servers for my friends), so I'm gonna give PAE a shot.

Thanks kpa


----------



## SirDice (May 11, 2014)

GROND said:
			
		

> It's not production (it's running Minecraft servers for my friends), so I'm gonna give PAE a shot.


Applications need to be specifically written for PAE to make use of the extra memory. Most applications aren't.


----------



## GROND (May 12, 2014)

Well, I can always try and see, and roll back to GENERIC if it's not worth it.

One problem, though: with PAE, modules aren't built. Now  I can't use ezjail, because the nullfs mount fails without the nullfs module. I'm at a loss with this one. How/can I get the modules installed with the PAE kernel?

**EDIT: typo


----------



## BSD-Kitsune (May 12, 2014)

Assuming the modules are available for use, using # kldload <module> will work. However, if you rebuilt the kernel properly the modules should've built. Here is the FreeBSD page that explains custom kernel building: http://www.freebsd.org/doc/en/books/han ... lding.html

There it says to modify /etc/make.conf so I'd check that and rebuild the modules.

Since you're running Minecraft I'll just chime in on that, since it runs on top of Java, I'd check to see if OpenJDK/IcedTea has a switch for PAE. Otherwise, its not going to be worth it for your application. A quick Google suggested this is possible, but I'd look more into that if I were you.


----------



## GROND (May 12, 2014)

From the /usr/src/sys/i386/conf/PAE config file:

```
# Don't build modules with this kernel config, since they are not built with
# the correct options headers.
makeoptions	NO_MODULES=yes
```
I just found the FreeBSD FAQ that says 





> Using PAE has some drawbacks... loadable modules are not supported. This means all drivers must be compiled into the kernel.


How would I go about doing this (and being sure I didn't miss anything)?


----------



## User23 (May 13, 2014)

Build a custom kernel with all the drivers you need configured in the KERNCONF.


----------



## Crivens (May 14, 2014)

SirDice said:
			
		

> GROND said:
> 
> 
> 
> ...


This sounds strange. In my understanding, the PAE is only part of the kernel code. Also, the applications can only use memory which is mapped to their process space, thus it is virtualised anyway. It only seems that one process can access almost all of it's 4GB space. So, more than one process with a demand of up to 4GB can be kept in core with PAE. But please correct me if I am wrong on this.

According to wikipedia, kernel modules are supported in PAE kernels if they are also build with PAE enabled. Some drivers will habe problems, tough.


----------



## SirDice (May 14, 2014)

It's been a while but as far as I know a 32 bit OS will assign each process a 4 GB memory map. That's the limitation and it's a hardware one, in 32 bit mode the MMU simply doesn't map more than 4 GB. PAE adds some functions to allow mapping of more memory maps. More or less in the same way as the old "real mode" was able to access more than 1 MB. But as I said, applications need to specifically use these functions to access memory above the 4 GB limitation in the same way old "real mode" applications had to add specific code to address memory above 1 MB. If applications do not use the PAE features it will be limited to 4 GB, regardless of how much physical memory the machine really has.


----------

