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

Translation

(itstool) path: answer/para
English
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.
383/3790 · 379
Context English Portuguese (Brazil) State
See the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/arch-handbook">FreeBSD Architecture Handbook</link>. Veja o <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/arch-handbook"> Handbook de Arquitetura do FreeBSD </link>.
Additionally, much general <trademark class="registered">UNIX</trademark> knowledge is directly applicable to FreeBSD. Além disso, muito do conhecimento geral sobre o <trademark class="registered">UNIX</trademark> é diretamente aplicável ao FreeBSD.
How can I contribute to FreeBSD? What can I do to help? Como posso contribuir para o FreeBSD? O que posso fazer para ajudar?
We accept all types of contributions: documentation, code, and even art. See the article on <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributing/article.html">Contributing to FreeBSD</link> for specific advice on how to do this. Nós aceitamos todos os tipos de contribuições: documentação, código e até mesmo arte. Veja o artigo <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributing/article.html">Contribuindo com o FreeBSD</link> para obter maiores informações sobre como fazer isso.
And thanks for the thought! E obrigado por considerar nos ajudar!
What are snapshots and releases? O que são Snapshots e Releases?
There are currently 3 active/semi-active branches in the FreeBSD <link xlink:href="http://svnweb.FreeBSD.org/base/">Subversion Repository</link>. (Earlier branches are only changed very rarely, which is why there are only 3 active branches of development): Atualmente existem 3 branches ativas/semi-ativas no <link xlink:href="http://svnweb.FreeBSD.org/base/">Repositório Subversion</link> do FreeBSD. (Os branches anteriores são alterados muito raramente, e é por isso que existem apenas 3 branches ativas de desenvolvimento):
<symbol>stable/11/</symbol> AKA <emphasis>11-STABLE</emphasis> <symbol>stable/11/</symbol> AKA <emphasis>11-STABLE</emphasis>
<symbol>stable/12/</symbol> AKA <emphasis>12-STABLE</emphasis> <symbol>stable/12/</symbol> AKA <emphasis>12-STABLE</emphasis>
<symbol>head/</symbol> AKA <emphasis>-CURRENT</emphasis> AKA <emphasis>13-CURRENT</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>. <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>

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: answer/para
Source string location
book.translate.xml:6097
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/faq.po, string 984