Até o meio do ano passado, meu computador era um Athlon XP 2.3 GHz com 128 MB de memória e 40 GB de HD. Fraquinho, mas funcionava até bem. Eu continuaria utilizando-o cotidianamente se não tivesse de utilizar o OpenOffice.org e o Eclipse. Além disso, estava querendo brincar com outros sistemas operacionais, e preferia virtualizá-los. Isso obviamente era inviável na máquina antiga.

Vendo que não havia mais para onde escapar, comprei outro computador. O computador era de um amigo meu, tinha 80 GB de HD, 1 GB de memória, gravadora de DVD e uma placa GForce 2200, ou algo assim. É uma máquina ótima para meus objetivos. Formatei as partições, instalei um Debian e configurei a máquina.

Notei, porém, que o computador estava bastante lento, muito mais lento que minha máquina antiga. Depois de pesquisar, descobri que era um problema com o HD e DMA. O syslog estava cheio de mensagens como:

Apr 8 00:17:41 localhost kernel: ide: failed opcode was: unknown
Apr 8 00:17:47 localhost kernel: hda: status timeout: status=0xd0 { Busy }
Apr 8 00:17:47 localhost kernel:
Apr 8 00:17:47 localhost kernel: ide: failed opcode was: unknown
Apr 8 00:17:47 localhost kernel: hdb: DMA disabled
Apr 8 00:17:47 localhost kernel: hda: drive not ready for command
Apr 8 00:17:47 localhost kernel: ide0: reset: success
Apr 8 00:14:07 localhost kernel: hdb: dma_timer_expiry: dma status == 0x41
Apr 8 00:14:07 localhost kernel: hdb: DMA timeout error
Apr 8 00:14:07 localhost kernel: hdb: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }

Aparentemente, havia algum erro ao carregar os módulos do DMA. Pesquisando sobre o problema, vi sugestões para verificar a saída do comando hdparm -i /dev/hda. O resultado foi algo como:

/dev/hda:

Model=SAMSUNG SP0802N, FwRev=TK100-24, SerialNo=S00JJ10XB83245
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156365903
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0:  ATA/ATAPI-1,2,3,4,5,6,7

* signifies the current active mode

Em resumo, a linha

UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

indicava que o módulo do DMA estava carregado! O que, então, estava dando errado?

Em uma breve pesquisa no Google, encontrei essa thread nos Ubuntu Forums. Nela, alguem sugere verificar se o HD estava configurado para Master ao invés de Cable Select. Meu HD já estava jumpeado e cabeado como Master. Todas as outras soluções que encontrei não funcionaram para ninguém – inclusive, não funcionavam para mim. O que fazer?

Pois bem, em um experimento, eu coloquei o HD como Secondary Master; antes, reconfigurei o GRUB para que o root do kernel passasse a ser /dev/hdc1 e editei o /etc/fstab trocando /dev/hda por /dev/hdc (e vice-versa). Liguei a máquina e… Voi là! O problema sumiu!

Hoje, porém, fui tentar configurar o HD como Primary Master e pesquisar por uma solução menos estranha. Infelizmente, tive novamente o mesmo problema com DMA, não importasse o que eu fizesse. Desisti e voltei o HD para Secondary Master – afinal, estava só explonrando possibilidades. Quando reinicio a máquina, o erro de DMA reaparece, agora com o HD como Secondary Master! Desligo então a máquina, tiro e recoloco o cabo flat no HD e reinicio a máquina. Voi là!² o problema foi resolvido novamente.

Então, se você está tendo esse problema, tente tirar e recolocar o cabo flat, que pode estar frouxo. Se isso não funcionar, dá uma olhada na thread citada, que ela tem boas dicas. Entretanto, se ela não te ajudar, tente colocar o HD como Secondary Slave (ou como Master Slave, se já estiver como Secondary Slave). Vai que funciona, não é?

HTH. Até mais!

Eu estava tentando usar o VirtualBox no meu computador de casa, que roda Debian Lenny. No começo, até funcionou, mas o kernel Linux foi atualizado em algum momento, e os módulos do VirtualBox pararam de funcionar.

Instalei todos os módulos possíveis do repositório, mas o VirtualBox se recusava a funcionar. Procuro no Google alguma solução, e não encontro nada, exceto que devo recompilar os módulos. Eu realmente não estava disposto a fazer isso…

Entretanto, pesquisa vai, pesquisa vem, encontrei uma solução melhor. Envolve compilar os módulos também, mas de maneira mais “debiana”.

Para compilar os módulos, primeiro, atualize a referência aos pacotes com os repositorios:

# apt-get update

Agora, atualize os pacotes instalados em sua máquina:

# apt-get upgrade

Feito isso, instale o pacote com o código-fonte dos módulos do VirtualBox:

# apt-get install virtualbox-ose-source

O pulo do gato é utilizar a ferramenta module-assisant para compilar o módulo. Uma vez que o código-fonte do módulo esteja instalado, basta executar:

# m-a a-i virtualbox-ose


O m-a compila o módulo. A opção a-i diz ao module-assistant para instalar os módulos automaticamente.

Voilà! Seus módulos estão funcionando. No máximo, vai precisar carregar os módulos:

# modprobe vboxdrv

Se isso resolver seu problema, agradeça ao Daniel Baumann lá do e-mail. Tudo bem que dizer que tudo isso é óbvio foi exagero dele, mas a ajuda valeu bastante

Osvaldo Santana, o pythonista, postou no seu blog algumas “cagadas computacionais” que cometera. Lembrei-me de um causo interessante…

Meu primeiro emprego foi como servidor público, técnico administrativo na Universidade de Brasília. Era um emprego chato para mim, tecnocrata que sou, mas consegui escapar da chatice convencendo o pessoal a me deixar usar um Debian na minha máquina – na época, um Debian Etch, ainda em testes.

Em casa, eu já usava Debian, mas não tinha conexão com a Internet, de modo que fiquei preso ao Debian Woody, GNOME 1.8 etc. etc. No trabalho, porém, eu tinha uma ótima conexão, então atualizava freqüentemente o sistema operacional. Foi minha primeira experiência mais interativa com o APT: antes, só utilizava para instalar pacotes dos sete CDs do Woody que eu tinha gravado.

Depois de um bom tempo usando Debian, enfrento meu primeiro inferno de dependências. Bem feito, quem mandou misturar testing, unstable e até experimental, né? De qualquer forma, entrei em desespero, porque aquela era minha máquina de trabalho e tinha de funcionar. Bato a cabeça, reinstalo pacote, tiro repositório, dou apt-get update pra cá, apt-get dist-upgrade para lá mas nada se resolve…

No desespero daquela sexta feira, tomo uma decisão drástica: vou desinstalar o APT! Lá vamos nós digitar o inacreditável comando:

apt-get remove apt

O Debian não gostou muito… A mensagem que recebi foi algo como:

AVISO: Os pacotes essenciais a seguir serão removidos.
Isso NÃO deveria ser feito a menos que você saiba exatamente o que você está fazendo!
apt
Depois desta operação, 30,1MB de espaço em disco serão liberados.
Você está prestes a fazer algo potencialmente destrutivo.
Para continuar digite a frase 'Sim, faça o que eu digo!'
?]

Bem, é realmente uma mensagem assustadora. Qualquer pessoa perceberia que desinstalar o APT não era só aparentemente uma idéia sem sentido, era um absurdo estúpido! Mas eu não sou qualquer pessoa! Como sou brasileiro e não aprendo nunca, vou lá e digito:

Sim, faça o que eu digo!

Depois de todo o trabalho sujo feito, vamos tentar reinstalar o APT. Bem, vocês podem imaginar que não, não consegui fazer isso. Quando vi que a opção menos absurda seria recompilar o APT, desisti: fiz backup dos documentos e reinstalei o Debian.

Pelo menos saí do inferno de dependências