The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: step/screen
Context English State
There are currently 3 active/semi-active branches in the FreeBSD <link xlink:href="">Subversion Repository</link>. (Earlier branches are only changed very rarely, which is why there are only 3 active branches of development):
<symbol>stable/11/</symbol> AKA <emphasis>11-STABLE</emphasis>
<symbol>stable/12/</symbol> AKA <emphasis>12-STABLE</emphasis>
<symbol>head/</symbol> AKA <emphasis>-CURRENT</emphasis> AKA <emphasis>13-CURRENT</emphasis>
<literal>HEAD</literal> is not an actual branch tag. It is a symbolic constant for the current, non-branched development stream known as <emphasis>-CURRENT</emphasis>.
Right now, <emphasis>-CURRENT</emphasis> is the 13.<replaceable>X</replaceable> development stream; the <emphasis>12-STABLE</emphasis> branch, <symbol>stable/12/</symbol>, forked off from <emphasis>-CURRENT</emphasis> in December 2018 and the <emphasis>11-STABLE</emphasis> branch, <symbol>stable/11/</symbol>, forked off from <emphasis>-CURRENT</emphasis> in October 2016.
How can I make the most of the data I see when my kernel panics?
Here is typical kernel panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf014a7e5
stack pointer = 0x10:0xf4ed6f24
frame pointer = 0x10:0xf4ed6f28
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 80 (mount)
interrupt mask =
trap number = 12
panic: page fault
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 <filename>GENERIC</filename> 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 <literal>0x8:</literal> part at the beginning is not significant in this case: it is the <literal>0xf0xxxxxx</literal> part that we want.
When the system reboots, do the following:
<prompt>%</prompt> <userinput>nm -n kernel.that.caused.the.panic | grep f0xxxxxx</userinput>
where <literal>f0xxxxxx</literal> 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:
<prompt>%</prompt> <userinput>nm -n kernel.that.caused.the.panic | grep f0xxxxx</userinput>
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 <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> 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:
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
Change to the <filename>/usr/src</filename> directory:
<prompt>#</prompt> <userinput>cd /usr/src</userinput>
Compile the kernel:
<prompt>#</prompt> <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput>
Wait for <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> to finish compiling.
<prompt>#</prompt> <userinput>make installkernel KERNCONF=MYKERNEL</userinput>
If <varname>KERNCONF</varname> is not included, the <filename>GENERIC</filename> kernel will instead be built and installed.
The <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> process will have built two kernels. <filename>/usr/obj/usr/src/sys/MYKERNEL/kernel</filename> and <filename>/usr/obj/usr/src/sys/MYKERNEL/kernel.debug</filename>. <filename>kernel</filename> was installed as <filename>/boot/kernel/kernel</filename>, while <filename>kernel.debug</filename> can be used as the source of debugging symbols for <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
To capture a crash dump, edit <filename>/etc/rc.conf</filename> and set <literal>dumpdev</literal> to point to either the swap partition or <literal>AUTO</literal>. This will cause the <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> scripts to use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command to enable crash dumps. This command can also be run manually. After a panic, the crash dump can be recovered using <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry>; if <literal>dumpdev</literal> is set in <filename>/etc/rc.conf</filename>, the <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> scripts will run <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> automatically and put the crash dump in <filename>/var/crash</filename>.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: step/screen
no-wrap, read-only
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/faq.pot, string 990