Translation

(itstool) path: step/para
Make sure that the following line is included in the kernel configuration file:
91/790
Context English Portuguese (Brazil) State
<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>. <literal>HEAD</literal> não é uma tag de branch real. É uma constante simbólica para o fluxo de desenvolvimento atual, não ramificado, conhecido como <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. No momento, o <emphasis>-CURRENT</emphasis> é o fluxo de desenvolvimento 13.<replaceable>X</replaceable>; o branch <emphasis>12-STABLE</emphasis>, <symbol>stable/12/</symbol>, derivou do <emphasis>-CURRENT</emphasis> em Dezembro de 2018 e o branch ​​<emphasis>11-STABLE</emphasis>,<symbol>stable/11/</symbol>, derivou do <emphasis>-CURRENT</emphasis> em Outubro de 2016.
How can I make the most of the data I see when my kernel panics? Como posso aproveitar ao máximo os dados que vejo quando meu kernel entra em panic?
Here is typical kernel panic: Aqui está um panic típico do kernel:
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
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. Esta mensagem não é suficiente. Embora o valor do ponteiro de instrução seja importante, ele também depende da configuração, pois varia dependendo da imagem do kernel. Se for uma imagem de kernel <filename>GENERIC</filename> de um dos snapshots, é possível que alguém rastreie a função problemática, mas para um kernel personalizado, somente você pode nos dizer onde a falha ocorreu.
To proceed: Para prosseguir:
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. Anote o valor do ponteiro de instrução. Note que a parte <literal>0x8:</literal> no começo não é relevante neste caso: é a parte <literal>0xf0xxxxxx</literal> que nós queremos.
When the system reboots, do the following: Quando o sistema for reinicializado, faça o seguinte:
<prompt>%</prompt> <userinput>nm -n kernel.that.caused.the.panic | grep f0xxxxxx</userinput> <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: no qual <literal>f0xxxxxx</literal> é o valor do ponteiro de instrução. As probabilidades são de que você não obterá uma correspondência exata, pois os símbolos na tabela de símbolos do kernel são para os pontos de entrada das funções e o endereço do ponteiro de instrução estará em algum lugar dentro de uma função, não no início. Se você não obtiver uma correspondência exata, omita o último dígito do valor do ponteiro de instrução e tente novamente:
<prompt>%</prompt> <userinput>nm -n kernel.that.caused.the.panic | grep f0xxxxx</userinput> <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. Se isso não produzir nenhum resultado, corte outro dígito. Repita até que haja algum tipo de saída. O resultado será uma possível lista das funções que causaram o panic. Este é um mecanismo menos do que exato para rastrear o ponto de falha, mas é melhor do que nada.
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. No entanto, a melhor maneira de rastrear a causa de um panic é capturar um despejo de memória e usar o <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> para gerar um rastreamento de pilha no despejo de memória.
In any case, the method is this: Em qualquer caso, o método é este:
Make sure that the following line is included in the kernel configuration file: Certifique-se de que a seguinte linha esteja incluída no arquivo de configuração do kernel:
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
Change to the <filename>/usr/src</filename> directory: Mude para o diretório <filename>/usr/src</filename>:
<prompt>#</prompt> <userinput>cd /usr/src</userinput> <prompt>#</prompt> <userinput>cd /usr/src</userinput>
Compile the kernel: Compile o kernel:
<prompt>#</prompt> <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput> <prompt>#</prompt> <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput>
Wait for <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> to finish compiling. Aguarde até o <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> terminar a compilação.
<prompt>#</prompt> <userinput>make installkernel KERNCONF=MYKERNEL</userinput> <prompt>#</prompt> <userinput>make installkernel KERNCONF=MYKERNEL</userinput>
Reboot. Reinicie.
If <varname>KERNCONF</varname> is not included, the <filename>GENERIC</filename> kernel will instead be built and installed. Se a variável <varname>KERNCONF</varname> não for informada na linha de comando, o kernel <filename>GENERIC</filename> será compilado e instalado.
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>. O processo <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> terá compilado dois kernels. O <filename>/usr/obj/usr/src/sys/MYKERNEL/kernel</filename> e o <filename> /usr/obj/usr/src/sys/MYKERNEL/kernel.debug </filename>. O <filename>kernel</filename> foi instalado como <filename>/boot/kernel/kernel</filename>, enquanto o <filename>kernel.debug</filename> pode ser usado como fonte de símbolos de depuração para o <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>. Para capturar um despejo de memória, edite o <filename>/etc/rc.conf</filename> e defina o <literal>dumpdev</literal> para apontar para a partição de swap ou para <literal>AUTO</literal>. Isso fará com que os scripts <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> usem o comando <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> para ativar os despejos de memória. Este comando também pode ser executado manualmente. Após um panic, o despejo de memória pode ser recuperado usando o <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry>; se o <literal>dumpdev</literal> estiver configurado em <filename>/etc/rc.conf</filename>, os scripts <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> executarão o <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> automaticamente e colocarão o despejo de memória em <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. Os despejos de memória do FreeBSD são geralmente do mesmo tamanho que a RAM física. Portanto, verifique se há espaço suficiente em <filename>/var/crash</filename> para manter o despejo. Como alternativa, execute <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> manualmente e faça com que recupere o despejo de memória para outro diretório com mais espaço. É possível limitar o tamanho do despejo de memória usando <literal>options MAXMEM=N</literal> onde <replaceable>N</replaceable> é o tamanho da memória utilizada do kernel em KBs. Por exemplo, para 1 GB de RAM, limite o uso de memória pelo kernel a 128 MB, para que o tamanho do despejo de memória seja de 128 MB em vez de 1 GB.
Once the crash dump has been recovered , get a stack trace as follows: Depois que o despejo de memória for recuperado, obtenha um rastreamento de pilha da seguinte maneira:
<prompt>%</prompt> <userinput>kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(kgdb)</prompt> <userinput>backtrace</userinput>
<prompt>%</prompt> <userinput>kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(kgdb)</prompt> <userinput>backtrace</userinput>
Note that there may be several screens worth of information. Ideally, use <citerefentry><refentrytitle>script</refentrytitle><manvolnum>1</manvolnum></citerefentry> 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. <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> 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. Note que pode haver várias telas de informação valiosa. Idealmente, use <citerefentry><refentrytitle>script</refentrytitle><manvolnum>1</manvolnum></citerefentry> para capturar todas elas. Usar a imagem do kernel unstripped com todos os símbolos de depuração deve mostrar a linha exata do código fonte do kernel onde o panic ocorreu. O rastreamento de pilha geralmente é lido de baixo para cima para rastrear a sequência exata de eventos que levam à falha. O <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> também pode ser usado para imprimir o conteúdo de várias variáveis ​​ou estruturas para examinar o estado do sistema no momento da falha.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: step/para
Source string location
book.translate.xml:6151
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/faq.po, string 994