Arquivo da tag: kernel

Diagnóstico de Alice

ATENÇÃO: Este conteúdo foi publicado há 8 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

O problema do meu Amazon PC Slim L92 é uma incompatibilidade da sua placa-mãe com seu processador.

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.

Sobre os meus 5²³ problemas com meu laptop

ATENÇÃO: Este conteúdo foi publicado há 8 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

Comprei na Fnac no dia 15 de janeiro deste ano um Amazon PC Slim L92 12” com as seguintes especificações:

  • Processador: Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz
  • Placa-mãe: Compal JFT00 (versão da bios: 1.05A)
  • Disco rígido: Samsung HM250JI (250GB)
  • Memória RAM: 4GB DDR2 SODIMM (dois pentes de 2GB)

O resto é irrelevante para este post, mas pros geeks desocupados deixo aqui o lspci e o lsusb:

root@alice ~ # lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)
00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 03)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 [8086:2843] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f3)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller [8086:2815] (rev 03)
00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller [8086:2829] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 03)
01:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller [11ab:4363] (rev 12)
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)

Compal JFT00

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.

A página que melhor refletiu esse problema foi essa: 64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory (Ubuntu Bug #272530) e talvez também essa.

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.

amazonPC

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.

Funtoo

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 ~core2_32, caprichei nos arquivos de configuração e quando rodei um emerge -DN world surpresa! 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?

Windows Vista = shit

Ó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

Está trabalhando demais? Vou tentar compilar com MAKEOPTS=”-j1″. Porém, mesmo resultado.

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:

fs/reiserfs/dir.c:231: internal compiler error: Segmentation fault

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.

Resignado, ontem enviei e-mails detalhados para quatro assistências técnicas de São Paulo. Acabou o horário comercial há duas horas e nenhuma delas me respondeu.

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.

that-damntechsupportguy

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…

Desenvolvimento livre de drivers de webcam Microdia

ATENÇÃO: Este conteúdo foi publicado há 10 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

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.

Airforce One 14E4:4318

ATENÇÃO: Este conteúdo foi publicado há 11 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

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)

# wget ftp://ftp.support.acer-euro.com/notebook/ferrari_4000/driver/winxp64bit/80211g.zip

(o driver da minha placa, com PCI ID igual e tudo, peguei aqui)

# unzip 80211g.zip
# cd pasta-que-ele-criou
# ls
BCMWL564.SYS  Setup.exe  bcm43xx.cat  bcmwl5.inf
# ndiswrapper -i bcmwl5.inf
installing bcmwl5 ...
forcing parameter IBSSGMode from 0 to 2
# ndiswrapper -a 14E4:4318 bcmwl5
couldn't create symlink for "14E4:4318.5.conf": File exists -
installation may be incomplete
driver 'bcmwl5' is not installed (properly)!
# ndiswrapper -l
bcmwl5 : driver installed
        device (14E4:4318) present

Semana que vem, depois de aprender a configurar, vou testar na casa da Carol, que usa wireless. ;)

Acer Orbicam

ATENÇÃO: Este conteúdo foi publicado há 11 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

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:

 idVendor           0x0c45 Microdia
 idProduct          0x6260
 bcdDevice            1.00
 iManufacturer           0
 iProduct                1 USB20 Camera

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. ;)

udev e suas regras maravilhosas

ATENÇÃO: Este conteúdo foi publicado há 11 anos. Eu talvez nem concorde mais com ele. Se é um post sobre tecnologia, talvez não faça mais sentido. Mantenho neste blog o que escrevo desde os 14 anos por motivos históricos. Leia levando isso em conta.

Participei nos dias 8 e 9 do IV Encontro Nacional Linuxchix Brasil em Florianópolis. O evento teve umas palestras interessantes, entre as quais destaco as do pessoal do FreeBSD, a do Luiz Fernando Capitulino sobre o desenvolvimento do Kernel, a do Hélio Castro sobre interfaces gráficas 3D, mas em especial a do Piter PUNK sobre o udev (talvez porque eu sou um usuário Slackware =). E é sobre o udev que eu resolvi falar nesse artigo…


Tenho até vergonha de dizer que até semana passada eu não tinha percebido que o hotplug não estava mais sendo inicializado no meu Slackware… Só depois da palestra que aprendi que o Kernel 2.6 acaba com a necessidade do hotplug substituindo por um novo e poderoso aplicativo chamado udev. Isso é uma mudança e tanto, que traz alguns prós e contras (na verdade, eu só vi prós).

O que é o udev?

Bom… Segundo a Wikipedia, udev is the device manager for the Linux 2.6 kernel series. Its primary function is managing device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load.

Como funciona o udev

Na inicialização do sistema, o udev vê no /sys que dispositivos foram encontrados pelo Kernel e adiciona os dispositivos ao /dev (por enquanto, vou fingir que ele só adiciona os dispositivos ao /dev).

Depois, seu daemon fica rodando para adicionar novos dispositivos assim que eles aparecerem.

É bem mais rápido que no hotplug e parece funcionar bem.

E onde está a mágica?

O udev possue um diretório de regras (/etc/udev/rules.d) onde adicionamos arquivos de texto com uma sintaxe super fácil para dizer o que queremos fazer com cada dispositivo que é adicionado ao sistema.

E o que queremos fazer com cada dispositivo que é adicionado ao sistema?

Hmmm… Isso depende muito da sua necessidade, mas deixe-me citar algumas possibilidades das regras do udev:

  • Dar nome aos dispositivos – Pra que uma pasta /dev cheia de nomes difíceis que você não entende? Com o udev, você pode chamar seu sda1 de pendrive ou o seu hdc de cdrom.
  • Dar nomes diferentes para dispositivos iguais – Hoje em dia vivemos pluggando pendrives, máquinas digitais, MP3 players, etc. em nossas placas USB. Com o udev, podemos fazer com que a nossa máquina da Canon chame-se /dev/canon, a nossa máquina da Sony chame-se /dev/sony, o pendrive da mamãe chame-se /dev/mamae e o nosso MP3 Player chame-se /dev/mp3player.
  • Adicionar links simbólicos aos dispositivos – Podemos fazer nosso CD-ROM ter vários links como cdrom, dvd, cdrw, cdwriter
  • Mudar permissões dos dispositivos – Podemos fazer com que o pendrive da mamãe possa, logo que for pluggado em qualquer porta USB, ser acessado por ela (e somente por ela).
  • Executar comandos quando ocorrem alterações nos dispositivos – Sempre que a mamãe colocar o seu pendrive numa porta USB podemos montá-lo para ela e já abrir o dispositivo no Konqueror e quando ela pluggar a sua máquina digital da Canon podemos mudar suas permissões, linká-la para /dev/camera e abrir o digiKam.
  • … entre provavelmente muitas outras coisas que eu não me lembro ou não sei fazer (eu só conheço o udev há quatro dias!)

Claro que o udev pode ser útil para servidores também, para trocar hardware ou reiniciar o computador com segurança (ex.: você pode dizer que o HD principal seja sempre /dev/principal e assim mesmo que ele passe a ser o seu Second Slave ele funciona), mas estou focando mais o uso doméstico. A “mamãe” é um usuário leigo que não precisa saber montar dispositivos ou qual o nome do programa que baixa as fotos da máquina. Ela simplesmente plugga a sua máquina e o digiKam abre.

Legal… E como é que eu faço essas regras?

A sintaxe dos arquivos em /etc/udev/rules.d é muito simples. Você simplesmente separa por vírgulas as condições que você quer para que as ações que você quer fazer e as ações.

A máquina fotográfica da mamãe

ACTION=="add", BUS=="usb", SYSFS{product}=="Canon Digital Camera", 
GROUP="camera", MODE="0660", SYMLINK+="camera", RUN:="/bin/su mamae -c 
'/usr/bin/abredigikam.sh'"

Aqui em casa, usei um “abredigikam.sh” assim:

#!/bin/bash
 
export DISPLAY=":0"
/opt/kde/bin/digikam
Sinais do exemplo
  • Os dois iguais (==) são para expressar condição, como no C (e em um monte de linguagens derivadas dele).
  • O “=” atribui
  • O “+=” atribui “mais uma coisa” (append)
  • O “:=” atribui uma coisa como constante (ou seja, neste caso eu ou os scripts de regras da minha distro não conseguem mais mudar o valor do “RUN”).
Variáveis do exemplo
  • ACTION: A ação que está sendo feita com o dispositivo (neste caso é a adição dele – add)
  • BUS: Barramento. Neste caso, a USB.
  • SYSFS: Variáveis específicas deste dispositivo (depois vou mostrar como encontramos elas)
  • GROUP: Grupo em que o dispositivo está.
  • MODE: Permissões do dispositivo.
  • SYMLINK: Links simbólicos para o dispositivo.
  • RUN: Comando Shell para executar.

Não conheço todas as variáveis, mas para saber mais você pode consultar o Writing udev rules (o objetivo desse post não é entrar em detalhes).

udevmonitor

O udevmonitor é um aplicativo que imprime os eventos recebidos pelo Kernel e o evento que o udev manda depois do proessamento de regras em tempo real. Veja o que acontece, por exemplo, quando pluggo uma máquina digital na minha porta USB:

UEVENT[1158086870.385094] add@/devices/pci0000:00/0000:00:02.0/usb1/1-1
UEVENT[1158086870.388950] add@/devices/pci0000:00/0000:00:02.0/usb1/1-1/1-1:1.0
UEVENT[1158086870.389571] add@/class/usb_device/usbdev1.3
UDEV  [1158086870.390983] add@/devices/pci0000:00/0000:00:02.0/usb1/1-1
UDEV  [1158086870.404378] add@/devices/pci0000:00/0000:00:02.0/usb1/1-1/1-1:1.0

É interessante para acompanharmos os dispositivos que são encontrados pelo udev. Veja agora o udevmonitor quando eu despluggo a minha máquina:

UEVENT[1158089965.438657] remove@/devices/pci0000:00/0000:00:02.0/usb1/1-1/1-1:1.0
UEVENT[1158089965.438765] remove@/class/usb_device/usbdev1.3
UEVENT[1158089965.438794] remove@/devices/pci0000:00/0000:00:02.0/usb1/1-1
UDEV  [1158089965.440899] remove@/devices/pci0000:00/0000:00:02.0/usb1/1-1/1-1:1.0
UDEV  [1158089965.443341] remove@/class/usb_device/usbdev1.3
UDEV  [1158089965.444795] remove@/devices/pci0000:00/0000:00:02.0/usb1/1-1

udevinfo

O udevinfo imprime informações sobre um dispositivo. Para descobrir que o SYSFS{product} da minha máquina era Canon Digital Camera foi este comando que eu utilizei, da seguinte maneira:

# udevinfo -q all -n usbdev1.4
P: /class/usb_device/usbdev1.4
N: usbdev1.4
S: bus/usb/1/4

(descobri que ela estava na usbdev1.4 usando o udevmonitor)

Aí agora sabendo o path eu descobri todo o resto: (a saída é grande, use a barra de rolagem)

# udevinfo -a -p /class/usb_device/usbdev1.4
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/class/usb_device/usbdev1.4':
    KERNEL=="usbdev1.4"
    SUBSYSTEM=="usb_device"
    DRIVER==""
    SYSFS{dev}=="189:3"

  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb1/1-1':
    ID=="1-1"
    BUS=="usb"
    DRIVER=="usb"
    SYSFS{configuration}==""
    SYSFS{product}=="Canon Digital Camera"
    SYSFS{manufacturer}=="Canon Inc."
    SYSFS{maxchild}=="0"
    SYSFS{version}==" 1.10"
    SYSFS{devnum}=="4"
    SYSFS{speed}=="12"
    SYSFS{bMaxPacketSize0}=="8"
    SYSFS{bNumConfigurations}=="1"
    SYSFS{bDeviceProtocol}=="00"
    SYSFS{bDeviceSubClass}=="00"
    SYSFS{bDeviceClass}=="00"
    SYSFS{bcdDevice}=="0001"
    SYSFS{idProduct}=="30f9"
    SYSFS{idVendor}=="04a9"
    SYSFS{bMaxPower}=="  2mA"
    SYSFS{bmAttributes}=="c0"
    SYSFS{bConfigurationValue}=="1"
    SYSFS{bNumInterfaces}==" 1"

  looking at parent device '/devices/pci0000:00/0000:00:02.0/usb1':
    ID=="usb1"
    BUS=="usb"
    DRIVER=="usb"
    SYSFS{configuration}==""
    SYSFS{serial}=="0000:00:02.0"
    SYSFS{product}=="OHCI Host Controller"
    SYSFS{manufacturer}=="Linux 2.6.17.11 ohci_hcd"
    SYSFS{maxchild}=="4"
    SYSFS{version}==" 1.10"
    SYSFS{devnum}=="1"
    SYSFS{speed}=="12"
    SYSFS{bMaxPacketSize0}=="64"
    SYSFS{bNumConfigurations}=="1"
    SYSFS{bDeviceProtocol}=="00"
    SYSFS{bDeviceSubClass}=="00"
    SYSFS{bDeviceClass}=="09"
    SYSFS{bcdDevice}=="0206"
    SYSFS{idProduct}=="0000"
    SYSFS{idVendor}=="0000"
    SYSFS{bMaxPower}=="  0mA"
    SYSFS{bmAttributes}=="e0"
    SYSFS{bConfigurationValue}=="1"
    SYSFS{bNumInterfaces}==" 1"

  looking at parent device '/devices/pci0000:00/0000:00:02.0':
    ID=="0000:00:02.0"
    BUS=="pci"
    DRIVER=="ohci_hcd"
    SYSFS{modalias}=="pci:v000010B9d00005237sv0000103Csd00000024bc0Csc03i10"
    SYSFS{local_cpus}=="1"
    SYSFS{irq}=="10"
    SYSFS{class}=="0x0c0310"
    SYSFS{subsystem_device}=="0x0024"
    SYSFS{subsystem_vendor}=="0x103c"
    SYSFS{device}=="0x5237"
    SYSFS{vendor}=="0x10b9"

  looking at parent device '/devices/pci0000:00':
    ID=="pci0000:00"
    BUS==""
    DRIVER==""

Os contras

Hmmm… Na verdade, pelo que eu me lembro da palestra, o udev só tem um contra. Ele vai detectando os dispositivos e jogando-os no /dev na ordem em que ele vai encontrando-os. Então, às vezes a minha placa de rede SiS pode ser detectada como eth0 e a Realtek como eth1 e no outro dia o contrário. Mas contornar isso é muito simples, usando aquelas regras (e inclusive podemos dar os nomes /dev/placa-sis e /dev/placa-realtek para nossas placas). =)

Encontrou um erro?

Eu ainda tô conhecendo o udev (como eu disse, conheci ele nesse final de semana), então meu texto pode ter alguma falha ou pode estar faltando alguma informação. Por favor, comente se encontrar algum erro ou quiser sugerir algo legal… =)

Para mais informações…

$ man udev

… e a página do udev