Ryzen 1700

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.

Nvidia 304.22 con dkms integrato

Uploaded with ImageShack.us

Con il nuovo pacchetto binario Nvidia (beta), oltre alla correzione di bug e nuove caratteristiche, è stato integrato il meccanismo dkms, che in caso di installazione di un nuovo kernel, ricompila automaticamente il modulo.

Tutti i dettagli:
www.nvidia.com/object/linux-display-amd64-304.22-driver.html

Ovviamente in caso di aggiornamento di xerver-core e mesa, è sempre necessario reinstallare il driver per la sovrascrittura dei link delle LibGL.

xserver-xorg-core 1.11.x Debian Sid e Nvidia.

Lo sviluppatore dei driver proprietari nvidia dice:

Unfortunately, there was a change to a data structure without a corresponding change to the extension module ABI version that breaks GLX. It’s not exactly clear whether this structure counts as part of the extension ABI, so I need to get to the bottom of that before a driver with official xserver 1.11 support can be released. It may be that we need to skip xserver 1.11.0 if my hunch is correct and this is a bug in the X server.

Fonte.

Tutta la discussione.

Ergo meglio NON aggiornare xserver-xorg-core e compagnia bella, e restare alla versione 1.10.4-1, in attesa di soluzioni, tanto non cambia una emerita cippa, come per ogni aggiornamento di xorg da molte versioni a questa parte.

PS:
occhio anche su Archlinux.

Il consumo del kernel? Aumenta.

Almeno secondo il sempre dettagliato articolo di Phoronix:
Linux 3.1 Kernel Draws More Power With Another Regression

Io non ho portatili e me la rido.
E voi?

Gnome 3 e driver Nvidia

Con mutter, le prestazioni migliori dei driver Nvidia, si ottengono con queste impostazioni:

Uploaded with ImageShack.us

Lo spostamento delle finestre diventa molto fluido, e niente corruzioni nelle immagini catturate.

Per caricare le impostazioni all’avvio con
gnome-session-properties
aggiungete una voce con
nvidia-settings --load-config-only
come comando.

EXT4: terrorismo mediatico?

Rispondo alle accuse di presunto terrorismo mediatico contro ext4, e sulla presunta inesistenza dei problemi di ext4,
riproponendo come articolo, un mio commento in EXT4 continua il calvario, perchè abbia la giusta visibilità.

Perchè fare una patch, inclusa nel kernel 2.6.32 che recita testualmente:

“ext4: fix cache flush in ext4_sync_file

We need to flush the write cache unconditionally in ->fsync, otherwise
writes into already allocated blocks can get lost. Writes into fully
allocated files are very common when using disk images for
virtualization, and without this fix can easily lose data after
an fdatasync, which is the typical implementation for a cache flush on
the virtual drive.”

fonte: git kernel org

e che chiaramente dice che
“otherwise writes into already allocated blocks can get lost”
“without this fix can easily lose data after an fdatasync”

se NON ESISTE ALCUN PROBLEMA DI PERDITA DATI?

Altro tipico esempio di “already allocated blocks” sono oltre ai dischi virtuali, tutti i file scaricati da programmi p2p dove viene allocata l’intera dimensione e poi riempita man mano che i dati vengono ricevuti.

(cit.) Quindi mi chiedo, perché continuare a fare terrorismo mediatico contro ext4 se non si sa nulla di concreto?

Io non faccio alcun terrorismo, cito le fonti dirette e CONCRETE a differenza di chi sostiene tesi contrarie senza citare NULLA di autorevole a supporto.

Ora la situazione attuale di EXT4 è questa:

senza patch veloce ma possibili perdite di dati in scrittura su blocchi già allocati,
con la patch niente perdite dati ma forte decadimento delle prestazioni ben evidenziato dai test phoronix.

(cit) http://tinyurl.com/ydzqggo
The performance of PostgreSQL in Lucid is absolutely slaughtered when compared to Ubuntu 9.10. In Ubuntu 9.10 it averaged 1910 transactions per second, but with Ubuntu 10.04 LTS right now it is at 114 TPS. However, it is to no surprise and will likely not change. Thanks to our ability to autonomously find performance regressions in the Linux kernel (and you can too with the Phoronix Test Suite), in that same article we pointed out the change that is causing EXT4 in PostgreSQL and some other applications to be much slower in Linux 2.6.32 kernel compared to earlier releases bearing this popular Linux file-system. It was a very simple commit approved by Red Hat that improves the reliability of EXT4 with its default options, but it comes at a severe performance cost for many operations due to flushing the write cache unconditionally in fsync calls.

Qui i nuovi test dei vari filesystem con EXT4 azzoppato dal kernel 2.6.32 che va “peggio” di ext3 (segnalati da sober).

Tutto ciò è figlio del peccato originale di Ext4 con la conseguente diatriba tra lo sviluppatore e gli altri che sviluppano applicazioni, su come vadano scritti correttamente i dati su disco dalle applicazioni (riassunta per brevità qui se vi interessa).

Su chi ha ragione in questa diatriba tra sviluppatori non mi pronuncio, ma chiaramente il “sonno della ragione genera mostri”.

In conclusione, fede equivale a “credere” incondizionatamente, ma io sono agnostico e credo solo nella scienza che è fatta di teorie e dimostrazioni ripetibili, e sono stufo di leggere affermazioni o accuse bastate sul nulla cosmico eccepite alle mie considerazioni, basate invece, perlomeno nel caso specifico, su cose ben documentate e riportate in originale.

EXT4 continua il calvario.

Non c’è pace per il nuovo filesystem.
Dopo i vari problemi di possibile perdita di dati, forse risolti, forse no, il tutto è molto ambiguo, con il nuovo kernel 2.6.32 le prestazioni, unico motivo per preferirlo al lento ext3, sono crollate.

L’entità della regressione è preoccupante, qui gli articoli di Phoronix:

http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1

http://www.phoronix.com/scan.php?page=article&item=linux_2632_benchmarks&num=1

http://www.phoronix.com/scan.php?page=article&item=ubuntu_1004_alpha1&num=1

Questo il commit che genera la regressione, come dire rendiamo sicuri i dati, sopratutto nei dischi virtuali (ancora un altro problema?) ma al costo di un fortissimo rallentamento in scrittura.

Uhm, a questo punto tanto vale tornare al vecchio ext3 allora, almeno sicuramente è “sicuro” …

Che dire, se usate ext4 state lontani da questo kernel, a meno che non risolva gravi problemi con il vostro hardware.

Ext4 sembra nato sotto una cattiva stella.
Peccato perchè sicurezza dei dati e prestazioni, sono fortemente dipendenti dal filesystem usato.

Ora abbiamo:
ext3 sicuro ma lento, ext4 con kernel < 2.6.32 veloce ma potenzialmente insicuro, ext4 con kernel 2.6.32 sicuro (forse) ma lento come o più di ext3 …

Le conclusioni le lascio a voi,
io sto col 2.6.31 ed ext4 accollandomi il "rischio".

Non c’è pace tra gli ulivi

Velocità in lettura dei dischi.

Rilevata con
sudo hdparm -Tt /dev/sdX

HD Sata2 7200 rpm 1TB
/dev/sdc:
Timing cached reads: 2670 MB in 2.00 seconds = 1335.00 MB/sec
Timing buffered disk reads: 380 MB in 3.00 seconds = 126.47 MB/sec

HD Sata2 7200 rpm 500GB
/dev/sdb:
Timing cached reads: 2734 MB in 2.00 seconds = 1367.17 MB/sec
Timing buffered disk reads: 320 MB in 3.00 seconds = 106.55 MB/sec

HD Ata133 su interfaccia Ata100 (quella c’è) 7200 rpm 300GB
/dev/sda:
Timing cached reads: 2712 MB in 2.00 seconds = 1356.30 MB/sec
Timing buffered disk reads: 184 MB in 3.02 seconds = 60.97 MB/sec

HD Ata133 su box USB 7200 rpm 160GB
/dev/sdd:
Timing cached reads: 2642 MB in 2.00 seconds = 1320.80 MB/sec
Timing buffered disk reads: 82 MB in 3.04 seconds = 26.96 MB/sec

PEN DRIVE economico USB 2GB
/dev/sde:
Timing cached reads: 2504 MB in 2.00 seconds = 1251.87 MB/sec
Timing buffered disk reads: 30 MB in 3.07 seconds = 9.78 MB/sec

Tirate voi le conclusioni.

😉

Kaffeine, registrare più canali DVB-T contemporaneamente.

Una caratteristica avanzata di kaffeine. è di poter registrare più stream A/V dallo stesso “mux”.
Nell’esempio attivata la registrazione istantanea su Rai2, nella lista canali rimangono visibili gli altri canali dello stesso mux.

Mplayer smplayer + VDPAU

Per abilitare il supporto completo, cioè video out e decoder accelerati VDPAU, in mplayer con interfaccia smplayer, è necessario qualche accorgimento.