Amenizando o problema com o driver ATI

Recentemente notei que o driver proprietário da ATI estava aumentando muito o consumo de memória do Xorg, o que está registrado nesta entrada. Eu tinha decidido usar o driver de código-aberto, onde o problema não existe, entretanto, tive de reconsiderar por um fator um tanto quanto importante: a função suspender só funciona com o driver proprietário e isso é importante considerando-se que uso um laptop.

Hoje, analisando o log do Xorg, notei a seguinte linha repetida algumas vezes:

(WW) AIGLX: 3D driver claims to not support visual

E como não uso isso, resolvi desativar o AIXGL no xorg.conf com a opção abaixo:

Section "ServerFlags"
Option “AIGLX” “false”
EndSection

Fiz isso mais porque não gosto de coisas “erradas” nos logs, mas o resultado é que foi surpreendente. Ao reiniciar o X com essa opção desativada, o consumo caiu consideravelmente. Os resultados obtidos com o htop podem ser vistos abaixo (editados):

Memória Virtual Residente Compartilhada
Antes: 125M 33736 9868
Depois: 38632 16028 7788

É claro que esses valores não devem ser considerados como reais sem uma complexa análise, mas pode-se inferir que houve sim uma redução no consumo de memória. Enfim, uma solução temporária(??) para quem quer reduzir o consumo de memória sem deixar de usar o driver proprietário da ATI.

:~)

Do Debian Etch

Drivers ATI e consumo exagerado de memória

Ontem compilei um novo kernel com o patch -ck e ao iniciar por ele, notei uma melhora na responsividade do sistema, mas algo mais me chamou atenção. Em situações normais, meu sistema inicia consumindo 27% de memória (129Mb), mas ao iniciar com o novo Kernel, o consumo havia se reduzido a ínfimos 16% (76Mb) de memória. Sabia que não poderia ser o Kernel a causa disso, compilar seu próprio Kernel pode melhorar o desempenho, mas não fazer milagres.

Depois de algumas horas, já sem procurar a causa para tal constatação, percebi que estava sem aceleração 3D e lembrei que tinha me esquecido de compilar os módulos do driver da ATI para o novo kernel. Fiz isso e reiniciei o X. Surpresa! O consumo havia voltado aos 27% habituais. Somente o módulo do kernel não consumiria tudo isso também. Ao olhar a lista de processos (ps aux) vi que haviam duas instâncias do X iniciadas, consumindo cerca de 10% de memória cada uma. Passei a usar o driver opensource e o consumo voltou a baixar, desta vez, havia apenas um processo do X e consumindo só 4% de memória.

Não sei se isso é um bug ou se é a forma do driver proprietário da ATI funcionar, mas não gostei da diferença gritante de desempenho. Como raramente faço uso de recursos 3D, optei por usar o driver opensource para atividades comuns, economizando uma boa quantidade de memória. Usei a versão do driver 8.1 (a 8.2 não mostrou nada sobre isso no changelog) no Debian Etch e com uma placa Radeon Xpress 200m. Se tiveram ou não o mesmo problema, favor comentar, fiquei curioso se isso é só um bug ou não.

:~)

Do Debian Etch

Corrigindo erro no desligamento no Debian Etch com kernel recente

Esse tutorial se aplica àqueles que usam o Debian Etch com um kernel mais atual que o 2.6.21 e que vêem a seguinte mensagem durante o desligamento:

DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN UTILITY
For more info, visit http://linux-ata.org/shutdown.html

Consultando o site indicado acima, você pode ter uma descrição detalhada sobre a causa do problema. Pra resumir, pode-se dizer que a forma como o utilitário Shutdown trabalha usando um kernel mais recente é inadequada, podendo a longo prazo, causar danos ao disco. Para corrigir isso, seria necessário atualizar o script de desligamento, que no Debian, está no pacote sysvinit.

Como pode-se ver na página de changelogs do pacote, isso foi corrigido no dia 23 de dezembro do ano passado, e hoje já está disponível no Debian Testing e Unstable. O problema fica para os usuários do Etch, que não receberam a correção, já que o kernel padrão dessa versão (2.6.1 não é afetado.

O uso de um kernel atual as vezes se faz necessário, principalmente por problemas relacionados a compatibilidade de hardware, motivo que me fez adotar a última versão disponível. E como não queria passar a usar o Lenny por um pequeno problema como esse, resolvi buscar uma solução.

Como o pacote é relativamente recente, não encontrei muitos artigos sobre o assunto, apenas algumas discussões em fóruns onde a única solução era usar gambiarras cuja eficiência era um tanto quanto duvidosa. Pensei em baixar o pacote do Lenny, mas as dependências requerem versões mais atuais da GlibC, então isso não seria possível. Por fim, a solução foi compilar um pacote com a versão atual, assim não teria problema com dependências.

Para os que não desejam fazer todo o processo, disponibilizei os pacotes do Sysvinit atualizados neste apontador. Os pacotes foram compilados para a arquitetura i386 e até o presente momento, não apresentou nem um tipo de problema. Se por motivos de segurança, aprendizado ou as duas coisas, continue lendo para você mesmo criar os pacotes.

Primeiramente, certifique-se que você tem os repositórios oficiais ativados no seu sources.list, incluindo os repositórios de código-fonte (aqueles que começam por deb-src). Pode seguir este apontador para verificar se estão corretos.

Agora, adicione também o repositório de código-fonte do Debian Lenny:

deb-src http://ftp.br.debian.br/debian lenny main

Depois de adicionar os repositórios necessários, atualize a lista de pacotes do apt-get:

# apt-get update

Entre em um diretório de sua escolha – sugiro /usr/src/ - e baixe as dependências de compilação e o código-fonte do pacote sysvinit:

# cd /usr/src/
# apt-get build-dep sysvinit
# apt-get -t lenny source sysvinit

Agora, entre no diretório recém criado do código-fonte do sysvinit:

# cd sysvinit-2.86.ds1

Construa os pacotes com o comando abaixo:

# dpkg-buildpackage -b -us -uc

Depois de terminar o processo, os pacotes .deb estarão no diretório /usr/src/ e só precisam ser instalados:

# cd ..
# dpkg -i *.deb

O comando acima irá instalar todos os pacotes .deb localizados no diretório, verifique antes se não existem outros pacotes lá. Para confirmar, certifique-se de instalar todos os pacotes criados, que devem ser:

initscripts_2.86.ds1-53_i386.deb
sysvinit_2.86.ds1-53_i386.deb
sysvinit-utils_2.86.ds1-53_i386.deb
sysv-rc_2.86.ds1-53_all.deb

Pronto, se quiser, pode apagar o diretório do código-fonte e os demais pacotes para liberar espaço. Tentei ser o mais sucinto possível sem omitir informações importantes, qualquer dúvidas sobre o processo usado, por favor, use os comentários e responderei assim que puder. Só lembrando que não me responsabilizo por quaisquer danos ou problemas causados pela instalação dos pacotes ou pelos procedimentos aqui descritos. Espero que tenha sido útil.

:~)

Do Debian Etch