FreeBSD 10.0-RELEASE: Can not boot a x86 PAE kernel

Simba7

Simba7

I've tried it several times, but it just will not boot a PAE-enabled kernel on a HP DL580G2.

This system has 32GB of RAM, 4x 3.0GHz Xeon processors, and 4x147GB Drives. I built a PAE-enabled kernel and when it loads, it pauses after the splash screen for 10 seconds and then crashes.
 
Don't use PAE, really. Use the amd64 version of FreeBSD. PAE doesn't do what most people think it does. It will not allow you to make full use of the 32 GB memory. Applications have to specially be built to use PAE and most of them aren't. So, do yourself a favour and use a 64 bit OS.
 
SirDice said:
Don't use PAE, really. Use the amd64 version of FreeBSD. PAE doesn't do what most people think it does. It will not allow you to make full use of the 32 GB memory. Applications have to specially be built to use PAE and most of them aren't. So, do yourself a favour and use a 64 bit OS.
Click to expand...
If I could run a 64 bit OS on a 32 bit processor, I would.
 
Then I'm afraid you're out of luck. You really, really don't want to enable PAE.
 
So, is there any proposed solution for using more than 3 GiB of memory on 32-bit machines? I'm not interested in applications having a larger address space, since I don't run any single application that would need that.
 
It's a technical restriction that is very hard to work around in a portable way. There's always certain areas of memory that have to be reserved from usable memory area (the famous 2^32 addresses since we are talking about 32-bit CPUs) because peripheral devices require memory mapped I/O and those areas can add up to a gigabyte of memory in some cases. If the CPU is unable to address more than 4 gigabytes of memory there's really no solution. PAE uses the Intel-only feature of i386 CPUs that allows the CPU to have kind of 36-bit address space but it's done in such a way that it causes more problems than solves. At best the extra memory can be used as extra buffer cache. The only real portable solution is to migrate to the AMD64 (aka x64) architecture.
 
If you're still using non-x64 capable hardware, I'd suggest you're also at the point where you should be planning for hardware failure in any case.

Yeah, it sucks, but even intel had EM64T machines available in 2004 - with the mainstream intel CPUs being x64 capable in 2007.
 
throAU said:
If you're still using non-x64 capable hardware, I'd suggest you're also at the point where you should be planning for hardware failure in any case.
Click to expand...
For desktop machines, that may be the case. For industrial, embedded, and low-power servers, that is not at all the case. For example, Intel is actively developing new Atom chips, which are still de-facto bound to be 32 bit machines (even though the core is 64-bit capable, motherboards and BIOS tend to disable that).
 
ralphbsz said:
throAU said:
If you're still using non-x64 capable hardware, I'd suggest you're also at the point where you should be planning for hardware failure in any case.
Click to expand...
For desktop machines, that may be the case. For industrial, embedded, and low-power servers, that is not at all the case. For example, Intel is actively developing new Atom chips, which are still de-facto bound to be 32 bit machines (even though the core is 64-bit capable, motherboards and BIOS tend to disable that).
Click to expand...

If you purchased ATOM with the intent of using more than 4 GB of RAM, you're "doing it wrong".
 
I thought that the Xeon processors in DL580G2 were 64 bit. The Xeon 3.2GHz cpus that were in the DL380 I had were 64 bit. Are you sure that your system is not 64bit compatible?
 
rrichard said:
I thought that the Xeon processors in DL580G2 were 64 bit. The Xeon 3.2GHz cpus that were in the DL380 I had were 64 bit. Are you sure that your system is not 64bit compatible?
Click to expand...
Yes, I am very sure they are 32-bit processors. They are Intel Xeon 3.0GHz Gallatin Processors, all 4 of them.
 
I would probably take out all memory and leave 4 GB in there to run FreeBSD on. Even if you can get PAE booting the added memory will just sit there sucking up power and not doing anything. You may have some other hardware that could use the memory you took out of this one.
 
throAU said:
If you purchased ATOM with the intent of using more than 4 GB of RAM, you're "doing it wrong".
Click to expand...
I have an Atom, less than 2 years old, and it has exactly 4 GB of RAM in hardware. FreeBSD uses 3 GB of it, the rest is "wasted". Being able to use the remaining GB would be pretty, even if it only gets used for file system buffer cache. But it is not terribly important, since that one extra GB would not significantly increase the performance of the system. The extra GB might prevent a few disk IOs from happening, but my system is so underutilized, the working set in the buffer cache is not a big issue. So I'm not going to invest more than a few minutes of chatting on a forum into making it go. Now, for someone else who is stuck on 32 bit CPUs, but absolutely needs to use more memory, that tradeoff might look different. More power to them!
 
You might want to turn off "System BIOS Cacheable" and "VGA BIOS Cachaeble" in the BIOS if you have it. Those settings cache both into memory for faster access but FreeBSD doesn't use them. But they are going to use some of that precious memory.
 
(OT: This discussion is getting further and further afield)
SirDice: I actually tried that in the BIOS on my Jetway board, once. Unfortunately, BIOSes are not the best-written pieces of software, and after I did that, the machine completely lost its VGA output, and completely refused to boot (no disk access). So I had to take the hardware apart and find the "reset BIOS settings to factory default" jumper. Which is quite a bit of work (server connected via many cables to the outside world, compact case with MoBo buried deep underneath stuff). I don't think I'll try that again, it's not worth the hassle for a measly 1 GB of memory.

People with different motherboards should probably listen to your advice.
 
I had the exact same thing happen with a Compaq ML370. It only happens with FreeBSD 10.0-RELEASE.
 
I'd take the time spent trying to make PAE work, and spend the time looking for discarded hardware of 64 bit nature.

I myself have now decommissioned 2 generations of machine that are 64 bit capable, I'd wager picking something up that CAN use more than 4 GB of RAM and run x64 will not break the bank (e.g., even the N54L Microserver can do 16 GB and the base chassis is about $250, new - you can likely pick up a second-hand N36L way cheaper - or some other discarded hardware (e.g., an old Pentium D or Core 2 system) even cheaper than that), and you'll gain processing speed, less power consumption and higher memory/IO throughput as a bonus.

Unless you're feeling particularly masochistic and just wanting to make PAE work for kicks... I'd avoid.


edit:
As an example - a friend has picked up a few discarded PowerEdge 2950s for his home lab. He got them free from his place of business. I'm currently decommissioning this generation of machine in my environment as well.

I'm not saying you'll get things THAT cheap (free), but I'd certainly be looking for that sort of generation of machine which is likely now end of warranty/end of support, and being replaced by businesses as part of their 3-5 yearly hardware refresh.

I'm assuming this is for home use. If you're still running that in production... :O
 
Bringing up an old thread.

Looks like it does still exist in FreeBSD 11.0-RELEASE as well. It runs fine with 16GB (32GB / 2 for mirroring) and 24GB (24GB without mirroring). As soon as I bump it up to 28GB or 32GB, it faults.

This is the same HP ProLiant DL580G2 with 4x Intel Xeon 3.0/512K/4M processors (all 32bit). It works fine in Gentoo Linux and Windows Server 2008.

I am still operating this old server due to others possibly having the same issues, along with using it for other 32bit tasks. Unless it is isolated to just this series.

Code: 
Fatal trap 12: page fault while in kernel mode
cpuid = 0 ; apic id = 00
fault virtual address   = 0x7fd31000
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0x8110cc31
stack pointer           = 0x28:0x820f8c50
frame pointer           = 0x28:0x820f8c78
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran
processor eflags        = resume, IOPL = 0
current process         = 0 ()
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x80b64a2f at ??+0
#1 0x80b145b5 at ??+0
#2 0x80b1449b at ??+0
#3 0x8111a2ba at ??+0
#4 0x8111a4a4 at ??+0
#5 0x81119d2f at ??+0
#6 0x8110261a at ??+0
#7 0x80eba012 at ??+0
#8 0x80ea5f38 at ??+0
#9 0x80a8e2b7 at ??+0
#10 0x802cb096 at ??+0
 
You must log in or register to reply here.
Back
Top