Capítulo 5. Resolução de Problemas

Com controladoras SCSI, o drive (HD) deveria ser capaz de remapear blocos ruins e corrigí-los automaticamente. Porém, muitos desses discos mantém essa função desabilitada por alguma razão misteriosa...

Para habilitar essa função é necessário editar o primeiro modo de página do dispositivo, o qual pode ser feito com o comando abaixo (como root)

# scsi -f /dev/rsd0c -m 1 -e -P 3

E mudando os valores de AWRE e ARRE de 0 para 1:-

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

Os parágrafos seguintes foram enviados por Ted Mittelstaedt <tedm@toybox.placo.com>:

Para os discos IDE, qualquer bad block é considerado um sinal de dificuldade em potencial. Todos os discos IDE modernos já vêm com um remapeador interno que realoca bad blocks por outros blocos em bom estado, automaticamente. Todos os disco rígido IDE fabricados hoje em dia oferecem garantias extensas.

Se ainda quiser tentar salvar um drive IDE com bad blocks, pode fazer um download do programa de diagnóstico e correção do próprio fabricante do disco rígido. Às vezes estes programas podem fixar e forçar eletronicamente o disco a marcar estes blocos ruins e desativá-los.

Em discos ESDI, RLL e MFM, a existência de bad blocks é normal e não representa nenhum sinal de dificuldade,geralmente. Em um PC, a placa controladora das unidades de disco e, a BIOS se encarregam da tarefa de re-mapear os bad blocks. Isso funciona em sistemas operacionais como DOS que usa código da BIOS para acessar o disco. Porém, o driver (software controlador) do FreeBSD não trabalha ou acessa comandos da BIOS para para interagir com o drive (HD), então um mecanismo chamado bad144, existente no FreeBSD, acaba substituindo esta funcionalidade. O bad144 só trabalha com o drive wd (portanto, não é suportado no FreeBSD 4.0), e não pode ser usado com drive SCSI. O bad144 trabalha marcando e organizando setores ruins encontrados no HD, em um arquivo especial no disco.

Uma característica do bad144 - o bloco danificado é colocado em um arquivo especial situado na última trilha do disco. Como este arquivo contém uma lista de setores defeituosos que pode incluir valores perto do início do disco, onde o /kernel pode estar alocado, esse arquivo deverá ser acessível ao bootstrap para que o programa - por meio da BIOS - leia o kernel; isso significa que o disco usado com bad144 não deve exceder 1024 cilindros, 16 cabeças, e 63 setores, logo, temos um limite efetivo de 500MB para discos mapeados com o bad144..

Para ativar o uso do bad144, simplesmente defina a opção de procurar por “Bad Block” como ON na tela do fdisk do FreeBSD, durante a instalação. Essas instruções funcionam a partir do FreeBSD 2.2.7, e o disco deve ter menos que 1024 cilindros. Geralmente recomenda-se que a unidade de disco esteja em operação durante pelo menos 4 horas antes de executar o bad144, permitindo assim a expansão térmica do HD.

Se o disco tem mais de 1024 cilindros (como um disco ESDI grande) a controladora ESDI usa um tipo de tradução especial em modo DOS. A device wd também entende esses mesmos modos de tradução e conversão, isso se o “tradutor” de geometria for ativado como “geometria fixa”, quando particionado pelo fdisk. Você também não deve usar o modo “dangerously dedicated” para criar partições do FreeBSD, pois isso ignora o tipo de geometria. Embora o fdisk use a geometria definida pelo usuário, ele continua reconhecendo o tamanho verdadeiro do disco, e tentará criar uma partição maior para o FreeBSD. Se a geometria de disco for alterada para geometria traduzida(translated geometry), a partição DEVE ser criada manualmente, informando os números de blocos do HD.

Um truque rápido é usar um disco grande ESDI com uma controladora ESDI, iniciar(booting) o sistema com um disco DOS e formatar uma partição DOS. Depois reiniciar o sistema com um disco de instalação do FreeBSD, e anotar o número e tamanho dos blocos que serão apresentados na tela do fdisk para a partição DOS. Redefina a geometria do disco com os valores anotados, apague a partição DOS e crie uma partição FreeBSD “cooperativa”. Defina essa partição como bootável e habilite o reconhecimento de bad blocks. Na instalação, o bad144 é carregado antes que qualquer outro sistema de arquivos seja criado (você pode ver isso com um Alt+F2). Se houver problemas na criação do arquivo de definições de setor danificado (o arquivo de badsector) é porque a geometria definida é maior do que o seu valor real - reinicie o sistema e comece todos os procedimentos novamente, inclusive o particionamento e formatação da partição DOS.

Se o remapeamento já estiver habilitado e os problemas com bad block continuarem, considere a substituição imediata do disco, pois os danos e os bad blocks aumentarão consideravelmente com o passar do tempo.

As informações a seguir são para o modelo 742a, mas provavelmente também servem para as placas Buslogic. (Bustek = Buslogic).

Existem duas “versões” tradicionais da placa 742a. São os equipamentos de revisão A-G e de revisão H; as letras de cada revisão são colocadas depois do número de fabricação, ao lado das placas. A placa 742a possui 2 chips ROM acoplados, o primeiro é o chip da BIOS e o segundo é o do Firmware. Para o FreeBSD a versão da BIOS é irrelevante, mas a versão do Firmware é uma informação fundamental. É interessante dizer que, se você fizer uma chamada ao departamento de suporte da Buslogic, eles irão te enviar um upgrade desses ROMs, e é muito bom sempre manter a versão mais recente do ROM do seu Firmware para a versão de revisão do seu equipamento.

As placas cuja letra de revisão é A-G aceitam apenas atualizações da BIOS/Firmware de versão 2.41/2.21 respectivamente. A revisão H (REV H) aceita as versões mais recentes da BIOS/Firmware até a versão 4.70/3.37. A principal diferença entre as versões do Firmware é que a versão 3.37 tem suporte a“round robin”.

As placas Buslogic também tem um número serial. Caso seu equipamento seja antigo, tente abrir uma chamada no departamento de RMA da Buslogic e informe-os o número de série da sua placa. Se ela estiver entre os seriais de abrangência, a Buslogic vai aceitar seu equipamento para revisão.

O FreeBSD 2.1 aceita apenas as revisões de Firmware até o 2.21. Caso o seu Firmware seja mais antigo do que o 2.21 sua placa não será reconhecida como Buslogic. Contudo, é possível que o equipamento seja reconhecido como Adaptec 1540, já que os Firmware mais antigos da Buslogic possuem um modo de “emulação” da AHA1540, o que não é uma boa coisa, para uma placa EISA.

Caso seu Firmware seja antigo e você conseguiu obter uma revisão para a versão 2.21, não se esqueça que é necessário alterar o jumper W1 da posição A-B (padrão) para posição B-C ao atualizar a placa.

Isso já é um problema conhecido. A controladora SCSI on-board EISA dos servidores HP Netserver estão no slot EISA número 11, portanto todos os “verdadeiros” slots EISA estão na sua frente. O endereço definido para os slots EISA >= 10 ocupa um endereço compartilhado com o barramento PCI, e portanto entra em conflito com seus recursos. Essa é uma situação onde a configuração automática do FreeBSD não se comporta muito bem.

Portanto o que você deve fazer, é fingir que não existe limitação quanto ao intervalo de endereços, definindo a opção option EISA_SLOTS do kernel para o valor 12. Configure e compile um novo kernel, conforme descrito no capítulo de configuração do kernel no Manual do FreeBSD.

Obviamente esse problema é ainda maior quando se trata de uma nova instalação. Para corrigir esse problema é necessário uma pequena alteração no modo UserConfig. Não use a interface de configuração “visual” do kernel, use a Interface de Linha de Comando (CLI), simplesmente digitando:

eisa 12
quit

na tela do modo CLI, e continue a instalação do FreeBSD como de costume. De qualquer forma, é recomendável recompilar e instalar um novo kernel depois da instalação do sistema..

Futuras versões do FreeBSD terão esse problema corrigido automaticamente.

Está com defeito! Não suporta mais comandos nos dois canais de forma simultânea.

Existe uma correção disponível e automaticamente habilitada, se você usa uma controladora com esse chip. Para maiores detalhes, refira-se a página de manual da controladora de disco (wd(4)).

Se o FreeBSD em questão é o FreeBSD 2.2.1 ou 2.2.2 com essa controladora em questão, e você quer usar o segundo canal, compile um novo kernel com a opção options "CMD640" habilitada. Essa configuração é padrão para o FreeBSD 2.2.5 e posteriores.

Normalmente esse problema é causado por um conflito de interrupções (por exemplo, duas placas usando a mesma IRQ). O FreeBSD até a versão 2.0.5R costumava ser tolerante quanto a esse problema e a placa de rede continuava funcionando mesmo com IRQ conflitantes. Contudo desde a versão 2.0.5R os conflitos de interrupções não são mais tolerados. Inicie o sistema com a opção de boot -c e mude as device ed0/de0/... para o valor correspondente ao da placa.

Caso esteja usando um conector BNC na sua placa de rede, é provável que existam device timeout por causa de má terminação do barramento. Pra tirar isso a limpo coloque um terminador direto na placa (sem cabos) e veja se as mensagens de erro param.

Algumas placas compatíveis NE2000 apresentarão esse problema caso a porta UTP não receba sinal de link, ou se o cabo estiver desconectado.

Esse cartão tem um hábito horrível de perder suas informações de configuração. Redefina as informações da placa usando o programa de DOS chamado 3c5x9.exe.

Se o único problema é a lerdeza terrível da sua impressora, tente mudar seu modo da porta de impressão conforme discutido na seção de Configuração de Impressoras no Manual do FreeBSD.

Erros de sinal 11 são fruto de tentativas de acesso indevido a memória. Esse acesso normalmente é controlado pelo sistema operacional, e quando o sistema não permite acessar determinados endereços, o processo é morto com signal 11. Se isso estiver acontecendo em intervalos aleatórios de tempo, é preciso investigar as causas com cuidado.

Esse problema normalmente é atribuído a:

1. Se o problema ocorre apenas em um programa específico que você mesmo esta desenvolvendo, se trata de um bug no código do seu programa.

2. Se o problema é com algum programa que faz parte da base do FreeBSD, é possível que também seja um problema de bug no código em questão. Contudo, esses problemas costumam ser corrigidos antes que os usuários tradicionais percebam sua existência - e necessitem ler este FAQ - afinal, é para isso que o -CURRENT existe.

Em especial, uma indicação que esse problema não é um bug do FreeBSD, é um erro repetitivo no mesmo instante da compilação, mas o problema que o compilador apresenta muda de linha a cada nova compilação.

Por exemplo, suponha que você esteja executando um “make buildworld”, e a compilação falha na hora de compilar o ls.c em ls.o. Se você rodar o “make buildworld” de novo e a compilação falha exatamente no mesmo trecho do código, então o problema realmente é com o fonte da aplicação, nesse caso atualize os fontes do FreeBSD e tente novamente. Agora se a compilação falhar em um trecho diferente do código, é quase certo que o problema seja físico, ou seja, com o seu equipamento.

O que deve ser feito:

Em primeiro lugar, deve-se usar um debugador, como o gdb, por exemplo, para encontrar o ponto exato do código que está tentando acessar um endereço problemático de memória, e corrigi-lo.

Em segundo lugar, verifique se a culpa não é do seu equipamento.

As causas mais comuns para o problema incluem::

1. Os seus discos rígidos podem estar superaquecidos: Verifique se o sistema de ventilação do seu PC está funcionando. Verifique coolers internos (da fonte) e externos, e verifique se não existe superaquecimento de outros componentes do computador.

2. O processador está superaquecido: Pode ser porque foi feito um overclock no processador em questão, ou no caso mais tradicional, pode ser que o cooler tenha parado de funcionar ou que esteja sujo e portanto funcionando em rotação baixa. Em ambos os casos, o primeiro passo é garantir que o processador esteja rodando sob as mesmas condições que ele foi construído para funcionar - por exemplo, com a velocidade do clock original e com a ventilação adequada.

   Caso tenha sido feito overclock no processador, lembre-se que é mais barato usar um computador um pouco mais lento, do que trocar o processador da máquina por causa de um chip fritado ;-) Além do que a maioria das pessoas não são simpatizantes de overclock, mesmo que você considere a ação segura ou não.

3. Caso tenha múltiplos pentes de memória SIMM/DIMM, tente desligá-los e experimente usar cada pente de uma vez, indiviualmente. Com isso é possível descobrir se o problema é com algum chip DIMM/SIMM ou se o problema é a combinação entre os pentes.

4. Configurações super otimistas na BIOS da sua placa mãe são outra causa provável. Algumas BIOS tem opções que permitem alterar a velocidade e frequência de vários recursos. Normalmente os valores padrão na BIOS são os mais conservadores, e portanto devem ser o bastante para controlar corretamente o equipamento; contudo algumas opções como por exemplo “RAM Speed: Turbo” ou alguma opção parecida coloca o estado de espera para o acesso a memória em um valor muito baixo, e as vezes, por mais otimista que você seja, sua memória pode não ser rápida o bastante. O ideal é definir os valores padrão da sua BIOS, mas é interessante anotar os valores atuais primeiro!

5. Alimentação insuficiente de energia na placa-mãe. Caso exista alguma placa que não esteja sendo utilizada, algum disco rígido ou CDROM, é interessante desliga-los temporariamente do computador, ou simplesmente remover o cabo de energia desses equipamentos. Mesmo em sub utilização, essas placas e discos estão sob constante alimentação e talvez sua fonte consiga suprir uma carga menor. Ou tente trocar a fonte do seu PC, de preferência por uma com maior poder de alimentação (por exemplo, se a sua fonte é de 250 Watts troque por uma de 300 Watts).

Leia ainda o FAQ SIG11 (disponível a seguir) que tem outras boas explicações sobre esses problemas. O FAQ também discute como alguns programas de teste de memória podem pensar que um pente problemático está funcionando corretamente.

Finalmente, se nenhum dos casos acima ajudou a solucionar seu problema, pode ser que exista um bug no FreeBSD. Você deve seguir as intruçõoes para enviar um relatório de problemas para o Projeto FreeBSD.

Existe um FAQ extenso que cobre esse assunto, disponível no FAQ dos problemas com SIG11.

A equipe de desenvolvimento do FreeBSD tem muito interesse nesse tipo de erro, mas é necessário obter algumas informações suplementares, do que apenas o erro que você está tendo. Copie sua mensagem de erro inteira, consulte o FAQ sobre kernel panics, compile um kernel em modo de debugação e tente analisar o problema. Parece uma tarefa difícil, mas não é necessário conhecimento de programação; basta seguir as instruções.

Esse é um problema conhecido da placa de vídeo ATI Mach 64. O problema é que essa placa usa o endereço 2e8, o mesmo utilizado pela quarta porta serial dos computadores pessoais. Devido a um bug (ou uma vantagem?) da sio(4) ,essa porta será sempre reconhecida, ainda que não exista a quarta porta serial no seu computador, ou mesmo se o sio3 (a quarta porta) estiver desabilitado.

Até que o bug seja corrigido, você pode usar essa solução:

1. Entre no modo de configuração do kernel com opção -c na tela de inicialização(boot). (Isto colocara o kernel no modo de configuração).

2. Desabilite a sio0, sio1, sio2 e sio3 (todas elas). Dessa forma será ativada, logo, você não terá -> problemas.

3. Digite exit para continuar o boot.

Caso queira usar as portas seriais, será necessário construir um kernel customizado, com as seguintes alterações: no fonte /usr/src/sys/i386/isa/sio.c encontre a ocorrência da expressão 0x2e8 e apague essa expressão e a vírgula que a antecede (mantenha a outra). Depois compile o novo kernel normalmente.

Mesmo depois dessa correção, é provável que o X Windows ainda não funcione como esperado. Se for o caso, garanta que a versão do Xfree86 em questão seja ao menos o XFree86 3.3.3 ou uma versão superior. Esse XFree86 e os posteriores tem suporte nativo às placas de vídeo Mach64, e tem inclusive um X Server dedicado para tal equipamento.

Devido à maneira que o FreeBSD obtém as informações quanto ao tamanho da memória disponível por intermédio da BIOS, pode acontecer de apenas 16 bits válidos serem detectados (65535 Kbytes = 64MB) ou até menos, dependendo da BIOS (em alguns casos, apenas 16MB). Mesmo nessa situação o FreeBSD tenta detectar mais que 64MB de memória, mas esse reconhecimento pode falhar.

Pra corrigir esse problema pode ser usada a opção do kernel descrita a seguir. Existe uma forma de obter informações completas quanto ao tamanho da memória, a partir da BIOS, mas devido a algumas limitações isso nem sempre é possível hoje em dia. Futuramente será. De qualquer forma, temos ainda a opção do kernel para situações onde toda a memória não puder ser reconhecida.

options "MAXMEM=n"

Onde n equivale à memória (em Kilobytes) disponível no sistema. Para 128 MB de memória, use o valor 131072.

Nota: A mensagem em questão também pode ser mb_map too small!

Essa mensagem de pânico indica que o sistema ficou sem memória suficiente pros buffers de rede (especificamente, os mbuf clusters). A quantidade de memória virtual disponível para os clusters mbuf pode ser elevada com a opção::

options "NMBCLUSTERS=n"

no arquivo de configuração do seu kernel, onde n equivale ao valor entre 512-4096, dependendo do número de conexões TCP simultâneas que você espera poder suportar. O valor 2048 é recomendável, e provavelmente será o bastante para sanar o problema que causa o pânico em questão O número de clusters mbuf em uso pode ser monitorado com o comando netstat -m (veja netstat(1)). O valor padrão para a variável NMBCLUSTERS no kernel do FreeBSD é 512 + MAXUSERS * 16.

O kernel do FreeBSD limita o número máximo de processos simultâneos existentes no sistema. O número em questão é baseado na opção MAXUSERS. do sistema. A opção MAXUSERS afeta ainda inúmeros outros limites do kernel do FreeBSD, como por exemplo os buffers disponíveis para o stack de rede do sistema (veja esta resposta anterior). Se o computador estiver sob grande carga, provavelmente será necessário aumentar o MAXUSERS. Essa alteração aumentará os limites do sistema em adição ao número de processos permitido.

Desde a versão 4.4 do FreeBSD, o valor para MAXUSERS se tornou configurável, não sendo mais necessário recompilar o kernel para alterá-lo, bastando definir a variável kern.maxusers no arquivo /boot/loader.conf. Em versõoes mais recentes do FreeBSD, deve-se ajustar o MAXUSERS em sua configuração do kernel.

Caso seu sistema não esteja muito carregado, mas o número de processos simultâneos ainda assim é alto basta definir a variável kern.maxproc com o sysctl. Em casos especiais, onde esses inúmeros processos estão sendo executados por um único usuário, será preciso alterar ainda alterar o valor da variável kern.maxprocperuid para um a menos do que o valor de kern.maxproc. (deve ser ao menos 1 processo a menos, visto que ao menos o init(8) do sistema vai estar sempre em execução.)

Para tornar uma alteração de variável do sysctl permanente, defina-a no arquivo /etc/sysctl.conf nas versões mais recentes do FreeBSD, ou então no arquivo /etc/rc.local em versões mais antigas do sistema.

A lógica que tenta detectar uma data errada nos arquivos /var/db/kvm_*.db as vezes é falha, o que leva o sistema a entrar em pânico.

Se for o caso, reinicie seu sistema em modo monousuário e faça:

# rm /var/db/kvm_*.db

Trata-se de um conflito com o Ultrastor SCSI Host Adapter.

Durante o processo de inicialização(boot), entre no menu de configuração do kernel e desabilite a uha0, que esta causando o problema.

A placa-mãe em questão não consegue se dar bem com o suporte a terminação automática do barramento. Altere sua BIOS SCSI para a terminação correta, de acordo com a configuração do equipamento, ao invés de usar terminação automática. O driver AIC7XXX não consegue descobrir se o reconhecimento externo dos cabos (e conseqüente auto-terminação) está disponível, e portanto ele simplesmente assume que o suporte existe, caso a configuração da EEPROM serial esteja definida como automatic termination. Sem o reconhecimento de cabo externo o driver irá sempre configurar a terminação de forma incorreta, o que compromete a confiabilidade do barramento SCSI.

Essa pergunta é respondida no FAQ do próprio Sendmail, e diz:-

        * Eu estou tendo problemas de configurações local "Local configuration error" como essas:

        553 relay.domain.net config error: mail loops back to myself
        554 <user@domain.net>...  Local configuration error

Como posso resolver esse problema?

Você definiu que as mensagens enviadas para o domínio
em questão (domain.net) devem ser repassadas para uma outra
estação específica (nesse caso para
relay.domain.net) usando um registro MX, mas essa máquina de
relay não se reconhece como a estação
responsável pelas mensagens do domínio domain.net.  
Adicione domain.net no arquivo /etc/mail/local-host-names
(caso você esteja usando FEATURE(use_cw_file)) ou então
adicione a linha "Cw domain.net" em /etc/mail/sendmail.cf.
            

Atualmente a versão mais recente do FAQ do sendmail é mantida em sincronia com as versões mais atuais do MTA, mas ela ainda é enviada regularmente para os grupos de notícias comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, e news.answers. Ainda é possível receber um cópia por e-mail do FAQ, enviando uma mensagem para <mail-server@rtfm.mit.edu> com o comando send usenet/news.answers/mail/sendmail-faq no corpo da mensagem.

A estação remota deve estar definindo o terminal como algum tipo diferente do cons25 que é o tipo de terminal usado pelo console do FreeBSD.

Existem inúmeras correções para esse problema:

• Depois de logar-se na estação remota, defina a variável de ambiente TERM como ansi ou sco caso a máquina em questão tenha informações quanto a esse tipo de terminal.

• Use um emulador VT100 como o screen no console do FreeBSD. O screen oferece a possibilidade de usar múltiplas sessões concorrentes em um mesmo terminal, e é um grande programa. Cada janela do screen se comporta como um terminal VT100, portanto a variável TERM deve ser definida como vt100.

• Instale a base do cons25 na estação remota. A maneira correta de faze-lo depende do sistema operacional em questão na estação remota. Consulte os manuais de administração do sistema remoto em questão para descobrir como faze-lo.

• Levante um X server do lado FreeBSD da coisa e acesse a estação remota usando um terminal baseado no ambiente X, como o xterm ou o rxvt. A variável TERM deve ser definida comoxterm ou vt100 no lado remoto.

Esse comportamento pode ser causado por diversos motivos relacionados a interrupções de hardware e/ou software. Pode ser devido a algum bug, mas também pode acontecer por causa da natureza de alguns devices. Por exemplo, usar TCP/IP via porta paralela com uma MTU muito grande é uma boa forma de provocar esse comportamento. Aceleradores gráficos também são eficientes para criar esse tipo de problema, nesse caso, sendo necessário analisar as configurações de interrupções do software.

Um efeito colateral desse problema são processos que morrem“SIGXCPU exceeded cpu time limit”.

No FreeBSD 3.0 e sistemas posteriores a 29 de Novembro de 1998, caso o problema não possa ser solucionado de outra forma, uma correção pode ser definir a seguinte variável do sysctl:

# sysctl -w kern.timecounter.method=1

Isso causa um impacto de performance, mas dependendo do problema que causava esse comportamento, é provável que nem consiga-se notar a mudança nessa performance. Se o problema continuar, mantenha a variável do sysctl habilitada e defina a opção NTIMECOUNTER no kernel para valores crescentes. Se chegar a um ponto em que foi necessário definir NTIMECOUNTER=20 e o problema ainda não tiver sido resolvido, as interrupções são serias demais e seu comportamento não é confiável.

Isso acontece no FreeBSD 3.X com placas de som PCI. A pcm0 é reservada exclusivamente para placas de som ISA e por isso se a placa em questão é PCI, ela será reconhecida como pcm1 e a mensagem em questão pode acontecer.

Caso sua placa de som seja PCI ainda será preciso criar a device snd1 ao invés da snd0:

# cd /dev
# ./MAKEDEV snd1

Esse comportamento não ocorre na série 4.X do FreeBSD, muito trabalho foi feito para tornar o sistema mais PnP-centric e a device pcm0 não é mais reservada exclusivamente para placas ISA.

O FreeBSD 4.X é muito mais PnP-centric do que as versões anteriores, e isso causou alguns efeitos distintos em algumas placas PnP (como algumas placas de som e alguns modems interno por exemplo) que não funcionam mais da forma como funcionavam no FreeBSD 3.X.

O motivo para esse comportamento é explicado no seguinte e-mail, que foi enviada na lista freebsd-questions pelo Reter Wemm, respondendo uma pergunta sobre um modem interno que não era mais reconhecido no FreeBSD depois de atualizar o sistema para versão 4.X (os comentários entre []foram adicionados com a intenção de explicar melhor o contexto da mensagem).

A bios PNP configurou ele [o modem] e o deixou conectado na porta em questão, por isso o estilo antigo [no 3.X] “reconhece” o equipamento ISA.

No FreeBSD 4 o código ISA é bem mais PnP-centric. Era possível [no 3.X] encontrar uma placa ISA que funcionava com “determinada” device e depois, o id PNP da mesma device encontrava a mesma placa novamente, como se fosse uma outra usando os mesmos recursos do sistema, e por isso ele falhava, como se fosse um conflito de recursos. Portanto, agora ele desabilita o suporta às placas programáveis de forma que essa confusão e dupla detecção de hardware não ocorra. Essa mudança implica também na necessidade de se saber previamente os ids PnP para cada tipo de equipamento suportado, aumentando um pouco mais a lista de TODO do suporte PnP no sistema.

Para fazer o equipamento voltar a funcionar, é necessário encontrar seu PnP id e adicioná-lo a lista de devices ISA reconhecidas como PnP. Essa informação pode ser obtida usando pnpinfo(8) que detecta a configuração dos equipamentos. Por exemplo, veja a saída do pnpinfo(8) de um modem interno:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[algumas linhas com TAG foram eliminadas]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

A informação que você quer é a linha “Vendor ID” no começo da saída do comando. O valor hexadecimal entre parênteses (0x3024a341 esse caso) é PnP id e o conjunto de caracteres que o antecede (PMC2430) é a identificação ASCII única.

Alternativamente, se o pnpinfo(8) não listou sua placa em questão, o pciconf(8) pode ser usado preferivelmente. Esta é a saída do comando pciconf -vl de uma placa de som onboard:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

Aqui deve-se usar o valor do chip, “0x24158086”.

Tais informações (Vendor ID ou valor do chip) precisam ser adicionadas ao arquivo /usr/src/sys/isa/sio.c.

Primeiro faça uma cópia de segurança do sio.c no caso de algo dar errado e também para que você possa fazer um patch para enviar junto com o seu Relatório de Problemas (você vai enviar um PR, não vai?) e depois edite o sio.c e procure a linha

static struct isa_pnp_id sio_ids[] = {

Depois analise as linhas logo abaixo para encontrar o lugar apropriado para sua placa. As entradas na tabela ficam todas parecidas com essa logo abaixo, e são ordenadas de acordo com a identificação ASCII do fabricante do produto a qual deve ser incluída como comentário na coluna do lado do código em questão, e junto com a descrição da placa ou parte dela, conforme identificada na saída do pnpinfo(8):

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */

Adicione o ID hexadecimal do fabricante da placa no local apropriado, salve o arquivo e recompile o kernel, depois reinicie o sistema. Agora a sua placa deve ter sido encontrada como uma device sio exatamente como era encontrada no FreeBSD 3.X

O problema é que o programa que você está tentando executar tenta ler alguma informação específica do kernel, baseando-se no kernel symbol em questão, mas por algum motivo, essa informação não pode ser encontrada; esse erro é causado por um dos seguintes problemas:

• O kernel e o userland do sistema não estão em sincronia (por exemplo, você compilou um kernel novo e o instalou sem de dar um installworld, ou vice-versa), e por isso a tabela de informações dos kernel symbols é diferente do que o programa pensa que é. Se esse for o caso basta completar os procedimentos de atualização do sistema (veja o arquivo /usr/src/UPDATING para a correta seqüência de ações).

• O /boot/loader não está sendo usado para carregar o kernel dessa estação, ao invés dele, o boot2 (veja boot(8)) está sendo usado diretamente. Apesar de não ter problema algum deixar de usar o /boot/loader, ele costuma se comportar melhor na hora de tornar os kernel symbols disponíveis para aplicações em nível de usuário.

O sintoma: existe um atraso muito grande entre o estabelecimento da conexão TCP e o momento que o programa cliente pede a senha (ou no caso do telnet(1), quando a tela de login aparece).

O problema: o programa servidor dessa transação leva muito tempo tentando resolver o nome da estação cliente que está se conectando. A maioria dos servidores, incluindo os servidores Telnet e SSH que vem junto com o FreeBSD tentam resolver o número IP do cliente no nome da estação, para, entre outras coisas, gravar essa informação em um arquivo de log para referências futuras por parte do administrador.

A solução: Se o problema acontece apenas quando você (o cliente) tenta se conectar no servidor, o problema é com o lado cliente da transação; se o problema acontece com qualquer estação que tente se conectar ao computador (servidor) então o problema é do lado servidor.

Se o problema é com o cliente, a única maneira de corrigir o problema é configurar corretamente o servidor DNS que responde autoritativamente pelo endereço da estação. Se for uma rede local considere esse comportamento um problema do servidor, e continue lendo; se a conexão deve ser estabelecida na rede global (internet) , então entre em contato com o seu Provedor de Serviços Internet e solicite que eles corrijam o problema.

Se o problema é do lado servidor, e a rede em questão, se trata de uma rede local, será necessário configurar o servidor de forma que ele consiga resolver os endereços dos clientes em nomes. Veja as páginas de manual do hosts(5) e named(8) para obter mais informações. Se a conexão é na Internet, provavelmente o resolvedor (lado cliente do serviço de nomes) do seu servidor não está funcionando corretamente. Pra fazer o teste, tente descobrir o endereço IP do site www.yahoo.com por exemplo. Se não funcionar, esta ai o problema.

Stray IRQs são sintomas de hardware que interrompe o pedido de interrupção no meio de um ciclo de autorização de interrupção.

Existem três formas de tratar o problema:

• Aprenda a conviver com as mensagens de advertência. De qualquer forma, todas as mensagens exceto as 5 primeiras para cada IRQ são suprimidas pelo sistema mesmo.

• Evite o inconveniente alterando de 5 para 0 na função isa_strayintr() o número de mensagens antes de suprimir as advertências.

• Evite as advertências instalando algum equipamento de porta paralela que use a IRQ 7 e o driver PPP (é o usual, na maioria dos sistemas) e instale algum driver IDE ou qualquer outro dispositivo que use a IRQ 15 e seu respectivo suporte.

Esse erro indica que você excedeu o número máximo de descrevedores (descriptors) de arquivos no sistema. Leia a seção kern.maxfiles da capítulo de Ajuste de Limites do Kernel no Manual do FreeBSD do FreeBSD para obter mais informações sobre o problema.

Rode o comando dmesg(8), e procure algumas linhas com a expressão Timecounter. A última linha encontrada será o relógio que o FreeBSD escolheu, e com certeza ele será TSC.

# dmesg | grep Timecounter
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 595573479 Hz

Essa informação pode ser confirmada ao verificar a variável kern.timecounter.hardware do sysctl(3).

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC

A BIOS do laptop altera a frequência do relógio TSC de forma a modificar a velocidade do processador quando o computador estiver sendo utilizado com baterias, ou se o mesmo entrar em modo de economia de energia. O FreeBSD não faz distinção entre frequência do clock e modos especiais de trabalho, e por isso pode atrasar ou adiantar a hora do sistema.

Esse exemplo, o laptop em questão tem dois relógios; portanto o i8254 pode ser definido como padrão na variável kern.timecounter.hardware do sysctl(3).

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

Agora o seu laptop deve conseguir manter a data e hora de forma mais precisa.

Pra tornar essa alteração automática, adicione a seguinte linha no arquivo /etc/sysctl.conf.

kern.timecounter.hardware=i8254

Esse problema é comum em laptops que tem mais de um sistema operacional instalado. Alguns sistemas não-BSD fazem os cartões PCMCIA ficarem em um estado inconsistente, causando um reconhecimento problemático dos dispositivos por parte do pccardd, como por exemplo, detectando os cartões como “"(null)""(null)"” ao invés da sua marca e modelo verdadeiros.

É necessário desligar completamente a alimentação de energia do equipamento para garantir que o mesmo seja completamente resetado. Desligue completamente o laptop (não suspenda seu funcionamento, não o deixe entrar em modo de espera, conhecido como standby, a alimentação deve ser completamente interrompida), espere alguns - poucos - minutos e reinicie o laptop. Tudo deve correr bem.

Alguns laptops são grandes mentirosos quando afirmam estar desligados. Se o procedimento acima não funcionar, tire a bateria do laptop, espere alguns minutos e ligue o sistema novamente.

O inicializador do FreeBSD reconheceu a geometria de disco de forma incorreta e por isso esse valor deve ser definido manualmente com o fdisk(8) ao criar ou modificar uma partição FreeBSD.

A geometria correta do disco pode ser verificada na BIOS do computador. Procure pelo número de cilindros, cabeças e de setores do disco em questão.

No fdisk do sysinstall(8), aperte a tecla G para definir a geometria do disco manualmente.

Irá aparecer uma janela de diálogo perguntando o número de cilindros, cabeças e setores do disco. Defina esses valores, conforme anotados da BIOS do sistema e separados por barras.

5000 cilindros, 250 cabeças e 60 setores, por exemplo, seria definido como 5000/250/60.

Aperte ENTER para confirmar os valores e depois aperte a tecla W para escrever as novas informações na tabela de partições do disco.

Entre no sysinstall(8) e escolha o menu Configure, seguido do Fdisk. Escolha o disco onde o gerenciador de boot costumava ficar e aperte a barra de espaços(space). Depois aperte a tecla W para escrever as novas informações no disco. Vai aparecer uma tela, perguntando o que deve ser instalado na MBR do disco. Escolha o Gerenciador de inicialização(Boot Manager), e ele será reinstalado.

Quer dizer que existe um processo tentando paginar uma área da memória para o disco, e que esse processo demorou mais de 20 segundos; portanto falhou. É provável que a causa desse erro sejam blocos defeituosos no disco, falha nos cabos, ou até mesmo algum outro erro de I/O relacionado ao hardware. Se o disco estiver danificado, serão apresentadas mensagens de erro referentes ao mesmo em /var/log/messages e também na saída do dmesg. Do contrário, verifique seus cabos e conectores.