Tecnologia e non solo

ottobre 24, 2017

La “iattura” kded5…

Filed under: Debian,kde5 — telperion @ 4:07 PM

Sto azz di kded5 è “lammerda”.
Basta fare una ricerca in dolphin con la lente e dopo un po, kded5 quasi sempre inizia a cazzo a consumare cpu.
Se poi lo lasci fare, se cerchi di cancellare un file o svuotare il cestino, dolphin si frezza, e se aspetti troppo ti blocca il sistema.
Come ripararsi da sta secchiata dimmerda?
Ai primi sintomi aprire il terminale
ps ax | grep kded5
1668 ? Sl 0:03 kded5 [kdeinit5]
31134 pts/1 S+ 0:00 grep kded5

poi verificare che kded5 non si andato nello stato “lammerda”
top -p 1668

top - 17:02:52 up 7:05, 2 users, load average: 0,16, 0,30, 0,50
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,2 us, 0,4 sy, 0,0 ni, 99,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 16432376 total, 13151444 free, 1449396 used, 1831536 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 14659620 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1668 mc 20 0 1750760 45208 37280 S 0,0 0,3 0:03.19 kded5

e se la %cpu fosse elevata
kill -9 1668

poi
kded5 &
per rilanciarlo (servirà pure a qualcosa, o no?)

Avete evitato “lammerda” per questa volta.
Ma occhio, kded5 ha sempre il cagotto, quindi vigili.

NOTA:
il solito bontempone commenta cose tipo “il tuo pc è lammerda, a me non crea nessun problema”.
Amico bontempone dipende dall’uso che fai del pc, anche a me se navigo, guardo video, leggo la posta, insomma cazzeggio, il perfido kded5 non infastidisce, ma basta fare cose più avanzate con gimp o ffmpeg e cercare in una cartella da 100GB con migliaia di file ed a kded5 viene il cagotto.
Ed il fatto che cio accada lo rende “lammerda” appunto.
Pensa che, a pc spento, non crasha mai nulla 😉

settembre 23, 2017

Ryzen 1700

Filed under: Debian,hardware — telperion @ 4:45 PM

Con Debian 9 il mio Ryzen R7 1700 aveva qualche piccolo problemino.
Sporadicamente, mentre il pc era in idle, si freezava obbligando al reset, e sporadicamente avevo segfault durante le compilazioni con make -j16
Niente di catastrofico, capitava circa 1 volta a settimana e non andava perso nessun lavoro, ovviamente nel caso di segfault bisognava ricompilare.
Dopo ricerche, con visioni catastofistiche tipo “i Ryzen costruiti prima della settimana xx del 2017 sono fallati e da rendere in rma”, ho trovato alcune indicazioni utili:

Since I added CONFIG_RCU_NOCB_CPU and CONFIG_RCU_NOCB_CPU_ALL and Norandmaps in my kernel of vanilla 4.11.x, I have never seen a freeze …
Thanks for the tip !

effettivamente aggiungendo
CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_ALL=y norandmaps
ai parametri di boot del kernel i problemi sparivano.

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 root=UUID=11771692-d7fa-4854-ad67-badefa904511 ro vga=0x305 ipv6.disable=1 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_ALL=y norandmaps

Compilati poi vari kernel,
con
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_ALL=y

ora ho il 4.12.14
[ 0.000000] Linux version 4.12.14-mc (root@dhcppc1) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Thu Sep 21 15:24:35 CEST 2017
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-mc root=UUID=11771692-d7fa-4854-ad67-badefa904511 ro vga=0x305 ipv6.disable=1 norandmaps quiet

verifica:
mc@dhcppc1:~$ sudo dmesg | grep RCU
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=16.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=16
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-15.

tutto funziona da mesi senza intoppi.

Per chi ne avesse bisogno:
non è necessario ricompilare il kernel se non ne siete capaci, basta aggiungere
CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_ALL=y norandmaps
ai parametri di boot del kernel

CONFIG_RCU_NOCB_CPU_ALL=y probabilmente non ha effetto ma il resto si:

[ 0.000000] Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 root=UUID=11771692-d7fa-4854-ad67-badefa904511 ro vga=0x305 ipv6.disable=1 CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_ALL=y norandmaps

sudo dmesg | grep RCU
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] Build-time adjustment of leaf fanout to 64.
[ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=16.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=16

manca solo
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-15.

rispetto al kernel compilato, ma fa comunque il suo lavoro.

Aggiornamento:
dopo 3 settimane di test norandmaps non è necessario.
Rimosso e tutto funziona.

gennaio 28, 2017

Gimp 2.9.5 git

Filed under: Debian,image-processing — telperion @ 12:50 PM

postimage

Compilato in debian 8 ultimo git di gimp.
Mancano un po di lib, compilate anche quelle in /opt/gimp2.9:
libpng-1.6.26
libmypaint >= 1.3.0
lcms2 >= 2.7
libwep
pango1.0_1.40
libmng-2.0.3
aalib-1.4rc5
LibRaw-0.18.0
babl-git
gegl-git

Compilati anche i plugin fondamentali come gap, gmic non compila più ma quello compilato con la 2.9.4 funziona senza problemi compila di nuovo.
Anche animstack funziona.

Migrati anche i miei plugin python, cambiate le funzioni deprecate, più problematico, workaround perche se prima la selezione era vuota veniva considerata ALL, ora non più generando errori.
Il codice gimp 2.8 funzionate:

new = pdb.gimp_edit_copy(drawable)
floating_sel = pdb.gimp_edit_paste(drawable, False)
pdb.gimp_floating_sel_to_layer(floating_sel)

diventa:

is_empty = pdb.gimp_selection_is_empty(image)
if is_empty:
(TAB) pdb.gimp_selection_all(image)
new = pdb.gimp_edit_copy(drawable)
floating_sel = pdb.gimp_edit_paste(drawable, False)
pdb.gimp_floating_sel_to_layer(floating_sel)

(l’identazione è sminchiata da wp alla faccia del tasto code, code sta minchia)
e tutto funziona.

Anche i livelli inseriti con pdb.gimp_floating_sel_to_layer che prima venivano posizionati al top, ora vengono posizionati diversamente, quindi bisogna prenderne il controllo con drawable = pdb.gimp_image_get_active_drawable(image), altrimenti si ottengo effetti indesiderati del plugin.

Occhio a lavorare con molti livelli in 32 bit che il disco si riempie.
Meglio mettere le cartelle temp e scambio in un’altra partizione.
[EDIT] Purtroppo è un mangia memoria anche con precisione 8 bit rispetto alla versione 2.8.x, con 4GB di ram facile finire in swap (swappiness 15) con relativa bradipizzazione del sistema.

Per i miei usi con i miei plugin è già operativo, forse ancora un po lento rispetto al 2.8.x, ovviamente un marea di plugin/script non funzionano più, ma tanto non li uso mai.
[EDIT] è già operativo ma anche no dopo vari test e con molti livelli (tipo con animstack) il consumo memoria è ABNORME, quindi scartato per ora.

Un passo avanti rispetto alla 2.8?
Boh, la 2.8 è di 5 anni fa, ancora siamo lontani dalla 2.10, nel frattempo la comunita utilizzatori gimp si svuota sempre di più, siti/forum, chiudono o sono un deserto desolato.

gennaio 20, 2017

Debian testing plasma 5.8

Filed under: Debian,kde5 — telperion @ 1:39 PM

postimage

Con il soft freeze di testing, ho iniziato la complessa migrazione a kde/plasma5.

Lo xorg.conf della mia nvidia con 2 schermi separati viene ignorato da kde, quindi xorg impostato con uno schermo solo, e poi lascio fare a xrandr e kscreen2 che impostano 1 schermo con 2 monitor.

Tearing su schermo principale eliminato con /etc/profile.d/tearing.sh
export KWIN_TRIPLE_BUFFER=1

Tearing di kodi su HDMI più problematico risolto poi con un lanciatore ad hoc

__GL_SYNC_DISPLAY_DEVICE="HDMI-0" __GL_YIELD="USLEEP" kodi

Il tutto abbastanza stabile con pochi crash, qualche finestra che si apre nello schermo sbagliato con 2 monitor, aspetto un po piatto e plasmoidi poco configurabili.

debuild binary ora è diventato
debuild -- binary
e altre cosette cambiate.

dicembre 10, 2015

4FFmpeg-8.xxx

Filed under: Debian,python,Sid,Video — telperion @ 12:39 PM

4fff
upload immagini

4fffull2

Nuova versione che ora funziona direttamente con ffmpeg, ffprobe e ffplay.
Funziona solo su linux, non ho scritto le varianti python per altri os.

Praticamente fa tutto quello che fa il mio tool (C++ a riga di comando) e con molte aggiunte, con interfaccia grafica GTK3.
——————————————————————————-
8.222
Classe per i compressori audio, selezione da combobox.
8.216
supporto a recenti modifiche di showvolume
8.215
rimosse le differenze di ratecontrol di libx265, visto che ffmpeg da un po supporta il wrapping -b:v -crf:v.
8.207
x265-params direttamente modificabili da textentry.
param
upload immagini

8.204
Nuova logica gestione video encoder, transizione completata.
8.203
Ordine e pulizia, nomi classi in Camel style nel limite del possibile.
Nuova logica gestione video encoder.

8.196
aggiunto supporto a zscale, ridimensiona ad alta qualità con libzimg, (serve la lib e ffmpeg compilato con --enable-libzimg).
libzimg
host image


8.194
Classi per varie cose.

8.180
Aggiunto supporto a Sox resampler (libsoxr), high-quality audio resampling.

(more…)

settembre 3, 2015

Debian pinning di kde4.

Filed under: Debian,kde4 — telperion @ 12:30 PM

Ecco come ho effettuato da testing, il pinning a jessie dei pacchetti kde.

(more…)

settembre 1, 2015

Debian testing plasma 5

Filed under: Debian,kde5 — telperion @ 12:32 PM

Fresh install, tutto ok il sistema è ottimamente configurato.
I pacchetti del driver nvidia 340 sono rotti, con nouveau il pc scalda come un forno (15C in più di cpu senza far nulla), installati i 352.41 dal file run nvidia, tutto ok.

Plasma 5.
Estetica di default da dimenticare, wallpaper e icone breeze da viaggio in acido, plasmoidi necessari (carico sistema, temperature, traffico di rete) abbastanza brutti, peggio di kde4.
Impostazioni di dolphin ballerine, aggiungi risorsa fa strani effetti, non si possono riordinare le risorse, manca azioni apri terminale qui.
Qualche crash ogni tanto, per non farsi mancare nulla.
Gestione del doppio schermo (DVI + TV HDMI) da incubo.
Accendi il tv e le finestre ed il mouse passano sul hdmi senza ritorno, il pannello resta su DVI, preferenze schermo non porta da nessuna parte.
Delirio.
Se si configura un xorg con schermi separati (nvidia-xserver-settings) come uso io, si stabilizza DVI, ma su HDMI si ottiene uno schermo nero col mouse a crocetta senza alcuna possibiltà di farci girare nulla neppure con export DISPLAY=:0.1 && programma.
Insomma siamo lontanissimi dall’usabilità che non sia navigare e poco più, ma per quello basta un tablet.
Un piccolo passo avanti per gli sviluppatori, un enorme passo indietro per gli utenti, ci riproviamo con plasma 5.5 semmai.

Per ora KDE4 resta dove sta, e per parecchio credo.
Era meglio lasciala in sid sta roba.

agosto 22, 2015

Debian sid aggiornamento agosto 2015 e passaggio a testing.

Filed under: Debian — telperion @ 11:32 am

Tentato l’aggionamento dei pacchetti, un caos inenarrabile.
Passato a testing.

Cambiato
/etc/apt/apt.conf.d/local
#APT::Default-Release "unstable";
APT::Default-Release "testing";
e
/etc/apt/sources.list
/etc/apt/preferences
su testing.

Ora aggiornato gcc (5 base compreso) senza disastri, e buona parte di gnome.
Totem non va:
errore:
(totem:19437): Gdk-ERROR **: The program ‘totem’ received an X Window System error.
This probably reflects a bug in the program.
cambiato
Exec=sh -c 'CLUTTER_BACKEND=x11 totem %U'
edit nel mio caso meglio: (altrimenti certi nomefile non li trova)
Exec=CLUTTER_BACKEND=x11 totem %U
in /usr/share/applications/org.gnome.Totem.desktop

Kde ho PAURA a toccarlo, visto il pasticcio di 4 e 5 che in sid crea un plasma5 totalmente inutilizzabile.

Anche la recente reintroduzione di libav-ffmpeg penso porterà catastrofi con debmultimedia, valeva la pena di usare libav per poi tornare indietro?!
Tanto poi i casini sono nostri …

Che rottura di maroni sti update, non ho più ne tempo ne voglia, preferisco concentrarmi su codifica video, sui miei programmi python, sui filtri complex di ffmpeg, che perdere tempo con il sistema e de…

UPDATE 1:
Anche su testing aggiornando KDE si ottiene un 4 misto a 5 con un sacco di plasmoidi mancanti e senza decoratore di fineste.
OK, bloccato l’attuale kde, per almeno 6 mesi sta come è (che va più che bene). Ho letto che causa passagio a kdef5 e gcc5 c’è un gran casino sia su sid che su testing, alla larga quindi.

dicembre 24, 2014

Debian sid upgrade 23/12

Filed under: Debian,Sid — telperion @ 3:49 PM

Aggiornamento “globale” della mia sid di giugno 2014.
Aggiorno sempre applicazioni e cose che uso, e per evitare problemi solo dopo molti mesi l’intero sistema su una partizione copia.
Processo lunghetto, gtk3.14, kde 4.14.2 e una montagna di altri file (~2GB).
Cosa non funziona.

plasma-nm: con questa nuova impossibile visualizzare/aggiungere connessioni, ho dovuto ripristinare il vecchio file interfaces manuale per poter usare la rete, e ciò è molto male. Rimosso plasma-nm_0.9.3.4-2_amd64, ripristinato plasma-widget-networkmanagement_0.9.0.9-1_amd64, dopo il riavvio, tutto rifunziona come prima.
Soluzione: commentata in /etc/network/interfaces la riga:
#allow-hotplug eth0

Pulseaudio: non partiva, org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct. Soluzione:
mc@debian64:~$ cd /usr/lib/dbus-1.0/
mc@debian64:/usr/lib/dbus-1.0$ sudo chmod 4755 dbus-daemon-launch-helper

Ricerca in dolphin: non va, esce protocollo sconosciuto. Soluzione: Installati baloo4, baloo-utils e kde-config-baloo-advanced, avviata l’incidizzazione, poi fermata e stoppato il sevizio (ciucciarisorse e stressahd a tradimento) ed ora ‘pare’ funzionare.

Deluge: deluge non va più.
Soluzione: usare ktorrent.

Il resto ‘pare’ ok.

Buon Natale.

dicembre 19, 2014

libx265 a che punto siamo?

Filed under: Debian,Video — telperion @ 3:24 PM

ffmpeg e libx265 git del 20141219.
Ecco il test.

x265
image hosting

I risultati visivi, considerando lo stato di continuo sviluppo di x265, tutt’altro che concluso, sono accettabili.
La lentezza della codifica, circa 9.5 frame per secondo nel caso del test, ne limita per ora fortemente l’utilizzo pratico.
Considerato che son finiti i tempi dove ogni anno si cambiava CPU perchè la potenza delle nuove ridicolizzava la generazione precedente, credo che questo sia il vero tallone di Achille per l’uso domestico di questo encoder.

x265 doc

Pagina successiva »