Source string Read only

(itstool) path: answer/para
Context English State
<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>.
FreeBSD crash dumps are usually the same size as physical RAM. Therefore, make sure there is enough space in <filename>/var/crash</filename> to hold the dump. Alternatively, run <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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 <literal>options MAXMEM=N</literal> where <replaceable>N</replaceable> 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:
<prompt>%</prompt> <userinput>kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(kgdb)</prompt> <userinput>backtrace</userinput>


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: answer/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/faq.pot, string 993