Capítulo 5. Solução de problemas

5.1. Por que o FreeBSD está encontrando a quantidade errada de memória no hardware i386™?
5.2. Por que meus programas morrem ocasionalmente com erros Signal 11 ?
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?
5.4. Qual é o significado do erro maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)?
5.5. Por que aplicativos de tela cheia em máquinas remotas se comportam de forma errática?
5.6. Por que demora tanto para conectar ao meu computador via ssh ou telnet?
5.7. Por que a mensagem file: table is full aparece repetidamente no dmesg(8)?
5.8. Por que o relógio do meu computador mantém-se com o horário incorreto?
5.9. O que significa o erro swap_pager: indefinite wait buffer:?
5.10. O que é um lock order reversal (inversão de ordem de bloqueio)?
5.11. O que significa o erro Called ... with the following non-sleepable locks held?
5.12. Por que o buildworld / installworld morre com a mensagem touch: not found?

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:

  1. Se o problema está ocorrendo apenas em um aplicativo customizado específico, é provavelmente um bug no código.

  2. Se é um problema com parte do sistema base do FreeBSD, também pode ser resultado de um código com bugs, mas na maioria das vezes esses problemas são encontrados e corrigidos muito antes que o publico em geral e que normalmente lê o FAQ usem essas partes do código (é para isso que -CURRENT existe).

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 make buildworld falhar ao tentar compilar ls.c para ls.o e, quando executado novamente, ele falhar no mesmo lugar, significa que o código está quebrado. Tente atualizar o código fonte e tente compilar novamente. Se a compilação falhar em outro lugar, é quase certo que a causa é um problema de hardware.

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:

  1. Os discos rígidos podem estar superaquecidos: Verifique se os ventiladores ainda estão funcionando, pois o disco e outros componentes de hardware podem estar superaquecendo.

  2. O processador está superaquecendo: pode ser porque o processador sofreu overclock ou o ventilador do processador pode ter parado de funcionar. Em ambos os casos, certifique-se de que o hardware esteja sendo utilizado de acordo com as condições especificadas pelo fabricante, pelo menos ao tentar resolver esse problema. Se não estiver, volte o clock para as configurações padrão.)

    Em relação ao overclocking, é muito mais barato ter um sistema lento do que um sistema frito que precisa ser substituído! Além disso, a comunidade não é simpática a problemas em sistemas com overclock.

  3. Memória Errática: se vários módulos de memórias SIMMS/DIMMS estiverem instalados, retire-os e tente executar a máquina instalando cada SIMM ou DIMM individualmente para encontrar o modulo DIMM/SIMM problemático ou até mesmo encontrar uma combinação de módulos com problema.

  4. Configurações over-otimizadas da placa-mãe: as configurações da BIOS e alguns jumpers da placa-mãe oferecem opções para definir vários intervalos de tempo. Os valores padrões geralmente são suficientes, mas, às vezes, a configuração dos estados de espera na RAM para valores muito baixos, ou a configuração da opção RAM Speed: Turbo causará um comportamento estranho. Uma ideia válida é restaurar a configuração padrão da BIOS, depois é claro de anotar as configurações atuais.

  5. Fonte com potência insuficiente para energizar a placa-mãe: Remova qualquer placa de I/O não utilizada, discos rígidos ou CD-ROMs, desconectando o cabo de alimentação deles para ver se a fonte de alimentação pode gerenciar uma carga menor. Ou utilize outra fonte de alimentação, de preferência uma com um pouco mais de potência. Por exemplo, se a fonte de alimentação atual é recomendada para uma carga de 250 Watts, tente uma que seja recomendada para uma carga de 300 Watts.

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 kern.maxusers do sysctl(8). O valor da variável kern.maxusers também afeta vários outros limites dentro do kernel, como por exemplo os buffers de rede. Se a máquina estiver muito carregada, aumente o kern.maxusers. Isso aumentará esses outros limites do sistema além do número máximo de processos.

Para ajustar o valor da variável kern.maxusers , consulte a seção Limites de Arquivos / Processos do Handbook. Apesar desta seção se referir a arquivos abertos, os mesmos limites se aplicam aos processos.

Se a máquina estiver levemente carregada, mas executando um número muito grande de processos, ajuste o valor do kern.maxproc definindo-o no arquivo /boot/loader.conf. O ajuste não terá efeito até que o sistema seja reinicializado. Para mais informações sobre o tuning de variáveis, consulte o manual do loader.conf(5). Se esses processos estiverem sendo executados por um único usuário, ajuste o kern.maxprocperuid para que fique menor em 1 unidade do novo valor do kern.maxproc. Ele deve ser pelo menos uma unidade menor porque o programa do sistema, init(8), deve estar sempre em execução.

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 xterm , que é o tipo requerido pelo console do FreeBSD. Alternativamente, o kernel pode ter valores errados para a largura e a altura do terminal.

Verifique se o valor da variável de ambiente TERM é xterm. Se a máquina remota não suportar isso, tentevt100.

Execute o stty -a para verificar o que o kernel acha que são as dimensões do terminal. Se estiverem incorretos, eles podem ser alterados executando stty rowsRRcolsCC.

Alternativamente, se a máquina do cliente tiver o x11/xterm instalado, a execução do resize consultará o terminal para as dimensões corretas e as definirá.

5.6.

Por que demora tanto para conectar ao meu computador via ssh ou telnet?

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 www.yahoo.com. Se isso não funcionar, este é o problema.

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 /etc/resolv.conf. Isso geralmente causará um atraso no SSH, já que a opção UseDNS é definida como yes por padrão no /etc/ssh/sshd_config. Se isso estiver causando o problema, preencha as informações ausentes no arquivo /etc/resolv.conf ou configure a opção UseDNS para no no arquivo sshd_config como uma solução temporária.

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 Timecounter. Aquele com o maior valor de quality é o que o FreeBSD escolheu.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Confirme isso verificando o valor da variável kern.timecounter.hardware no sysctl(3).

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Pode ser um timer ACPI quebrado. A solução mais simples é desabilitar o timer ACPI no arquivo /boot/loader.conf:

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 i8254 também está disponível e pode ser selecionado alterando-se a variável kern.timecounter.hardware do sysctl(3).

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

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 /etc/sysctl.conf:

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 /var/log/messages e na saída do comando dmesg. Caso contrário, verifique os cabos e conexões.

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 buildworld / installworld morre com a mensagem touch: not found?

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 adjkerntz -i para ajustar o relógio do kernel ao inicializar no modo de usuário único.

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>.