There are currently 3 active/semi-active
branches in the FreeBSD Subversion
Repository. (Earlier branches are only changed
very rarely, which is why there are only 3
active branches of development):

stable/10/ AKA
10-STABLE

stable/11/ AKA
11-STABLE

head/ AKA
-CURRENT AKA
12-CURRENT

HEAD is not an actual branch tag.
It is a symbolic constant for
the current, non-branched development
stream known as
-CURRENT.

Right now, -CURRENT is the
12.X development stream; the 11-STABLE
branch, stable/11/, forked off from
-CURRENT in April 2016 and the
10-STABLE branch, stable/10/, forked off from
-CURRENT in August 2015.

This message is not enough. While the instruction
pointer value is important, it is also configuration
dependent as it varies depending on the kernel image.
If it is a GENERIC kernel
image from one of the snapshots, it is possible for
somebody else to track down the offending function, but
for a custom kernel, only you can tell us where the fault
occurred.

To proceed:

Write down the instruction pointer value. Note
that the 0x8: part at the beginning
is not significant in this case: it is the
0xf0xxxxxx part that we
want.

When the system reboots, do the following:

%nm -n kernel.that.caused.the.panic | grep f0xxxxxx

where f0xxxxxx is the
instruction pointer value. The odds are you will not
get an exact match since the symbols in the kernel
symbol table are for the entry points of functions and
the instruction pointer address will be somewhere
inside a function, not at the start. If you do not
get an exact match, omit the last digit from the
instruction pointer value and try again:

%nm -n kernel.that.caused.the.panic | grep f0xxxxx

If that does not yield any results, chop off
another digit. Repeat until there is some sort of
output. The result will be a possible list of
functions which caused the panic. This is a less than
exact mechanism for tracking down the point of
failure, but it is better than nothing.

However, the best way to track down the cause of a
panic is by capturing a crash dump, then using
kgdb(1) to generate a stack trace on the crash
dump.

In any case, the method is this:

Make sure that the following line is included in
the kernel configuration file:

Note:

If KERNCONF is not included,
the GENERIC kernel will instead
be built and installed.

The make(1) process will have built two kernels.
/usr/obj/usr/src/sys/MYKERNEL/kernel
and
/usr/obj/usr/src/sys/MYKERNEL/kernel.debug.
kernel was installed as
/boot/kernel/kernel, while
kernel.debug can be used as the
source of debugging symbols for kgdb(1).

To capture a crash dump, edit
/etc/rc.conf and set
dumpdev to point to either the swap
partition or AUTO. This will cause the
rc(8) scripts to use the dumpon(8) command to
enable crash dumps. This command can also be run
manually. After a panic, the crash dump can be recovered
using savecore(8); if dumpdev is
set in /etc/rc.conf, the rc(8)
scripts will run savecore(8) automatically and put
the crash dump in /var/crash.

Note:

FreeBSD crash dumps are usually the same size as
physical RAM. Therefore, make sure there is enough
space in /var/crash to hold the
dump. Alternatively, run savecore(8) manually
and have it recover the crash dump to another directory
with more room. It is possible to limit the
size of the crash dump by using options
MAXMEM=N where
N is the size of kernel's
memory usage in KBs. For example, for 1Â GB
of RAM, limit the kernel's memory usage to
128Â MB, so that the crash dump size
will be 128Â MB instead of 1Â GB.

Once the crash dump has been recovered , get a
stack trace as follows:

Note that there may be several screens worth of
information. Ideally, use script(1) to
capture all of them. Using the unstripped kernel image
with all the debug symbols should show the exact line of
kernel source code where the panic occurred. The stack
trace is usually read from the bottom up to trace
the exact sequence of events that lead to the crash.
kgdb(1) can also be used to print out the contents of
various variables or structures to examine the system
state at the time of the crash.

Tip:

If a second computer is available, kgdb(1) can
be configured to do remote debugging, including setting
breakpoints and single-stepping through the kernel
code.

Note:

If DDB is enabled and the
kernel drops into the debugger, a panic
and a crash dump can be forced by typing
panic at the ddb
prompt. It may stop in the debugger again during the
panic phase. If it does, type
continue and it will finish the crash
dump.

18.6.

Why has dlsym() stopped working
for ELF executables?

The ELF toolchain does not, by default, make the
symbols defined in an executable visible to the dynamic
linker. Consequently dlsym()
searches on handles obtained from calls to
dlopen(NULL, flags) will fail to find
such symbols.

To search, using
dlsym(), for symbols present in the
main executable of a process, link the
executable using the --export-dynamic
option to the ELF linker (ld(1)).

18.7.

How can I increase or reduce the kernel address space
on i386?

By default, the kernel address space is 1Â GB
(2Â GB for PAE) for i386. When running a
network-intensive server or using
ZFS, this will probably not be
enough.

Add the following line to the kernel configuration
file to increase available space and rebuild the
kernel:

options KVA_PAGES=N

To find the correct value of
N, divide the desired address
space size (in megabytes) by four. (For example, it is
512 for 2Â GB.)