5.1. | Por que o FreeBSD está encontrando a quantidade errada de memória no hardware i386™? |
O motivo mais provável é a diferença entre endereços de memória física e endereços virtuais. A convenção para a maioria dos hardwares de PC é usar a área de memória entre 3,5 GB e 4 GB para uma finalidade especial (geralmente para PCI). Este espaço de endereço é usado para acessar o hardware PCI. Como resultado real, a memória física não pode ser acessada por esse espaço de endereço. O que acontece com a memória que deveria aparecer nesse local depende do hardware. Infelizmente, alguns hardwares não fazem nada e a capacidade de usar estes últimos 500 MB de RAM é totalmente perdida. Felizmente, a maioria dos hardwares faz o remapeamento da memória para um local mais alto, para que ela ainda possa ser usada. No entanto, isso pode causar alguma confusão ao observar as mensagens de inicialização. Em uma versão de 32 bits do FreeBSD, a memória parece perdida, uma vez que ela será remapeada acima de 4 GB, uma área a qual um kernel de 32 bits não consegue acessar. Neste caso, a solução é construir um kernel habilitado para PAE. Veja a seção sobre os limites de memória para mais informações. Em uma versão de 64 bits do FreeBSD, ou quando o kernel estiver habilitado para PAE, o FreeBSD irá corretamente detectar e remapear a memória para que ela seja utilizável. Durante a inicialização, no entanto, pode parecer que o FreeBSD está detectando mais memória do que o sistema realmente possui, devido ao remapeamento descrito. Isso é normal e a memória disponível será corrigida conforme o processo de inicialização for concluído. | |
5.2. | Por que meus programas morrem ocasionalmente com erros Signal 11 ? |
Os erros de sinal 11 são causados quando um processo tentou acessar a memória à qual o sistema operacional não concedeu acesso. Se algo assim está acontecendo em intervalos aparentemente aleatórios, comece a investigar a causa. Esses problemas geralmente podem ser atribuídos a:
Provavelmente não é um erro do FreeBSD se o problema ocorrer na compilação de um programa, mas sim da atividade que o compilador está realizando e que muda a cada vez. Por exemplo, se No primeiro caso, use um depurador como o gdb(1) para localizar o ponto no programa que está tentando acessar um endereço falso e corrija-o. No segundo caso, verifique qual peça de hardware está com defeito. As causas comuns disso incluem:
Leia a seção sobre o Signal 11 para obter maiores explicações e a discussão sobre como um software ou hardware de teste de memória ainda pode deixar passar uma memória defeituosa. Existe uma extensa FAQ sobre o problema do SIG11 disponível neste link. Por fim, se nada disso ajudou, trata-se possivelmente de um bug no FreeBSD. Siga estas instruções para enviar um relatório de problemas. | |
5.3. | Meu sistema trava com Fatal trap 12: page fault in kernel mode ou panic:, e mostra um monte de informações. O que devo fazer? |
Os desenvolvedores do FreeBSD estão interessados nesses erros, mas precisam de mais informações do que apenas a mensagem de erro. Copie a mensagem completa da falha. Em seguida, consulte a seção FAQ em kernel panics, compile um kernel de depuração e obtenha um backtrace. Isso pode parecer difícil, mas não requer nenhuma habilidade de programação. Apenas siga as instruções. | |
5.4. | Qual é o significado do erro maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? |
O kernel do FreeBSD permitirá que apenas um certo número de processos exista ao mesmo tempo. O número é baseado na variável Para ajustar o valor da variável Se a máquina estiver levemente carregada, mas executando um número muito grande de processos, ajuste o valor do | |
5.5. | Por que aplicativos de tela cheia em máquinas remotas se comportam de forma errática? |
A máquina remota pode estar configurando o tipo de terminal para algo diferente de Verifique se o valor da variável de ambiente Execute o Alternativamente, se a máquina do cliente tiver o x11/xterm instalado, a execução do | |
5.6. | Por que demora tanto para conectar ao meu computador via |
O sintoma: há um longo atraso entre o momento em que a conexão TCP é estabelecida e a hora em que o software cliente solicita uma senha (ou, no caso do telnet(1), quando um prompt de login aparece). O problema: mais provável do que não, o atraso é causado pelo software do servidor tentando resolver o endereço IP do cliente em um nome de host. Muitos servidores, incluindo os servidores Telnet e SSH que vêm com o FreeBSD, fazem isso para armazenar o nome do host em um arquivo de log para referência futura pelo administrador. A solução: se o problema ocorrer sempre, independente do servidor ao que o computador cliente se conecta, o problema está no cliente. Se o problema ocorrer apenas quando o computador cliente se conecta a um determinado servidor, o problema está no servidor. Se o problema for com o cliente, a única solução é corrigir o DNS para que o servidor possa resolvê-lo. Se isso estiver ocorrendo em uma rede local, considere um problema no servidor e continue lendo. Se isso estiver ocorrendo na Internet, entre em contato com seu ISP. Se o problema for com um servidor em uma rede local, configure o servidor para resolver as consultas de endereço para nome de host para o intervalo de endereços da rede local. Veja as páginas de manual para o hosts(5) e o named(8) para maiores informações. Se o problema for com um servidor na Internet, o problema pode ser que o resolver local do servidor não está funcionando corretamente. Para verificar se é isto, tente procurar outro host, como Após uma nova instalação do FreeBSD, também é possível que as informações do domínio e do servidor de nomes estejam faltando no | |
5.7. | Por que a mensagem file: table is full aparece repetidamente no dmesg(8)? |
Essa mensagem de erro indica que o número de file descriptors disponíveis no sistema esgotaram. Consulte a informação sobre a variável kern.maxfiles na seção Ajustando os Limites do Kernel do Handbook para uma discussão e solução. | |
5.8. | Por que o relógio do meu computador mantém-se com o horário incorreto? |
O computador tem dois ou mais relógios e o FreeBSD escolheu usar o errado. Execute o comando dmesg(8) e verifique as linhas que contêm a palavra
Confirme isso verificando o valor da variável
Pode ser um timer ACPI quebrado. A solução mais simples é desabilitar o timer ACPI no arquivo debug.acpi.disabled="timer" Ou a BIOS poderá modificar o relógio TSC - talvez para mudar a velocidade do processador quando estiver funcionando a partir de baterias, ou quando estiver entrando em modo de economia de energia, mas o FreeBSD não tem conhecimento desses ajustes e parece ganhar ou perder tempo. Neste exemplo, o relógio
O computador agora deve começar a manter seu relógio mais preciso. Para que essa mudança seja executada automaticamente no momento da inicialização, adicione a seguinte linha ao arquivo kern.timecounter.hardware=i8254 | |
5.9. | O que significa o erro swap_pager: indefinite wait buffer:? |
Isso significa que um processo está tentando armazenar em memória RAM a memória do disco (swap), e que o processo foi interrompido depois de tentar sem sucesso acessar o disco por mais de 20 segundos. Isso pode ser causado por blocos defeituosos na unidade de disco, fiação de disco defeituosa, cabos ou qualquer outro hardware relacionado a I/O de disco. Se a própria unidade estiver com problemas, erros de disco aparecerão em | |
5.10. | O que é um lock order reversal (inversão de ordem de bloqueio)? |
O kernel do FreeBSD usa vários locks de recursos para arbitrar a contenção de certos recursos. Quando várias threads do kernel tentam obter vários locks de recursos, há sempre o potencial para um impasse (deadlock), em que duas threads obtiveram cada uma um dos locks e trava para sempre esperando que a outra thread libere um dos outros locks. Esse tipo de problema de locking pode ser evitado se todas as threads obtiverem os locks na mesma ordem. Um sistema de diagnóstico lock em tempo de execução chamado witness(4), ativado no FreeBSD-CURRENT e desabilitado por padrão para a branch stable e releases, detecta o potencial para deadlocks devido a erros de locking, incluindo erros causados pela obtenção de vários locks de recursos com uma ordem diferente de partes diferentes do kernel. O framework witness(4) tenta detectar esse problema quando ele ocorre e relata isso imprimindo uma mensagem no console do sistema sobre um lock order reversal (geralmente também chamado de LOR). É possível obter falsos positivos, uma vez que o witness(4) é conservador. Um relatório positivo verdadeiro não significa que um sistema está travado; em vez disso, deve ser entendido como um aviso de que um deadlock poderia ter acontecido. Nota:Os problemas de LOR tendem a ser consertados rapidamente, então verifique a lista de discussão do FreeBSD-CURRENT antes de postar sobre um. | |
5.11. | O que significa o erro Called ... with the following non-sleepable locks held? |
Isso significa que uma função que pode dormir foi chamada enquanto um lock mutex (ou outro unsleepable) era mantido. A razão pela qual isso é um erro é porque os mutexes não devem ser mantidos por longos períodos de tempo; eles deveriam existir apenas para manter curtos períodos de sincronização. Este contrato de programação permite que os drivers de dispositivos usem mutexes para sincronizar com o resto do kernel durante as interrupções. As interrupções (no FreeBSD) podem não dormir. Por isso, é imperativo que nenhum subsistema bloqueie o kernel por um longo período mantendo um mutex ativo. Para capturar tais erros, asserções podem ser adicionadas ao kernel que interage com o subsistema witness(4) para emitir um aviso ou erro fatal (dependendo a configuração do sistema) quando uma chamada potencialmente de bloqueio é feita enquanto um mutex estiver sendo mantido. Em resumo, tais avisos não são fatais, no entanto, com um timing infeliz, podem causar efeitos indesejáveis, desde um pequeno erro na capacidade de resposta do sistema até o seu travamento completo. Para obter informações adicionais sobre locking no FreeBSD, consulte locking(9). | |
5.12. | Por que o |
Este erro não significa que o utilitário touch(1) esteja ausente. O erro é provavelmente devido às datas dos arquivos que estão sendo definidos em algum momento no futuro. Se o relógio do CMOS estiver configurado para a hora local, execute |
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>.