Fatal trap 12: page fault while in kernel mode

L

lukeido

I'm trying to install FreeBSD 7.1 amd64 on a Athlon 64 X2

At a certain point it shows:
Code: 
Fatal trap 12: page fault while in kernel mode
cpuid = 0: apic id = 00
fault virtual address = 0x8
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff806d16a9
stack pointer = 0x10:0xffffffff810517d0
frame pointer = 0x10:0x3
code segment = base 0x0, limit 0xfffff, type 0x1b
             = DPL 0, pres1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
What is this and what could be the problem?
 
Impossible to answer based on that alone. Try FreeBSD 8.2 or 9.0-BETA3. No reason to stick with an outdated version.
 
same error on Intel D510MO motherboard

I had that same error heading "Fatal trap 12: page fault...", although my fault code was "= supervisor write, page not present". The instruction, stack and frame pointers were different addresses, code segment and processor flags results were identical to yours. My "current process was =283 (ifconfig)".

Anyway, bottom line, it was a bad motherboard. I swapped in a new Intel D510MO and it worked fine. Another good FreeBSD 7.2 imaged HDD also failed on the bad board, and the original HDD from the bad board worked in another system.

Also interesting to note that a Windows 7 HDD booted fine and ran Passmark Burn In Test CPU Tests without errors. But it did not like FreeBSD 7.2.
 
A similar case

Note for posterity:

I also ran into this issue on an HPC cluster of Dell R415s. The issue was resolved by a firmware upgrade (which was *very* difficult to achieve due to Dell's mostly-broken and incredibly slow upgrade tools).

The problem only occurred on a particular configuration: 16 GB RAM, single CPU. The exact same systems with dual CPUs and either 16 GB or 32 GB RAM have never crashed once regardless of firmware version. (eight machines running FreeBSD 8.2 and 8.3) Since the firmware upgrade about six months ago, there have been zero system crashes.

The problem did occur with factory firmware versions on two different motherboards with the single CPU configuration and was cured by firmware upgrades on both of them. I stripped and swapped the motherboards of two machines and kept everything else in the same chassis to see if the problem would follow the motherboard. It did not.
 
outpaddling said:
The problem only occurred on a particular configuration: 16 GB RAM, single CPU. The exact same systems with dual CPUs and either 16 GB or 32 GB RAM have never crashed once regardless of firmware version. (eight machines running FreeBSD 8.2 and 8.3) Since the firmware upgrade about six months ago, there have been zero system crashes.

The problem did occur with factory firmware versions on two different motherboards with the single CPU configuration and was cured by firmware upgrades on both of them. I stripped and swapped the motherboards of two machines and kept everything else in the same chassis to see if the problem would follow the motherboard. It did not.
Click to expand...
Dell PowerEdge systems of the x10 and newer generations (like yours) do a lot more tricks with their memory controllers. The usual giveaway is that if you see "memory mirroring" or similar (whether or not you're using it), you have one of these.

The problem may also happen with other memory sizes - for example, if you've got 16 GB as 8 2 GB DIMMS across both sets of sockets, it might also happen with 8 of 1 GB DIMMs in those same sockets.

The BIOS update probably fixed the way the memory controller(s) are configured for that type of memory / CPU layout.
 
You must log in or register to reply here.
Back
Top