“Se dependesse de mim estaria agora completamente bêbado numa rave em Ibiza, com uma dona toda suada e de biquini se esfregando em mim mas… quem não tem cão, recompila kernel domingo anoite”
E foi com esse bom humor que eu retruquei a um sábio conselho. Idiotice, eu sei. Teimosia, como sempre. Mas como eu não segui o conselho, meu bom humor está cafa vez mais minguado, e a tendencia é de queda.
Para quem não sabe, resolvi deixar o capeta, meu desktop, mais demoníaco: fiz um upgrade dele para uma A7N266-VM. Coloquei um Duron 800, o que, diante do antigo K6-2 500, é um salto tecnológico imenso! Sai sexta-feira passada, todo animado, dinheiro em mãos para comprar a maldita placa e memória, volto pra casa todo alegre com o novo brinquedo. A êxtase era tamanha que me dei até ao trabalho fazer algo que eu detesto: abrir o micro. Desmontei a placa antiga, fonte, recoloquei os suportes fixadores nos devidos lugares para acomodar melhor a nova placa, etc. Perdi um tempão até me dar conta de configurar a placa para a freqüência do processador, mas blz! Finalmente, depois disso tudo, a parte divertida: recompilar o kernel!
Como bom debian-user, fiz meu novo kernel: make-kpkg --config=menuconfig --revision=tmacam.1.5.k7 --added-patches=preempt,lowlatency --added-modules=i2c,lm-sensors,alsa-drivers kernel_image modules_image
Depois, compilei os modulos de rede proprietados da nVidia para a minha placa. Blz! Depois compilo os modulos proprietários ( mais! ) para o X – apt-get install nvidia-kernel-source nvidia-glx-source
. Blz! Compilo esses tb. Rebooto novamente. E ai?! Tudo rápido, voando, quase uma ejaculação precoce?! Que nada… O micro brochou geral!
O capeta estava leeeeeeeento – leeeeeeeeeeeeeeeeeeeeeeeeeeentoo. O Xmms engasgava! Como se nem com um k6-2 500 ele engasgava vem engasgar com um duron 800?! Chegava ao cúmulo do wget ficar pegando 76% da CPU! O wget! Mostrar um tooltip fazia o micro engasgar. Até escrever o inicio desse post tava insuportável: tinha delay!
Eu achava q era o patch para lowlatency, depois achava q era o gcc-3.2, achava… rapaz, achei q era tanta coisa q de tanto recompilar kernel via make-kpkg já sei a linha de comando de cor, com várias, várias opções de variação. Criei uma versão com alsa, sem alsa, sem lowlatency, outra sem preempt. O engraçado, mais engraçado, era que quando eu iniciava o micro num kernel antigo, compilado para i386, eu podia colocar um divix rodando, glxgears rodando, xmms tocando e o load do sistema não ultrapassava os 20%. Com os kernels novos apenas um wget rodando já fazia o xmms engasgasr, o mouse se arrastar, etc.
Depois de muitas frustrações, aparentemente consegui achar a fonte do problema: o driver proprietário para a placa de rede onboard (nvnet).O foda que essa placa onboard é o cão: tão boa quanto uma 3com ou uma intel etherexpress mas… o driver dela – so pode – estava levando meu sistema ao chão. Se eu carregasse o módulo com opção de optimizar o driver de rede para throughput o micro engasga e fazia coisas absusrdas como fazer o wget pegar até 76% da CPU (!!). Se eu colocasse para optimizar para CPU o micro trava e so volta a funcionar se eu ficasse bulinando no conector de rede – e bulinar não é mera força de expressão. Pode?! Seŕio, bulinando! Nem queiram saber o que me levou a fazer isso, nem eu seu, mas talvez o fato dele ter travado a primeira vez quando estava carregando o samba dê alguma dica.
Desabilitei a placa de rede onboard, coloquei a placa antiga e não observei nenhuma instabilidade. Fiz o teste dos testes: coloquei um mplayer para decodear em 2x do tamanho original um divx, rodei um apt-get update
, rodei o home bankinkg do bb no mozilla em paralelo com o galeon, deixei o xmms tocando e ainda coloquei o glxgears. Nenhum problema. Tudo redondo, redondo. Se eu tirasse o glxgears o load ficava inferior a 25%.
Er… mais um final de semana produtivo
Placebo – This Picture