Fontes afirmam que testes realizados na Amazon PC revelaram que trocando o meu processador (Merom T5750) por um Penryn T8100 (US$ 230 nos EUA) ou T9300 (US$ 350 nos EUA) não há mais problema pra usar o computador com 4GB de memória RAM e um sistema operacional de 64 bits.
É evidente que a culpa originalmente não era da Amazon PC, mas da Compal, que foi capaz de fabricar e vender um laptop com processador incompatível com a placa-mãe. Porém, a Amazon PC não só não testou suficientemente o produto, como sua política de solução do problema foi escondê-lo aplicando este hack no software.
Exijo que a Amazon PC reverta a sua política de esconder o problema assumindo a culpa e consertando ou trocando o meu laptop por um com configuração igual ou superior, pois foi ela que me vendeu o produto e ela que me deve a garantia (ora, se vender laptops fosse só comprar de fora e colocar um preço eu também venderia laptops). Sugiro ainda ao pessoal da Amazon PC que eles reclamem e peçam indenização da Compal, mas isso já está fora da minha jurisdição.
Informo a todos os leitores que tomarei todas as providências que estiverem ao meu alcance pra que isto aconteça e que atualizarei este blog quando houver novas informações sobre o caso.
[update 27/ago/2009] O pessoal do Fórum Clube do Hardware afirma que a Intelbras resolveu o problema trocando por Penryn T6400. Este é melhor porque é mais barato que os sugeridos pela Amazon. Estou convencido que qualquer Penryn resolve o problema.
root@alice ~ # lsusb
Bus 002 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 04f2:b052 Chicony Electronics Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 147e:2016
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Alice (é o nome do laptop) veio com Windows Vista 64 bits e a primeira coisa que notei nela foi um estranho desligamento do nada (no seu primeiro dia de vida), antes mesmo de eu instalar Linux! (ou seja, nos seus primeiros minutos, pois obviamente a primeira coisa a fazer quando se recebe um computador com Windows é instalar um Linux)
Pensei ser problema do sistema operacional e não dei bola. Mas aí a coisa ficou estranha: coloquei um CD minimal do Gentoo amd64 e quando ele iniciava o computador desligava do nada.
Para não precisar resolver o problema na hora, instalei um Ubuntu 32 bits (que, estranhamente, não desligava) e entrei na internet para pesquisar.
Como o laptop estava com lacres de garantia, ao invés de abrir e tirar 2GB de memória pra testar levei-a até a divisa entre Florianópolis e São José (um local lá perto de onde o Peterson vive) para a Wil Informática, única autorizada da Amazon PC na região.
Lá chegando o cara do suporte falou que tinha outros laptops da Amazon dando problema e que podia ser devido aos 4GB de memória. Trocou os pentes e pensou que funcionaria. Funcionou por alguns minutos na mão dele. Chegando em casa notei que o problema continuava e, como não tinha mais lacres, tirei um pente.
O laptop com 2GB de memória RAM não teve problema algum. Instalei Gentoo, pesquisei mais um pouco e encontrei a opção mem=4000M que deveria passar para o Kernel só reconhecer 3 e com isso funcionar com 64 bits.
Continuei pesquisando, entrei em contato com a Amazon (que não ajudou em nada a não ser sugerir algo equivalente a mem=4000M pra Windows) e troquei e-mails com o Wil (que prometeu passar minha queixa para a Amazon trocar minha placa-mãe e desde 9 de fevereiro não me respondeu). No fim, não tive opção senão ficar com o laptop e, como ele não dava problemas com 3GB, resolvi deixar pra lá.
Há cerca de dois meses, porém, o laptop começou a apresentar outro problema. De vez em quando (quando eu fazia-o processar muito), ele desligava do nada. Quem tem noção de como é o Gentoo sabe que fazer o computador processar muito faz parte do dia-a-dia.
Estranhando o comportamento, mas atribuindo-o a eu estar usando versões bleeding edge (hard masked) de Kernel, GCC & etc, resolvi usar um Ubuntu 32 bits por um tempo até ter disponibilidade pra reinstalar um Gentoo com carinho.
Nos primeiros dias de Ubuntu ele travava com frequência, mas acreditei que fosse por culpa da placa de vídeo (tinha duas opções no Ubuntu: usava Compiz — blacklisted pa minha placa de vídeo — ou tinha um lag infernal pra trocar de área de trabalho no Gnome. Fiquei com a primeira), então não dei bola. Curiosamente os problemas cessaram e continuei usando o Ubuntu [razoavelmente-]feliz por mais algum tempo. De vez em quando o computador desligava quando eu fazia operações bastante pesadas e eu estranhava, mas pensava que era coincidência.
Nesse fim de semana ouvi falar do Funtoo e, mesmo com a agenda cheia, resolvi parar de usar Ubuntu de uma vez e fazer a Alice voltar a ter um sistema firme e forte. Baixei o stage 3 do <a href”http://dev.funtoo.org/linux/~funtoo/core2\_32/”>~core2\_32, caprichei nos arquivos de configuração e quando rodei um emerge -DN worldsurpresa! O laptop desligou.
Superaquecimento? Podia ser, o cooler fazia um barulho desumano, embora o tempo em São Paulo fosse muito frio. O ACPI não me ajudava, porque a temperatura da thermal zone ficava oscilando entre 42, 55, 63, 68, 73 e 79 graus celsius o tempo todo, assim como o barulho do cooler.
Deixei-a desligada por um dia, coloquei-a com as pontas apoiadas em livro, super ventilada, e fui compilar o Gentoo. Novamente, o laptop desligou.
Só pode ser o problema da BIOS, pensei. Vou ver se tem uma versão nova… E não é que tem?
Ótimo, sofro um pouco mas instalo o Vista, atualizo a BIOS e depois isso vai estar corrigido. Alterei minha tabela de partições, criei uma partição primária especialmente pro Windows (porque sei que ele é chato com isso), iniciei com enorme desgosto a instalação do Vista e depois de digitar a product key mais de uma vez cheguei a conclusão que não ia conseguir instalá-lo. E depois ainda dizem que Linux é que é difícil…
Bom… Vou tentar instalar o Gentoo 64 bits, afinal ele já tinha funcionado no início do ano. Baixei e queimei um system rescue cd, o stage 3 do ~core2 e fui à luta. Resultado: desligamento sempre que tentava compilar alguma coisa pesada. Notava uma mensagem estranha muitas vezes: gcc internal compiler error
Resolvi voltar lá, configurei o Kernel e fui compilar. Em vários pontos dava essa segmentation fault (eu ia retirando as partes que davam esse erro), um deles (o último que eu anotei, aí resolvi desistir) foi no reiserfs:
Pensei que só podia ser porque estava usando versões de Kernel e GCC muito novas, potencialmente instáveis (2.6.30-gentoo-r5 e 4.4). Mas por via das dúvidas resolvi procurar na internet. Eis o que encontrei:
- Random segfaults during compilation. These are signalled by compilation
failing at undetermined points. Often trying to recompile will succesfully
compile the file it was complaining about, but will fail for another. This is
in general a sign of hardware problems.
...
There are multiple causes that can cause the above symptoms:
- Flaky hardware. This is showstopper number one. The cause can be either:
- Insufficient power supply. To detect this try to unplug as many auxiliary
devices (like cd-players, usb devices, etc.) as possible and see whether
the problem persists
- Overclocked memory or CPU's can show random anomalous behaviour. Worse some
hardware has these problems even at "factory speed". Lowering the clockspeed
would be the solution to this problems
- Overheated CPU's. CPU's have several calculation units which have a specific
location on the chip. Compilation tends to intensively use a few of those
units. This can cause heat problems within these units even when the overall
chip temperature is within limits. If overheating is a problem a better cpu
cooler often works. (Underclocking also works as heat increases with
frequency)
- Broken chipsets. There are some chipsets on motherboards which are broken.
sometimes the os (read linux kernel) can work around some of these bugs,
sometimes the only solution is a new motherboard.
Resolvi ainda testar o Funtoo estável pra desencargo de consciência, mas dessa vez o system rescue cd não bootou!!! Suponho então Broken chipset ou overclocked memory or CPU. Qual dessas? Apostaria na primeira, mas de fato não faço muita ideia, porque não entendo nada de hardware.
Minha grande dificuldade é explicar isso pras assistências técnicas que, em geral, são compostas por pessoas que não entendem nada de Linux, nada de compilação e não compreendem nem mesmo o problema que tenho. Não que a última seja fácil, nem eu entendo esse problema (mas eu pelo menos sei que há algo errado). Elas testam deixando o computador ligado por algumas horas e, notando que ele não desliga, pensam que está tudo normal.
Creio inclusive que há outros Compal JFT00 (a Intelbras produziu vários desses, além da Amazon) com o mesmo defeito, mas usuários comuns de computador nem devem notar.
Solução? Amanhã telefonarei pra Amazon e incomodarei eles até eles consertarem Alice de vez ou me prometerem um laptop novo. Por sorte Alice ainda está na garantia, que vai até janeiro de 2010. Espero que até lá eu já tenha resolvido tudo isso…
Como alguns de meus leitores já sabem, meu laptop (Acer Aspire 5050-3205) possui uma Acer Orbicam sem suporte no Linux (tanto com gspcav, quanto com linux-uvc), identificada pelo lsusb como 0c45:6260 (vendor: Microdia).
Além da minha, existem várias webcams desse tipo sem suporte pelo Kernel: 0c45:6027, 0c45:608f, 0c45:60ec, 0c45:60fe, 0c45:60c0, 0c45:613b, 0c45:613c, 0c45:624e, 0c45:624f, 0c45:6242, 0c45:6253, 0c45:6260, 0c45:6270, 0c45:627b, 0c45:8105.
Na lista microdia, surgiu uma iniciativa que pode mudar essa realidade: usando USB sniffs dos drivers de Windows, começamos a desenvolver drivers para webcams Microdia (repositório git).
Gostaria de convidar a comunidade brasileira usuária de Linux que tem webcam Microdia (0c45:XXXX) a também participar, compartilhando as informações de sua câmera para ajudar no desenvolvimento. Quem se interessar, favor entrar na lista ou entrar em contato comigo para mais informações.
Nunca mexi com wireless. Nunca mexi com ndiswrapper. O mais legal é que eu nem mesmo tenho nem uma antena de wireless aqui perto pra “testar” alguma coisa.
Para configurar o adaptador wireless do Acer Aspire 5050-3205, que o lspci reconhece como:
Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
… eu tentei fazer o que Morimoto ensina nesse artigo, só que com Gentoo, 64bits e nada de gráficos do Kurumin tive que adivinhar algumas coisas. Não sei se funcionou o reconhecimento do driver, porque não sei configurar wireless.
O que eu fiz foi:
# emerge ndiswrapper
(pra instalar esse negócio que vai “emular” um driver de windows)
Agora que já estou com o Acer Aspire 5050-3205 quase totalmente configurado com Gentoo, estou resolvendo os últimos problemas de hardware, que creio que são os mais difíceis: wireless e webcam.
Estou conseguindo gravar DVDs, usar ponto de interrogação (eba!) = AltGr+W, o som hda-intel já está funcionando (embora eu não consiga salvar as configurações entre as sessões – alsactl store/restore), estou a 1280×800 usando drivers proprietários da ATI e chegando a 1600fps com a ATI Radeon Xpress 1100. O sistema está quase redondo e bem rápido.
Acabei de entrar em contato com o Michel Xhaard, doutor francês responsável pelo GSPCA, que é o driver que suporta as câmeras no Linux. A câmera do Acer Aspire 5050-3205 no lsusb -v é reconhecida como:
Na resposta do e-mail que eu mandei pra ele (e que ele respondeu em menos de meia hora, achei super legal!), ele disse que isso é igual uma Sonix USB2.0 sn9c201+Ov7670. O GSPCA ainda não a suporta, mas segundo o Michel, ele deve suportar em breve. Então, se você tem uma câmera embutida da Acer como a minha, o lance é ficar ligado e esperar pelo “sn9c20x” na lista de drivers suportados. ;)