11:55:20 up 100 days, 0 min, 43 users, load average: 1.22, 0.83, 0.84
Finalmente meu laptop, de uso diário e pessoal, quebrou a barreira dos 100 dias de uptime. E o que isso quer dizer? Nada, e ao mesmo tempo, várias coisas. Mas significa que estou trabalhando sem interrupções por 100 dias.
Fazia tempo que eu não tinha um uptime maior que 30 dias, quanto mais de 100. O problema não era específico, mas um conjunto deles. O que mais afetava o tempo em que a máquina funcionava sem interrupções (leia-se travamentos) era o driver de vídeo Intel. Invariavelmente o Xorg apresentava um crash por conta dos efeitos 3D do KDE com o plasma-desktop. Tentei de tudo, inclusive desabilitar os efeitos e até mesmo parar de usar o KDE, mas o crash de xorg sempre me encontrava.
Contudo vários esforços ocorreram em várias frentes e paralelamente, como sempre acontece no mundo do software livre. A equipe do Xorg melhorou o driver Intel, o KDE, com o lançamento do 4.7, criou uma forma de contornar esse crash, deixando o ambiente plasma muito mais estável e, por fim, a equipe de kernel trabalhou na melhoria do driver framebuffer e DRM pra Intel.
Esse conjunto de melhorias deram um resultado excelente, visível pelo tempo em que o laptop está funcionando sem parar. E olhe que o uso é intenso. Faço desde desenvolvimento de software até apresentações pra clientes, inclusive utilizando 2 monitores (em geral uma televisão). Tive alguns problemas nesse percurso, como uma sobrecarga no xorg, que levou o KDE a cair, mas nada que um reinício do serviço gráfico não pudesse resolver, sem precisar rebootar o laptop.
Em geral tenho trabalhado de forma consistente, fechando e abrindo o laptop, sem reiniciar o trabalho que tinha parado anteriormente. Isso garante um ganho de produtividade muito bom, pois já vejo em que ponto eu estava da última vez e continuo dali pra frente. Nada de reabrir documentos e procurar onde foi a última linha editada, nada de reabrir ambientes de desenvolvimento, nada de reiniciar minhas conexões SSH pra máquinas em que trabalho via VPN, já que faço isso automaticamente via script, que só detectam a queda do link e reiniciam a conexão. Fecho o laptop na sexta-feira e reabro na segunda, como se tivesse parado pra um café.
Então quando se vê um uptime alto, não estamos falando somente de tempo se desligar a máquina mas a produtividade que isso proporciona. Claro que existe um lado egocêntrico de falar no tempo sem desligar ou sem reboot, que vem da cultura de sysadmin, onde o maior uptime significa (ou ao menos significava) um servidor bem ajustado e configurado, mas isso é quase insignificante em relação ao benefício do trabalho ininterrupto.
E você? Já chegou aos 100 dias ou isso ainda é um fardo pra sua produtividade?
Hoje pela manhã (ou quase isso), fui surpreendido pelo mau funcionamento da minha placa de rede cabeada, uma placa gigabit. Não é uma placa que eu tenha escolhido, pois faz parte do notebook, um Sony Vaio VPC-S110GB.
Como a placa não tem led de indicação de funcionamento, eu só consegui identificar que não estava operando pela mensagem abaixo:
root@shibboleet:~# dmesg | grep -i eth
[45263.845838] ADDRCONF(NETDEV_UP): eth0: link is not ready
Após algumas tentativas infrutíferas de colocar e tirar o cabo (acabei até quebro o clipezinho que segura o cabo), dei uma olhada como estava a camada de enlace ethernet.
root@shibboleet:~# mii-tool eth0
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
eth0: negotiated 1000baseT-HD flow-control, link ok
Esse "Input/output error" já me deu uma dica que algo tinha acontecido com o driver da placa. Como estou usando um kernel-pf, e compilado por mim, esse tipo de erro pode mesmo surgir. Claro que existe a possibilidade de ser um defeito da placa, mas prefiro acreditar que o erro é meu, pois esse eu consigo consertar.
Então dei uma olhada na placa de rede.
root@shibboleet:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:be:65:5a:ab
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:4294957164 errors:4294906502 dropped:4294947030 overruns:4294957163 frame:4294967295
TX packets:4294957163 errors:4294926764 dropped:0 overruns:4294957163 carrier:4294967295
collisions:4294916631 txqueuelen:1000
RX bytes:4294957164 (4.2 GB) TX bytes:4294957163 (4.2 GB)
Interrupt:43
É notável a quantidade de colisões na placa, além de erros, que mostram que realmente alguma coisa não estava certa.
Em outros sistemas (nem preciso mencionar), a única solução seria a de... rebootar. Mas como é um Linux, com kernel modular, bastou fazer o seguinte:
root@shibboleet:~# ifconfig eth0 down
root@shibboleet:~# rmmod atl1c
root@shibboleet:~# modprobe atl1c
root@shibboleet:~# ifconfig eth0 up
Em seguinda, testando o meio físico...
root@shibboleet:~# mii-tool eth0
eth0: negotiated 1000baseT-FD flow-control, link ok
E nada de reboot. Nada como usar unix. Pode não ser perfeito, mas também não é windows.
Gosto do jogo UFOAI, de UFO Alien Invasion. É um jogo de estratégia que joguei pela primeira vez nos tempos do DOS e do "Windows 3.11 for Workgroups". Nessa época era um outro jogo, pago, e que se chamava X-Com Unknown Enemy, ou algo assim. Com o avanço dos sistemas, computadores, e jogos, obviamente ficou obsoleto e esquecido. Então alguns fãns resolveram fazer uma versão opensource do jogo, e claro, com esteróides.
O jogo exige OpenGL pra rodar, pois usa massivamente o "quake engine" pra renderizar os ambientes. E é fantástico, e difícil, pois tem uma inteligência artificial aprimorada, que faz com que seus soldados saiam correndo de medo no meio de algumas batalhas.
Fazia tempo que não jogava, mesmo porque jogo mais em console que no PC, mas essa semana resolvi brincar um pouco. Eis que descubro um problema de OpenGL no meu laptop:
helio@shibboleet:~$ ufo +set vid_ref sdl
---- filesystem initialization -----
Adding game dir: /usr/share/games/ufoai/base
Added packfile /usr/share/games/ufoai/base/0base.pk3 (9 files)
Added packfile /usr/share/games/ufoai/base/0maps.pk3 (544 files)
Added packfile /usr/share/games/ufoai/base/0materials.pk3 (45 files)
Added packfile /usr/share/games/ufoai/base/0media.pk3 (10 files)
Added packfile /usr/share/games/ufoai/base/0models.pk3 (2015 files)
Added packfile /usr/share/games/ufoai/base/0music.pk3 (49 files)
Added packfile /usr/share/games/ufoai/base/0pics.pk3 (2114 files)
Added packfile /usr/share/games/ufoai/base/0shaders.pk3 (26 files)
Added packfile /usr/share/games/ufoai/base/0snd.pk3 (266 files)
Added packfile /usr/share/games/ufoai/base/0ufos.pk3 (97 files)
Adding game dir: ./base
Added packfile ./base/0base.pk3 (9 files)
Added packfile ./base/0maps.pk3 (544 files)
Added packfile ./base/0materials.pk3 (45 files)
Added packfile ./base/0media.pk3 (10 files)
Added packfile ./base/0models.pk3 (2015 files)
Added packfile ./base/0music.pk3 (49 files)
Added packfile ./base/0pics.pk3 (2114 files)
Added packfile ./base/0shaders.pk3 (26 files)
Added packfile ./base/0snd.pk3 (266 files)
Added packfile ./base/0ufos.pk3 (97 files)
Adding game dir: /home/helio/.ufoai/2.3.1/base
using /home/helio/.ufoai/2.3.1/base for writing
executing default.cfg
couldn't execute config.cfg
----- network initialization -------
libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3 initialized.
------ server initialization -------
added 7 maps to the mapcycle
----- console initialization -------
Console initialized.
------- video initialization -------
SDL version: 1.2.14
I: desktop depth: 32bpp
I: video memory: 0
I: Available resolutions: 1366x1792 1366x768 1360x768 1024x768 800x600 640x480 (6)
I: video driver: x11
I: setting mode -1
I: set swap control to 0
X Error of failed request: GLXUnsupportedPrivateRequest
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 16 (X_GLXVendorPrivate)
Serial number of failed request: 25
Current serial number in output stream: 26
Tentei forçar o sistema a inicializar sem o uso de OpenGL, com o parâmetro "+set vid_ref sdl", mas nem isso resolveu. Como não existe nada mais sagrado ao homem que seus jogos eletrônicos, resolvi consertar o problema. Ou ao menos tentar.
Não vou escrever sobre vídeos de pornografia ou de pessoas xingando, nada disso. Vou falar de novo dos "padrões Microsoft". Não é de hoje que a Microsoft cria aplicativos não padronizados e que fazem questão de não funcionar em outros sistemas além do Windows.
Num desses dias me deparei com um danado de um arquivo de vídeo, WMV, que não funcionava de jeito nenhum.
helio@shibboleet:tmp$ mplayer sound_of_music.wmv
mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing sound_of_music.wmv.
ASF file format detected.
[asfheader] Video stream found, -vid 1
[asfheader] Audio stream found, -aid 2
VIDEO: [WMV3] 352x264 24bpp 1000.000 fps 336.0 kbps (41.0 kbyte/s)
Load subtitles in ./
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: Permission denied.
[VO_3DFX] Unable to open /dev/3dfx.
NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [dmo] DMO video codecs
DMO dll supports VO Optimizations 0 1
DMO dll might use previous sample when requested
MPlayer interrupted by signal 11 in module: init_video_codec
Não é a primeira vez que pego desses arquivos WMV que morrem com essa mensagem "MPlayer interr'upted by signal 11 in module: init_video_codec". Aliás o sinal 11 de saída significa, de acordo com o /usr/include/asm-generic/errno-base.h":
#define EPERM 1 /* Operation not permitted */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* Interrupted system call */
#define EIO 5 /* I/O error */
#define ENXIO 6 /* No such device or address */
#define E2BIG 7 /* Argument list too long */
#define ENOEXEC 8 /* Exec format error */
#define EBADF 9 /* Bad file number */
#define ECHILD 10 /* No child processes */
#define EAGAIN 11 /* Try again */
#define ENOMEM 12 /* Out of memory */
#define EACCES 13 /* Permission denied */
#define EFAULT 14 /* Bad address */
o que não quer dizer nada para mim. Aliás quem criou esse código de erro de saída tava trollando, com certeza.
Mas voltando ao vídeo, que eu queria assistir de qualquer jeito, consegui resolver depois de um Googlada profunda. Foi difícil achar referências, mas encontrei um alternativa pra assistir o vídeo, lá no launchpad. Estava no bug descrito como "mplayer crashes opening wmv files encoded with DMO codec".
A solução foi usar o parâmetro "-vc ffwmv3". Com isso pude assistir ao vídeo que fizeram durante a Mobile World Congress, em Barcelona. Muito bonitinho por sinal.
helio@shibboleet:tmp$ mplayer -vc ffwmv3 sound_of_music.wmv
mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
MPlayer SVN-r33713-4.6.1 (C) 2000-2011 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
Playing sound_of_music.wmv.
ASF file format detected.
[asfheader] Video stream found, -vid 1
[asfheader] Audio stream found, -aid 2
VIDEO: [WMV3] 352x264 24bpp 1000.000 fps 336.0 kbps (41.0 kbyte/s)
Load subtitles in ./
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: Permission denied.
[VO_3DFX] Unable to open /dev/3dfx.
NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Forced video codec: ffwmv3
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 61
Unsupported PixelFormat 53
[wmv3 @ 0xb657c180]Extra data: 8 bits left, value: 0
Selected video codec: [ffwmv3] vfm: ffmpeg (FFmpeg WMV3/WMV9)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8003->176400)
Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))
==========================================================================
AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 352x264 => 352x264 Planar YV12
A: 7.2 V: 7.2 A-V: -0.000 ct: -0.046 108/108 9% 1% 0.3% 4 0
Nota: Antes que perguntem, não posso publicar o vídeo. Não é nada de tão sério ou secreto, mas uma vez que envolve a marca da empresa e foi feito por outras pessoas, eu preciso que elas primeiro publiquem no Youtube, ou algum outro site, pra depois publicar aqui. E não vou pagar nada pro ECAD.
Não tem nada mais chato que sistema lento. Atualmente não dá pra aguentar um sistema que fica cortando a música que se está ouvindo só porque o Firefox consumiu 2 GB de memória, a máquina virtual no VirtualBox tá com mais 2 GB alocados e ainda tá compilando um kernel.
Pois é exatamente o que tem acontecido e muito em Linux. Não sei de outras distribuições, mas especificamente em Ubuntu.
Como os patches de tempo real foram incluídos na árvore principal do kernel já faz algum tempo, isso deveria estar bem mais amenizado. Fui em busca de informação sobre como ativar tal função e encontrei o comando "chrt" (change realtime talvez).
Lendo o manual do chrt, é possível ver uma gama de opções sem muitas explicações, nem comparativos de resultados. Isso não ajuda muito na ampla adoção do mesmo. Eu acabei fazendo alguns experimentos tanto em Intel 32 bits quanto em 64 e consegui um resultado supreendemente bom e bem fácil. Apenas adicionei prioridade de tempo real ao processo init.
chrt -r -p 1 1
Esse comando adiciona a política de escalonamento SCHED_RR ao processo ID 1 (init) com prioridade 1.
A política default do init é SCHED_OTHER, que de acordo com manual - SCHED_SETSCHEDULER(2) - significa:
SCHED_OTHER política padrão de round-robin baseado em compartilhamento de tempo
SCHED_RR política round-robin
Olhando mais a fundo o manual do escalonador, é possível ver que somente o SCHED_RR ativa a funcionalidade de tempo real.
Então basta adicionar esse comando no "/etc/rc.local" do Ubuntu/Debian para ter um sistema sem problemas de "travadinhas" quando sobrecarregado. Eu fiquei mesmo surpreso em como foi fácil melhorar o desempenho do sistema e como isso não é incluído por padrão nos sistemas.
