17.1. | Como posso aprender mais sobre os componentes internos do FreeBSD? |
Veja o Handbook de Arquitetura do FreeBSD . Além disso, muito do conhecimento geral sobre o UNIX® é diretamente aplicável ao FreeBSD. | |
17.2. | Como posso contribuir para o FreeBSD? O que posso fazer para ajudar? |
Nós aceitamos todos os tipos de contribuições: documentação, código e até mesmo arte. Veja o artigo Contribuindo com o FreeBSD para obter maiores informações sobre como fazer isso. E obrigado por considerar nos ajudar! | |
17.3. | O que são Snapshots e Releases? |
Atualmente existem 3 branches ativas/semi-ativas no Repositório Subversion do FreeBSD. (Os branches anteriores são alterados muito raramente, e é por isso que existem apenas 3 branches ativas de desenvolvimento):
No momento, o -CURRENT é o fluxo de desenvolvimento 13. | |
17.4. | Como posso aproveitar ao máximo os dados que vejo quando meu kernel entra em 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 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 Para prosseguir:
No entanto, a melhor maneira de rastrear a causa de um panic é capturar um despejo de memória e usar o kgdb(1) para gerar um rastreamento de pilha no despejo de memória. Em qualquer caso, o método é este:
Nota:Se a variável O processo make(1) terá compilado dois kernels. O Para capturar um despejo de memória, edite o Nota: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 Depois que o despejo de memória for recuperado, obtenha um rastreamento de pilha da seguinte maneira:
Note que pode haver várias telas de informação valiosa. Idealmente, use script(1) 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 kgdb(1) 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. Dica:Se um segundo computador estiver disponível, o kgdb(1) pode ser configurado para fazer uma depuração remota, incluindo pontos de interrupção de configuração e passos únicos através do código do kernel. Nota:Se o | |
17.5. | Por que |
A toolchain ELF não faz, por padrão, os símbolos definidos em um executável visíveis para o vinculador dinâmico. Consequentemente, a busca da função Para pesquisar, usando a função | |
17.6. | Como posso aumentar ou reduzir o espaço de endereçamento do kernel em uma máquina i386? |
Por padrão, o espaço de endereço do kernel é de 1 GB (2 GB para PAE) para a arquitetura i386. Se você estiver executando um servidor com uso intensivo de rede ou utilizando o ZFS, isso provavelmente não será suficiente. Adicione a seguinte linha ao arquivo de configuração do kernel para aumentar o espaço disponível e recompile o kernel: options KVA_PAGES= Para encontrar o valor correto de |
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.