Eu tenho uma placa de vídeo relativamente antiga: NVIDIA GTX 1050ti. Ela tem servido bem pro que preciso, mas deixa pra trás em alguns quesitos como rodar algum modelo mais complexo pelo ollama. Mas complexo? Nem os mais simples têm rodado. Porém o meu maior uso é renderizar os vídeos das pedaladas. Já escrevi o processo que faço aqui: Renderizando as fotos da GoPro em vídeo mpeg4 com ffmpeg e NVIDIA.
O problema surgiu quando a NVIDIA anunciou que abandonaria o suporte pra essa placa. A solução? Parar de usar o pacote do próprio archlinux e passar a usar um do AUR. Até aí, sem grandes problemas. Archlinux é feito pra esse tipo de coisa. O problema foi que eu usava o pacote ffmpeg-cuda e esse parou de receber updates.
A primeira solução que tentei foi fazer o build do pacote ffmpeg-full-git. Depois de trocentas horas compilando, erro. E não consegui resolver.
Então parti pra uma solução própria: peguei o pacote do ffmpeg-full-git, removi boa parte do que precisa pra compilar, olhei o que tinha no ffmpeg-cuda e... voilá! Pacote compilado.
E subi a solução toda pro codeberg, caso alguém também precise.
https://codeberg.org/helioloureiro/archlinux-ffmpeg-cuda
Eu vou precisar manter atualizado em algum momento. Mas depois descubro como farei isso. Um problema de cada vez.
Eu já fazia um tempo que um dos meus HDDs no desktop tava fazendo barulho de que estava estourando pipocas dentro. E dando algumas mensagens de erro como essas aqui:
[ xx.xxxxxx] ata2.00: revalidation failed (errno=-5)
[ xx.xxxxxx] ata2.00: revalidation failed (errno=-5)
E pra minha infelicidade era justamente o HDD novo de 8 TB que tinha comprado. E atualmente não é uma época auspiciosa pra pensar em gastar em computador, com os preços duplicando de valor pra memórias e discos.
Mas dando uma buscada na Internet, encontrei o seguinte link:
Então apliquei os parâmetros irqpoll all_generic_ide em /boot/default/grub, gerei uma configuração nova e rebootei. E realmente resolveu a parada.
Segundo o link https://www.kernel.org/doc/html/v4.16/admin-guide/kernel-parameters.html :
When an interrupt is not handled search all handlers for it. Also check all handlers each timer interrupt. Intended to get systems with badly broken firmware running.
Ou seja, tava dando alguma zica de interrupção e aparentemente por conta de firmware zoado.
E aqui segue a minha última dica desse ano. Pelo menos escrita do laptop de trabalho, uma vez que sempre dedico algumas horas pra escrever artigos nas sextas-feiras nele.
Tem algumas situações que meu terminal para de funcionar o ctrl-c.
Treco chato pra caramba.
Você conecta numa máquina remota, roda um journalctl e... fica preso.
Qualquer outro comando como ping também te trava.
E eu não sei exatamente em que situação isso ocorre.
Mas eu não rebooto meu laptop com muita frequência.
Fico com uns 10 terminais abertos, alguns no konsole, outros no yakuake.
Não sei se foram terminais que eu estava rodando algo como htop ou mesmo tmux.
Como diria Chicó: não sei, só sei que foi assim.
E tentei de tudo pra recuperar o ctrl-c: reset, recofigurar o fish pra
entender terminal_break, etc.
Tudo quanto era receita exotérica eu tentei.
E continuei não sabendo exatamente como arrumar além de fechar o terminal e abrir outro.
Até que um dia buscado na Internet achei uma dica que fez voltar o ctrl-c:
stty sane
Simples assim. Todo o sofrimento acabou. Esse comando reconfigura o terminal com parâmetros... sei lá. Mais sãos? O importante é que funciona.
E a luta continua. Agora com 4 placas NVIDIA instaladas, a configuração foi ajustada pra tudo funcionar corretamente.
E tenho que agradecer totalmente ao DevOps Engineer anterior, Peter, que fez esse trabalho todo. Sem ele eu ainda estaria pastando com a configuração da BIOS.
O que foi alterado está na tabela abaixo:
| BIOS | Estado | Nota |
| SVM Mode | Enabled | CPU Virtualization |
| BME DMS/A Mitigation | Enabled | |
| Launch CSM | Enabled | |
| Boot from Network | Disabled | |
| Boot from Storage Devices | UEFI Only | |
| Above 4G Decoding | Enabled | |
| Re-Size BAR Support | Disabled | |
| SR-IOV | Enabled | PCI Virtualization |
| SPCIX16_1 | GEN 3 | Importante |
| SPCIX16_2 | GEN 3 | Importante |
| SPCIX16_3 | GEN 3 | Importante |
| SPCIX16_4 | GEN 3 | Importante |
| SPCIX16_5 | GEN 3 | Importante |
| SPCIX16_6 | GEN 3 | Importante |
| SPCIX16_7 | GEN 3 | Importante |
| WIFI 6 | Disabled | Economizar pros IMMOU Groups |
| Bluetooth Controller | Disabled | Economizar pros IMMOU Groups |
| HD Audio Controller | Disabled | Economizar pros IMMOU Groups |
Com essa configuração eu pude remover o parâmetro pci=nommconf do grub e ter o sistema funcionando.
Por enquanto tudo está rodando redondinho na máquina.
E eu acabei desmontando e invertendo os lados da fonte pra ficar mais fácil de operar. Deixei do mesmo lado da entrada de I/O como cabos de rede, USB, etc.
Apesar da configuração pra todas as entradas EISA/PCI, estamos usando só as ímpares: 1, 3, 5 e 7.
Recebi a missão de montar uma máquina que será usada pra AI na firma. Na foto ainda está o esqueleto dela, que também montei. E com somente uma fonte.
Era o teste pra ver se ligava. E ligou.
Ontem fui instalar o sistema operacional, que será Ubuntu, e... cadê o nvme? Passei algum tempo pesquisando até que achei que é algo com a mother board, a ASUS Pro WS WRX80E-SAGE SE WIFI. O artigo que ajudou foi esse aqui:
tl;dr: é preciso passar o parâmetro pci=nommconf no boot pro kernel achar o nvme.
Quando estiver montada, provavelmente com metade das placas nvidia porque só recebemos 2 das 4 compradas, faço outro post com a foto e mais alguns dados.
