Suporte no Linux

Como funciona o suporte a hardware no Linux

Já que o principal objetivo desta análise é falar sobre o suporte no Linux, vamos começar com uma pequena introdução sobre o assunto. As distribuições estão cada vez mais automatizadas, de forma que, na maioria dos casos, todos os componentes compatíveis são detectados durante a instalação e tudo funciona sem a sua intervenção. Mas, de qualquer forma, é interessante entender como as coisas funcionam por baixo dos panos, pois este é o primeiro passo para aprender a solucionar problemas.

O suporte a dispositivos no Linux é feito através de “módulos” incluídos no Kernel, arquivos que ficam dentro da pasta “/lib/modules/versão_do_kernel_usada/“. Estes módulos são a coisa mais parecida com um “driver” dentro da concepção que temos no Windows. Para ativar suporte a um certo dispositivo, você precisa apenas carregar o módulo referente a ele.

Veja que os módulos ficam organizados em pastas: a pasta “kernel/drivers/net/” contém drivers para placas de rede, a pasta “kernel/drivers/usb/” agrupa os que dão suporte dispositivos USB e assim por diante.

Até o Kernel 2.4, os módulos de Kernel utilizavam a extensão “.o“, que é uma extensão genérica para objetos em C. A partir do Kernel 2.6, passou a ser usada a extensão “.ko” (kernel object), que é mais específica.

Quase sempre, os módulos possuem nomes que dão uma idéia do dispositivo a que oferecem suporte. O “8139too.ko” dá suporte às placas de rede com o chipset Realtek 8139, o “sis900.ko” dá suporte às placas SiS 900, enquanto o “e100.ko” ativa as placas Intel E100.

index_html_1a686532

Os módulos podem ser carregados e descarregados a qualquer momento usando os comandos “modprobe” e “modprobe -r“; não apenas na inicialização do sistema.

Existe também o comando “insmod“, mais antigo, que também permite carregar módulos. A diferença entre o “insmod” e o “modprobe” é que o modprobe carrega apenas módulos já instalados, junto com todas as dependências, ou seja, outros módulos de que o primeiro precise para funcionar. Se você tentar carregar o módulo “usb-storage” (que dá suporte a pendrives e HDs USB), vai perceber que serão carregados também os módulos “usbcore” e “ehci-hcd“.

O “insmod” é muito menos inteligente, carrega apenas o módulo solicitado, retornando um erro caso ele precise de outros. A única vantagem é que ele permite carregar módulos a partir de qualquer pasta, permitindo que você teste um módulo que acabou de compilar, ou que gravou num pendrive, por exemplo. Algumas distribuições oferecem uma opção de carregar módulos adicionais durante a instalação, justamente pensando nos raros casos onde você precisa de um determinado módulo para ativar a placa SCSI onde está instalado o HD para poder prosseguir com a instalação, por exemplo.

Os módulos são gerados durante a compilação do Kernel. Você não precisa se preocupar com isso se não quiser, pois as distribuições quase sempre incluem versões bem completas do Kernel por padrão. Mas, de qualquer forma, existe sempre a possibilidade de recompilar o Kernel, mexendo nas opções e ativando ou desativando os módulos que quiser.

index_html_43c7f517

Você pode incluir módulos para todo tipo de dispositivos, de marcas e modelos diferentes. Eles não atrapalham em nada, pois apenas alguns deles (os que você estiver usando no momento) ficarão carregados na memória. Estes módulos geralmente são pequenos; um conjunto completo com os módulos para todo tipo de dispositivos (que totalizam mais de mil arquivos no Kernel 2.6), normalmente ocupa de 40 a 50 MB no HD.

Podemos dividir os drivers de dispositivo para o Linux em dois grupos. O primeiro é o dos drivers de código aberto, que podem tanto ser desenvolvidos pelos próprios fabricantes quanto por voluntários em cantos remotos do mundo. Desenvolver drivers usando engenharia reversa sem ajuda dos fabricantes parece ser um passatempo bastante popular :-).

Estes drivers open-source são incluídos diretamente no Kernel, o que faz com que sejam incluídos diretamente nas distribuições e você não precise se preocupar muito com eles.

A segunda categoria é a dos drivers proprietários, de código fechado, que são desenvolvidos pelos próprios fabricantes. Em alguns casos os drivers são de livre distribuição e também podem ser incluídos diretamente nas distribuições. Em outros, você mesmo precisará baixar e instalar o driver. É aqui que entram os drivers para softmodems, para muitas placas wireless e também os drivers para placas 3D da nVidia e da ATI.

No caso do NX6310 e outro modelos similares, não precisaremos de nenhum driver proprietário adicional, o que é uma boa notícia, pois você não precisará se preocupar em compilar nada manualmente. A placa wireless é um “meio termo”, pois precisaremos do driver Windows, disponível no site da HP para ativá-la. Vamos então à análise:

Processador

Os processadores dual core ainda são uma relativa novidade no mercado doméstico. Depois de mais de 3 décadas (o Intel 4004 foi lançado em 1971) de miniaturização e sucessivos aumentos na freqüência de clock dos processadores, tanto a Intel quanto a AMD mudaram o foco e passaram a trabalhar em formas de aumentar o volume de informações processadas por ciclo de clock, aproveitando a evolução nos processos de fabricação para fabricar processadores com mais transistores (o que ainda é relativamente simples de fazer) ao invés de processadores com um maior clock (o que se tornou cada vez mais difícil, como mostrou o fiasco do Pentium 4).

Uma das formas encontradas foi passar a fabricar processadores dual-core, onde dois processadores compartilham o mesmo waffer de silício e o mesmo encapsulamento. Montar uma máquina com um processador dual-core é muito mais barato que montar uma com dois processadores e o poder de processamento é o mesmo.

O Core Duo T2300 usado no NX6310 opera a 1.66 GHz e possui 2 MB de cache L2. O cache é compartilhado entre os dois cores, o que faz com que o aproveitamento seja melhor, já que a distribuição é feita dinamicamente, de acordo com a carga de processamento de cada um. O T2300 inclui também suporte a instruções de 64 bits e ao Intel VT, o sistema de virtualização via hardware, que pode vir a ser usado para melhorar o desempenho das futuras versões do VMware e Xen. Ele é baseado no core Conroe, produzido numa técnica de 0.065 micron. Leia a minha análise sobre a plataforma no: https://www.hardware.com.br/analises/core-duo/

index_html_m196ff917

Ativar o suporte ao segundo processador no Linux é simples: é necessário apenas usar uma imagem de Kernel compilada com suporte a SMP. Na maioria das distribuições, o SMP não vem habilitado por padrão, pois isso causa problemas diversos com muitas placas antigas, sobretudo as PC-Chips com chipset SiS, de forma que você precisa instalar manualmente.

No caso do Kurumin 6.1, use meu script “install-kernel-smp“, através da opção “Suporte a Hardware > Instalar Kernel com suporte a SMP (e dual-core)”. O script faz o download e a instalação automaticamente, e no final pede para reiniciar o micro:

index_html_m5cbdccf

No caso do Ubuntu, você deve instalar o Kernel para processadores 686, via apt-get. O primeiro passo é abrir o arquivo “/etc/apt/sources.list” e descomentar a linha referente ao repositório “Universe”:

# sudo gedit /etc/apt/sources.list

Rode o comando “apt-get update” para atualizar a lista e rode o comando “uname -a” para checar qual versão do Kernel está instalada. O Ubuntu 6.6, por exemplo, vem com o Kernel 2.6.15-23. Para instalar a versão 686 do mesmo Kernel, você usa o comando:

# sudo apt-get install linux-image-2.6.15-23-686

Use a tecla TAB para ver outras opções disponíveis. Você pode instalar uma versão mais recente do Kernel se preferir. Ao instalar o pacote, será criada a entrada no menu de boot do grub automaticamente. Você precisa apenas reiniciar o micro.

Você pode verificar se o segundo core está ativado usando o comando “cat /proc/cpuinfo“. Com os dois cores ativados, o arquivo conterá duas entradas, uma para o processador 0, outra para o processador 1:

index_html_7d02da1a

Outro recurso interessante dos processadores baseados na plataforma Core é o sistema de gerenciamento de energia. Uma das grandes diferenças entre os notebooks baseados em processadores Pentium-M, Core Solo ou Core Duo, em relação aos com o Celeron-M é justamente o fato do Celeron-M não suportar o SpeedStep. Mesmo que a bateria e os demais componentes dos notebooks sejam iguais, o note com o Celeron esquenta bem mais e tem uma autonomia de bateria reduzida.

Claro, não adiantaria nada gastar mais caro para ter um Core Duo, se você não fosse aproveitar os recursos oferecidos pelo processador.

O primeiro passo é ativar o gerenciamento de energia. No Kurumin 6.1 e no Ubuntu 6.6 o SpeedStep é ativado automaticamente durante o boot, mas aqui vai o caminho das pedras para ativá-lo manualmente em outras distribuições:

O primeiro passo é instalar o pacote “powernowd“. Nas distribuições derivadas do Debian, instale-o via apt-get, como em:

# apt-get install powernowd

No Ubuntu e Kubuntu o comando é o mesmo, você deve apenas ter o cuidado de descomentar a linha referente ao repositório “Universe” dentro do arquivo “/etc/apt/sources.list”.

No Mandriva, instale-o usando o comando “urpmi powernowd“. No Fedora e outras distribuições você pode instalar a partir do pacote com os fontes, disponível no: http://www.deater.net/john/powernowd.html.

Com o powernowd instalado, adicione as linhas abaixo no final do arquivo “/etc/modules“, para que os módulos necessários sejam carregados durante o boot:

acpi
freq_table
speedstep-centrino
cpufreq_ondemand
cpufreq_performance
cpufreq_powersave

Os três módulos do cpufreq que carregamos, permitem que você escolha o perfil de gerenciamento a utilizar, alternando entre eles conforme desejado.

Se você usa o KDE, clique com o botão direito sobre o ícone da bateria ao lado do relógio e acesse a opção “Configurar Klaptop”:

index_html_173e8f03

Dentro da janela, acesse a aba “Configurar ACPI” (a última) e clique no botão “Definir Aplicação Auxiliar”. Forneça a senha de root, e, de volta à janela principal, marque todas as opções e clique no “Aplicar”:

index_html_2f8a5851

Feito isso, reinicie o micro e o SpeedStep estará ativado. Você pode checar a freqüência real de operação do processador a qualquer momento usando o comando “cpufreq-info“, como neste screenshot:

index_html_261d8410

O Cure Duo T2300 pode oscilar entre 1.0 GHz e 1.66 GHz. A diferença pode parecer pequena, mas operando a 1.0 GHz a tensão de operação também é reduzida, fazendo com que o processador consuma menos da metade que na freqüência máxima. O fato da freqüência de operação do processador nunca cair abaixo de 1.0 GHz, e o chaveamento entre as freqüências ser muito rápido, faz com que seja realmente difícil de perceber qualquer diferença de desempenho com o gerenciamento ativado ou desativado.

Para alternar entre os perfis de performance, clique com o botão direito sobre o ícone da bateria e clique na opção desejada dentro do menu “Perfil de Performance. No modo “powersave” o processador prioriza a autonomia da bateria, demorando mais tempo para subir a freqüência de operação, enquanto o modo “performance” é o oposto:

index_html_481a54bc

Uma observação é que no meu caso o cpufreq setou incorretamente a freqüência máxima de operação do processador para 1.33 GHz, ao invés de 1.66 GHz, fazendo com que ele sempre operasse a uma freqüência um pouco abaixo do máximo. Para corrigir o problema manualmente, usei o comando:

# cpufreq-set –max 1670000

O número indica a freqüência máxima do processador (em khz, por isso o monte de zeros).

Placa de som e rede

Este note usa a placa de som integrada ao chipset, uma “Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller“, como nos informa o comando lspci :).

index_html_md04825f

Ela é detectada corretamente tanto no Kurumin 6.1, quanto no Ubuntu 6.6, dispensando qualquer configuração manual.

Em caso de problemas, você pode reconfigurar a placa usando o comando “alsaconf“. Ao usá-lo, lembre-se sempre de ajustar o volume usando o aumix, alsamixer, kmix ou outro programa de ajuste de som, pois ele deixa a placa de som muda, para evitar sustos :). Basta abrir uma janela de terminal e executar o comando como root. Toda a detecção é feita automaticamente:

index_html_2bcac2ee

Esta página reporta um problema com o som, que saia apenas através do conector para os fones, e não através dos speakers. Este problema teria sido resolvido a partir do alsa 1.0.11 (de forma que afeta apenas distribuições antigas), mas de qualquer forma, não encontrei este problema nos meus testes: http://www.linlap.com/tiki-index.php?page=Hewlett-Packard+nx6320.

Esta placa de som funciona melhor usando os drivers de som alsa, o conjunto de drivers de som padrão do Kernel 2.6, que são usados em praticamente todas as distribuições atuais. O alsa inclui drivers para um grande número de placas. O que ativa a do NX6310 é o módulo “snd-hda-intel“, que é um relativo novato.

A placa de rede funciona através do módulo “b44“, e também funciona sem problemas. O único porém é que esta ainda é uma placa de 100 megabits.

Como de praxe, é importante usar uma distribuição recente, com um conjunto de drivers atuais para que tudo funcione como deveria. Uma distribuição antiga ainda não teria os drivers de som e o módulo que ativa o suporte 3D para a placa de vídeo, por exemplo. O mínimo recomendável para o HP NX6310 é uma distribuição com o Kernel 2.6.15 ou mais atual.

Video

Hoje em dia, tanto a nVidia quanto a ATI oferecem opções de chipsets com vídeo integrado e chipsets 3D dedicados para notebooks. As soluções mobile da nVidia e ATI oferecem um desempenho muito melhor, mas em compensação encarecem o projeto e aumentam o consumo e aquecimento do note.

O NX6310 utiliza o vídeo onboard do chipset ICH7, um “Intel Mobile 945GM/GMS/940GML”, que utiliza memória compartilhada. Esta solução da Intel possui um desempenho bem modesto se comparado com qualquer placa 3D atual, mas oferece como vantagem o baixo consumo elétrico e o baixo custo.

A boa notícia é que este chipset possui um bom suporte no Linux, contando inclusive com um driver 3D open-source, incluído no X.org.

Usando o Ubuntu, ou o Kurumin 6.1 beta3 em diante, o vídeo é detectado corretamente e com a aceleração 3D habilitada. Aqui estou jogando o bom e velho Quake 3. Meio fora de moda, mas ainda divertido :P.

index_html_m1b73544a

Em caso de problemas com a detecção do vídeo em outras distribuições, verifique em primeiro lugar, qual driver de vídeo está sendo usado. Muitas distribuições detectam o vídeo incorretamente, utilizando o driver “vesa”, que não oferece nenhum tipo de aceleração ou suporte 3D.

Mas, a solução nestes casos é simples. Independente da ferramenta de configuração disponível, você pode alterar o driver usado diretamente no arquivo “/etc/X11/xorg.conf“. Procure pela linha:

Driver “vesa”

E substitua por:

Driver “i810”

Para que a alteração entre em vigor, reinicie o X pressionando “Ctrl + Alt + Backspace“.

Um segundo possível problema é que o pacote “libgl1-mesa-dri” disponível no Debian Etch, ainda não inclui o patch que ativa o suporte 3D para a placa. Este problema afeta várias distribuições derivadas dele. Se atualizar o pacote através do apt-get não resolver, você pode instalar manualmente o arquivo com o patch aplicado. Este arquivo deve funcionar em qualquer distribuição baseada no X.org 6.9 ou 7.0:

https://www.hardware.com.br/kurumin/download/i915_dri.so

Para usá-lo, copie-o (como root) para dentro da pasta “/usr/lib/dri/“, substituindo o arquivo original. Reinicie o X e teste rodando algum game ou aplicativo 3D. É interessante fazer um backup do arquivo original, para qualquer eventualidade.

Placa Wireless

O NX6310 não é um notebook Centrino, pois apesar de usar um processador e chipset Intel, ele vem equipado com uma placa wireless “Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card”, um modelo até que bastante comum em notebooks atualmente.

Existem duas opções para a configuração desta placa no Linux. A primeira é usar o módulo “bcm43xx“, que é o driver open-source, desenvolvido via engenharia reversa. Ele pode ser encontrado nas distribuições com Kernel 2.6.17 em diante, e também no Ubuntu 6.6, que apesar de usar um Kernel um pouco mais antigo, vem com o patch instalado.

O problema é que este driver ainda está bem incompleto, e por isso não suporta WPA e outros recursos, além de precisar que o firmware da placa (um componente do driver Windows) seja instalado manualmente. Veja mais detalhes sobre como configurar o driver bcm43xx mais adiante.

A segunda opção é usar o Ndiswrapper, para carregar o driver Windows. Até o momento ele é a melhor opção, pois permite utilizar todos os recursos da placa.

No caso do Ubuntu, é necessário abrir o arquivo “/etc/modprobe.d/blacklist” e adicionar a linha “blacklist bcm43xx” no final do arquivo, para que o driver bcm43xx deixe de ser usado, dando espaço para o Ndiswrapper.

Configurar o Ndiswrapper no Kurumin é bastante simples, pois você pode utilizar o script “ndiswrapper-kurumin“, disponível através do “Conectar na Internet ou configurar a rede > Wireless > Ndiswrapper”:

index_html_19f45440

Para usar o Ndiswrapper, você precisa ter em mãos os drivers para Windows XP da placa. No caso do HP NX6310 e 6320, você pode baixar a versão que testei no:
ftp://ftp.compaq.com/pub/softpaq/sp32001-32500/sp32158.exe

Este é um arquivo auto-instalável, por isso o “.exe”. Para poder usá-lo no Linux, precisaremos primeiro descompactar o arquivo usando o comando “cabextract“, como em:

$ cabextract sp32158.exe

Se o comando não estiver disponível, instale o pacote “cabextract” usando o apt-get, urpmi ou yum (no Fedora) e tente novamente.

Quando o script pedir o arquivo .inf do driver, indique o arquivo “bcmwl5.inf“, dentro da pasta onde ele foi descompactado:

index_html_592e920f

Mais adiante o script pergunta sobre o sistema de encriptação usado na rede. Veja que está disponível a opção de conectar a uma rede com encriptação WPA:

index_html_m552e9156

Depois de fornecer a configuração da rede, você tem a opção de salvar a configuração, para que ela seja restabelecida automaticamente durante o boot.

O maior problema em utilizar o ndiswrapper é que o driver trava caso a placa wireless seja colocada em modo de economia de energia, o que acontece automaticamente depois de algum tempo de inatividade. Quando isso acontece, o driver fica travado e a placa não transmite mais dados até que você reinicie o micro. Não adianta nem tentar desativar e reativar o ndiswrapper.

Apesar disso, existe uma solução muito simples para o problema: basta impedir que a placa entre em modo de economia de energia, mantendo a conexão sempre ativa. A forma mais simples de fazer isso é usar o comando “ping” para enviar pacotes para um endereço qualquer a cada 15 segundos. Abra um terminal e rode o comando:

$ ping -i 15 google.com (o google.com pode ser substituído por outro endereço qualquer)

Para que ele seja executado automaticamente durante o boot, resolvendo o problema definitivamente, use os dois comandos abaixo, que criam um script dentro da pasta /etc/rc5.d:

# echo ‘ping -i 15 google.com &’ > /etc/rc5.d/S99ping
# chmod +x /etc/rc5.d/S99ping

Mantendo o ping ativo, a conexão se torna bastante estável, mesmo ao conectar em redes com encriptação WPA. Você pode deixar o note ligado durante vários dias (ele chegou a ficar ligado durante 4 dias consecutivos durante meus testes), mesmo sem usar a rede e a conexão se mantém aberta, pronta para usar.

O único inconveniente é que manter a placa ativa o tempo todo causa um pequeno aumento no consumo, reduzindo a autonomia das baterias em cerca de 10 minutos.

No Ubuntu, a melhor opção de interface gráfica de configuração é o “ndisgtk”, que você pode instalar via apt-get:

$ sudo apt-get install ndisgtk

Depois de instalado, será incluído o ícone “Windows Wireless Drivers” no menu “Sistema > Administração”. Ele é bem simples de usar: clique no “install new driver“, indique o driver Windows que será carregado. Clicando no “Configure Network” você abre o network-admin, onde pode configurar os parâmetros da rede:

index_html_75b131a

A maior dificuldade é que no Ubuntu não está disponível nenhum script para conectar a uma rede WPA, de forma que você precisa instalar o wpa_supplicant e fazer a configuração manualmente, como explico aqui: https://www.hardware.com.br/guias/configurando-wireless/

Como disse, existe também a opção de usar o módulo “bcm43xx“, que é o driver nativo, ao invés do Ndiswrapper. O procedimento de configuração ainda é bastante manual, se você é iniciante, ou não quer ter muito trabalho, recomendo que continue com o Ndiswrapper.

Para funcionar, ele precisa do firmware da placa, um componente do driver do Windows, de forma que você vai precisar baixar o arquivo “ftp://ftp.compaq.com/pub/softpaq/sp32001-32500/sp32158.exe” e extraí-lo usando o comando cabextract, da mesma forma que ao usar o Ndiswrapper.

O próximo passo é instalar o programa “fwcutter“, que usamos para extrair os arquivos do firmware. Ele está disponível aqui: http://bcm43xx.berlios.de/. Para instalá-lo, descompacte o arquivo e execute os comandos “make” e “make install”, como root. Você precisa ter instalado o pacote “build-essential”, que contém os compiladores necessários.

Com tudo em ordem, acesse a pasta onde foi extraído o driver Windows e execute o comando:

$ bcm43xx-fwcutter bcmwl5.sys

Isto vai gerar um conjunto de arquivos “.fw“. Para concluir a instalação, copie os arquivos para dentro da pasta “/lib/firmware/$versao_do_kernel“, no caso do Ubuntu (como em “cp *.fw /lib/firmware/2.6.15-23-386/”), ou simplesmente “/lib/firmware” no caso do Kurumin.

Concluindo, recarregue o módulo, usando os comandos abaixo, ou reinicie o micro:

# modprobe -r bcm43xx
# modprobe bcm43xx

Modem

O modem é único componente deste note que ainda não funciona no Linux. Como a maioria dos modems onboard, o chipset do modem é integrado ao chipset, compartilhando os circuitos da placa de som. Do ponto de vista técnico, uma placa de som e um modem são, até certo ponto parecidos, pois ambos transformam sinais digitais em som.

Os componentes analógicos do modem são instalados na placa MDR (Mobile Daughter Card, ou Modem Daughter Card), que tem uma função muito similar às plaquinhas AMR usadas em desktops, permitindo que os componentes analógicos (que precisam ser certificados pelos órgãos de telecomunicação de cada país) sejam separados do restante da placa mãe, facilitando (e até barateando) o projeto:

index_html_m254bfb9

No caso do NX6310, o modem é suportado pelo módulo “snd-hda-intel” (o mesmo que dá suporte à placa de som). Ao contrário da maioria dos drivers de modem, como o Smartlink e os drivers para modems Intel, este é um driver open-source, desenvolvido pela equipe do Alsa.

O driver consegue ativar o modem, mas (pelo menos até o Kernel 2.6.17) ainda existe uma incompatibilidade com a placa MDR. O modem é ativado, mas não consegue “escutar” a linha, de forma que ao tentar discar você recebe uma mensagem de “Sem portadora”. Se você desmarcar a opção “Esperar por tom de linha antes de discar” no Kppp, o modem chega a discar e você ouve a resposta do servidor remoto se ouvir por uma extensão do telefone. Mas, como o modem não consegue ouvir o sinal, o resultado é o mesmo:

index_html_586e4f21

Uma observação é que o modem usado no HP NX6110 (que é bem similar, porém suportado pelo módulo “snd-intel8x0m“) é perfeitamente compatível. Como estamos falando de um driver open-source, é provável que este problema seja resolvido nas próximas versões do alsa, eliminando esta última mancha no curriculum do 6310.

Caso queira testar, os passos para ativar o modem são os seguintes:

  • Não é preciso carregar o módulo que dá suporte ao modem, pois estamos falando do mesmo módulo que dá suporte à placa de som. Desde que ela esteja funcionando, significa que o modem também está ativo.
  • Ative o modem usando o comando abaixo, como root. É necessário que o pacote “sl-modem-daemon” esteja instalado:

# slmodemd –country=BRAZIL –alsa hw:0

  • Abra outro terminal e (como root), crie o link de acesso ao modem:

# ln -sf /dev/ttySL0 /dev/modem

  • Abra o KPPP, configure a conexão e tente discar.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X