sexta-feira, 30 de março de 2012

Kernel Panic


... don't panic!

Não, ainda não é o dia da toalha! Mas este post trata do pânico do núcleo de um sistema operacional. No Windows, conhecido como "tela azul da morte"... ok, não acontece só no Windows; no Unix também pode existir uma situação de travar o SO (tudo bem... é muito menos frequente e por motivos bem justificados). No Unix chama-se Kernel Panic!

Qualquer SO pode se encontrar em uma situação sem saída e, quando isto acontece, o sistema pode perder dados e entrar em um processo de instabilidade. Então para não perder dados ou danificar mais o SO ele para e espera ser reiniciado. Existe uma rotina, nos sistemas Unix e Linux que se chama panic(); ela exibe uma mensagem no console e grava uma imagem da memória do kernel na situação de emergência para ser depurada (debuged) numa outra ocasião.

Mas o que causa o pânico? Um erro de hardware ou mesmo de software, uma memória corrompida fisicamente ou por algum programa etc. causam uma situação de emergência e o sistema chama a função panic().

O código básico da função é:

 char    *panicstr;

 panic(s)
 char *s;
 {
        panicstr = s;
        update();
        printf("panic: %s\n", s);
        for(;;)
                idle();
 }

O "for(;;;)" é o loop em que o sistema entra para esperar pelo reboot! Antigamente, no Multics, grande parte do código do sistema tinha tratamento de excessões e correção de erros. No Unix, Ken Thompson e Denis Ritchie resolveram de modo mais simples: em caso de erro, emita uma mensagem de "Kernel Panic" e entre em loop. Assim, se houver uma falha de hardware ou mesmo um erro de software que desestabilize o sistema, ele para e emite a mensagem.

Nos kernels atuais, além da mensagem de erro e da parada em loop, o SO faz uma cópia da memória do sistema na hora que ocorre o problema. Esta cópia pode ser gravada em um arquivo para posterior análise e identificação do problema [1].

Apesar de ser uma rotina segura e importante, quando ela acontece em um servidor,  se transforma em um problema. Pode ser desejável ativar uma reinicialização automática. Para isso, basta acrescentar a linha:

kernel.panic = 60

no arquivo /etc/sysctl.conf salvar e reiniciar o processo com "sysctl -p". Isto fará com que o servidor reinicie em 1 minuto após um kernel panic! Se quiser testar podes simular um pânico:

# sync
# echo c > /proc/sysrq-trigger

Note que o 'c' tem que ser minúsculo e use com cuidado. Isto forçará um kernel panic e o computador reiniciará em um minuto, se o arquivo sysctl.conf foi configurado para isso.

OK ... e não esqueça a toalha!



Referências

[1] Novel.Com "Configure kernel core dump capture"
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3374462&sliceId=SAL_Public

segunda-feira, 19 de março de 2012

Kernel 3.3 lançado


... é pra valer, o Kernel Linux 3.3 está na rua!

Anunciado em 18 de março, o novo kernel do Linux está "solto" (released). Com muitas novidades tanto para PCs/laptops, como para smartphones. Eu já havia anunciado algumas novidades do 3.3 em meu artigo anterior em janeiro sobre o assunto. Mas vale a pena um reprise com mais detalhes.

A primeira coisa interessante é a incorporação do código do kernel Android permitindo o boot direto do Android [1]. Finalmente, após um grande período de desentendimentos, as partes se acertaram e vários segmentos do kernel do Android foram incorporados e outros mais serão [2].

Isto tem uma grande importância, principalmente para o futuro really open source dos SOs de tabletes e smarts. Numa disputa (oficial) entre o Android e o iOS, os pequenos (windows, Symbian etc.) vão ter que rebolar para conseguir "um lugar ao sol"... quem ganha? O usuário!

Outra coisa interessante é o suporte à nova arquitetura da Texas Instruments, o TI C6X (C6000, C6-Integra DSP+ARM e DaVinci) que merece um BIG DOUBLE WOW ...

Rodar Linux numa arquitetura orientada à multimídia é uma grande conquista. Além disso, o processador C6-Integra implementa o multicore de DSP e ARM. E, evidentemente, suporta todos os membros da família C64x de processadores DSP multicore da Texas Instruments, capazes de processamento paralelo real de 64 bits, com uma arquitetura VLIW (Very Long Instruction Word) com um set de instruções otimizado para aplicativos DSP. [3,4]

De quebra, temos ainda a capacidade de reperfilar arranjos diferentes de RAID em Btrfs (B-tree file systems, conhecido também pelo apelido de Butter file system) e diversas melhorias em aplicativos de redes. Dentre elas, temos que ressaltar o Open vSwitch [5].

O Open vSwitch adiciona às qualidades de gerenciamento de redes do Linux, mais versatilidade, principalmente num cenário de virtualização de servidores. Por exemplo:

  • Mobilidade de estado a cada rede;
  • Resposta às dinâmicas de rede (balanceamento),
  • Fácil manutenção de tags logicas (switches virtuais distribuidos, p. ex. VMWare, vDS ou Nexus)
  • Integração com hardware direto no kernel

O kernel 3.3 tem, também, mais suporte à criptografia:

  • caam - suporte a variantes MD5;
  • Suporte à verificação de assinatura digital;
  • Bibliotecas de multiprecisão do GnuPG: usado para implementação de RSA digital signature verification, com extensões IMA/EVM;
  • serpent - com assembler paralelo i586/SSE2 e x86_64/SSE2;
  • serpent-sse2 - com suporte a lrw e xts;
  • talitos - com adição de algoritmos hmac;
  • twofish-x86_64-3way - com adição de suporte a xts.

Este novo kernel traz muitas alterações no núcleo principal, com novas melhorias no gerenciamento de memória e paginação mais extensa com um debug mais intenso voltado para resistência a falhas. Os sistemas de arquivo suportados direto no kernel são o Btrfs (b-tree file system), o GFS2 (RH), o FUSE e o NFSD.

Além disso o novo kernel traz mais suporte a novos hardwares com novos drivers; suporte à virtualização com KVM e Xen; e mais ferramentas de segurança e auditoria.

Onde? ...  http://www.kernel.org/

Referências

[1] http://www.muktware.com/news/3273/linux-33-will-let-you-boot-android-greg-kh

[2] Corbet, J. "Bringing Android closer to the mainline", in lwn.net, 20/12/2011, [https://lwn.net/Articles/472984/]último acesso em 19/03/2012.

[3] http://linux-c6x.org

[4] http://processors.wiki.ti.com/index.php/Main_Page

[5] Corbet, J. "Routing Open vSwitch into the mainline", in lwn.net, 30/11/2011, [https://lwn.net/Articles/469775/], acesso em 19/03/2012

Crédito da imagem: http://fc01.deviantart.net/fs71/f/2011/060/3/a/tux_in_android_robot_costume_2_by_whidden-d3aq9k0.png

terça-feira, 6 de março de 2012

Windows 8 beta


... descendooo!

 Deve ser estratégia da Microsoft lançar um "bugado" entre as "distros" mais estáveis. Começou com o Millennium Edition, depois do 98 e antes do XP, depois o Vista, antes do Windows 7 e agora o Windows 8... Este bem-me-quer mal-me-quer já é clássico [1].

Observem que o Windows ME foi lançado porque o o XP não estava pronto. E o caso do Vista para o Windows 7 é o mesmo "lero"! Quem vai cair nessa de Windows 8?

Mas qual a vantagem de lançar um sistema buggy e atrasado? Bem, isto é uma estratégia para a paquidérmica Microsoft: fingir que está apresentando algo novo e pronto. Uma estratégia para fazer os tolos gastarem antes deles corrigirem os bugs e lançarem outra versão mais estável para estes mesmos tolos gastarem de novo. Lembram do caso de upgrade (service pack) do Vista que, na verdade, era um downgrade disfarçado para o XP? Foi vexaminoso. E os caras nem vermelho ficam... mas esta é a idéia!

Quando Bill Gates disse (na apresentação do Windows 95) que todo usuário Windows é um beta-tester da Microsoft. Escreveu: IDIOTA na testa dos consumidores tolos... e com letras garrafais!

Bem, tudo isto é parte da chamada "obsolescência programada" porque para rodar o Windows 8 precisamos de mais memória, mais capacidade de processamento... comprar computadores mais modernos, em suma!

Minha tentativa (frustrada) de instalá-lo no meu "velho" Toshiba (2 GB de RAM e 100 GB de disco, genuine intel dual core) mostra que é preciso muito mais que hardware para rodá-lo... é preciso dinheiro e tolice!

Ser obrigado a investir em novos computadores com hardware mais moderno, tendo ainda um com menos de 2 anos de uso é insano! Não sou contra ganhar dinheiro, aliás, citando meu amigo Jon "Maddog" Hall: "Free software stands for freedom, not for priceless"  (Jon, I don't remember if you told me that or did I read it. Maybe here  or at OpenBeach).

Até os asiáticos estão pedindo à Intel para abaixar os preços [2] ou será difícil desenvolver produtos competitivos no mercado com o Windows 8... não esqueçam: "o buguento Windows 8". Tudo bem... é beta! Mas procurem no Google pelos bugs e ficarão espantados de encontrar bugs na estrutura do sistema operacional... isto me assusta!

A apresentação do Windows 8, por Steven Sinofsky não me convence (no Youtube existem milhares de vídeos sobre o assunto). É sempre a mesma tentativa de mostrar particularidades que existem no Unix há tantos anos como se fosse a maior novidade tecnológica. "Fast and fluid" diz ele, mostrando vários aplicativos rodando ao mesmo tempo... Hallas! Pena que o grande número de usuários que não conhece Unix acha isto a maior loucura! Mas não tente copiar arquivos do Bluetooth e da rede ao mesmo tempo ou verás a lindíssima nova tela azul (Uiii! Ficou tão cute!).

Em sua apresentação [3] ele diz que o Windows 95 inciou uma "generational change" do sistema windows! Hum... com esta fritadeira de HD? Com aquele código do cmd.exe? (veja minha publicação sobre o Windows 7) Vai tentar enganar os trouxas, a mim não! Eu leio Assembly!

"Fast: vai ter um service pack logo!" and "Fluid: Como o dinheiro escorregará das mãos dos consumidores tolos".



Referências:

[1] Dvorak, J. C. "Will Windows 8 Be the Next Vista?", PC Magazine, march, 2012, http://www.pcmag.com/article2/0,2817,2401064,00.asp?utm_medium=referral&utm_source=pulsenews em 04/03/2012.

[2] Bylund, A. "Intel Can't Topple Apple's Portable Stronghold", http://www.dailyfinance.com/2011/09/20/intel-cant-topple-apples-portable-stronghold/ em 06/03/2012.

[3] Reisinger, D. "What Microsoft wants you to think about the Windows 8 beta", http://reviews.cnet.com/8301-13970_7-57387487-78/what-microsoft-wants-you-to-think-about-the-windows-8-beta/ em 04/03/2012.

sexta-feira, 2 de março de 2012

Linux e teclados



um legado complicado...


Não é exatamente a minha praia mas algumas pessoas têm tido problemas com teclados no Linux. O fato é que por ser proprietário de uma SunBlade 2000 com um teclado Sun, já experimentei usar o teclado da Sun em um PC e tive este tipo de problema: basta encostar em uma tecla e o resultado é uma dúzia de caracteres. Assim, vou dar algumas dicas e , embora um pouco off-topic, o assunto está relacionado com o SO.

Trata-se de problemas com teclados específicos e/ou distribuições Linux que necessitam de uma configuração manual. As distribuições modernas não apresentam este problema — bem, pelo menos nunca tentei instalar o Ubuntu num i486, por exemplo.

Este problema acontece porque, durante o boot, o kernel ajusta a velocidade do teclado para o máximo valor (0x0305). Bem, isto não é problema para a maioria dos teclados modernos e nem funciona para teclados USB, mas alguns tipos de teclado respondem "violentamente" a isto. No Linux, o problema pode ser contornado usando o programa kbdrate (veja: man 8 kbdrate) que muda a velocidade de repetição do teclado.

Alternativamente, podes alterar o kernel e recompilá-lo. Mas antes, vamos entender o que e porque.

Em kernels mais antigos, o arquivo:

/usr/src/linux/arch/i386/boot/setup.S

tem um código Assembly para ajustar a taxa de repetição do teclado:

     ! set the keyboard repeat rate to the max

         mov     ax,#0x0305
         xor     bx,bx           ! clear bx
         int     0x16

Nos novos kernels, esta chamada de interrupção está no código do arquivo:

/usr/src/linux/arch/x86/boot/main.c


...

/*
 * Set the keyboard repeat rate to maximum.  Unclear why this
 * is done here; this might be possible to kill off as stale code.
 */
static void keyboard_set_repeat(void)
{
        struct biosregs ireg;
        initregs(&ireg);
        ireg.ax = 0x0305;
        intcall(0x16, &ireg, NULL);
}

...

void main(void)
{

...

        /* Set keyboard repeat rate (why?) */
        keyboard_set_repeat();
...


...


Este código chama a interrupção 16 da BIOS com o valor hexa 0305 no acumulador, ou seja, AH=03 (set keyboard rate) usando o valor 05 (máximo) para o AL. Esta faixa de valor (0-5) pode ser de 02 a 30 caracteres por segundo ou de 02 a 1440 em alguns teclados. E isto pode resultar, em alguns casos, em um teclado hiper-sensível.

A sugestão, de vários desenvolvedores do kernel é alterar ou mesmo retirar esta parte do código e recompilá-lo. Mas porque então não retirá-lo do código (o que já foi até sugerido ao Linus). Bem tudo tem uma explicação, embora o próprio Linus nunca tenha esclarecido.

Primeiro, eu imagino que isto seja um código legado e que é mantido para compatibilidade. Segundo é que, por experiência própria, esta solução pode causar problemas no Accelerated-X que pode ficar instável e demorar para terminar.

Ainda, existem certos hardware (p. ex. Dell Inspiron) que depois da hibernação ajusta a velocidade do teclado para o default, deixando-o mais lento. Neste último caso, pode-se regular a velocidade usando o comando:

$ kbdrate -r 30 -d 250

Isto não aconteceria se o kernel controlasse a interrupção da BIOS.

Embora eu concorde com o comentarista do código ("why this is done here?") é melhor deixar o código onde está. Afinal, quem vai usar um teclado "alienígena" em um computador "Frankenstein" deve saber onde e como alterar o código do kernel.

Happy linuxing!