Reprise du message précédent :
720p@60fps sur cette vidéo, aucun soucis O_o : https://www.youtube.com/watch?v=cTNd3h9HC8A
 
étrange ...

j'ai voulu tester les pilotes propriétaires AMD.  ~ 500 Mo d'archive, et dkms n'a même pas réussi à construire les modules - pas compatible avec les headers des derniers noyaux (alors que le dossier date du 1er décembre 2017 >_< )

j'ai fait un git bisect, le commit qui pose problème est celui-là :

annuler ce commit n'est pas vraiment possible car la commande "git revert 648bc3574716400acc06f99915815f80d9563783" annonce un conflit de fichier,

j'ai crée un patch un peu bourrin consistant à modifier les fichiers liés à drm/ttm pour qu'ils reviennent à leur version du noyau 4.14.13,
ça concerne ces fichiers :

mon patch ne marche qu'avec les cartes radeon, car pour qu'il soit universel il faudrait modifier tous les fichiers drivers/gpu/drm/<modèle de carte>/*_ttm.c,

j'ai ouvert un rapport de bug, j'espère que les développeurs trouveront une solution

Tu as fait le gros du travail, je pense que ca devrait aller.
As-tu ouvert sur kernel.org ou fdo?

j'ai crée le rapport de bug sur kernel.org :

https://bugzilla.kernel.org/show_bug.cgi?id=198511

à noter que j'avais fait un premier bisect qui s'est averé erroné, git bisect s'était trompé en m'annonçant un "first bad commit" qui n'était pas le bon,

j'ai été contraint de faire un second bisect avec des intervalles différents entre le good et le bad commit, et là ça a marché cette fois, il a trouvé le vrai "first bad commit"

juste après le bisect j'ai remarqué que le paquet git a été mis à jour chez archlinux, peut-être qu'il y avait un bug subtil corrigé ensuite dans git ( ou alors c'est moi qui a merdé dans le bisect, j'ai pourtant fait attention )

sinon un développeur a commencé à me répondre dans le rapport de bug, le problème pourrait venir de la manière dont firefox fait le rendu des vidéos youtube, une technique liée à la gestion de la mémoire, le nouvel algo du kernel linux semble désavantager firefox si des allocations de page mémoire sont faites d'une certaine manière ( mais j'ai pas tout compris ), il en résulte une baisse des performances dans firefox, si vous avez un CPU ultra récent ( ryzen, core i7 ) vous ne verrez probablement pas les lags dans les vidéos 1080p/60 FPS de youtube,

par contre si comme moi vous avez un vieux CPU ( intel core 2 quad, pentium dual core, celeron ) alors vous risquez de voir des lags avec le noyau 4.15rc8 ( lags qui n'étaient pas présents avec le noyau stable 4.14.13 )

de plus sur un autre forum quelqu'un m'a fait remarquer que par défaut l'accélération graphique est désactivée dans la version linux de firefox, car il y a des bugs que n'ont pas résolu les développeurs de firefox, du coup par défaut ils ont carrément désactivé l'accélération graphique,

on peut forcer l'accélération graphique en mettant à true l'option "layers.acceleration.force-enabled" dans about:config, mais on court le risque d'un crash de firefox :

https://www.reddit.com/r/firefox/co [...] ox_may_be/
https://bugzilla.mozilla.org/show_bug.cgi?id=1323284

j'ai forcé l'accélération graphique dans les options de firefox, ça a fait disparaître les lags, mais c'est du cheat mode/workaround, pas une solution définitive,

j'ai testé aussi d'autres navigateurs internet avec le noyau 4.15rc8 :

- avec opera j'ai les mêmes lags que firefox 57
- avec chromium pas de lags, mais c'est probablement parce qu'il utilise par défaut l'accélération de la carte graphique ( contrairement à firefox )

pour chromium tout dépend du système. sous debian/ubuntu (et dérivées) même en forçant l'accélération, il ne se passera rien. il faut reconstruire chromium avec les options d'accélération, ou trouver un PPA avec une version de chromium recompilée

le record de RC pour un noyau (sous ubuntu, pas vu les autres) est de 10. sera-t-il battu ?  

oui la version 4.15 tarde à passer dans la branche stable, ils ont peut-être détecté des bugs ou bien ils veulent prendre leur temps,

sinon j'ai une question à propos des IRQ :

- est-il possible d'affecter une IRQ IO-APIC à un périphérique au moyen d'un paramètre de boot pour le noyau linux ?

le IRQ IO-APIC c'est ce qu'on voit quand on tape la commande :

le noyau linux est capable de réattribuer les IRQ à chaque périphérique en outrepassant les choix du bios, le souci avec ma config c'est que j'ai 2 cartes PCI tuner, 90% du temps le noyau linux attribue l'IRQ 18 à ma première carte tuner ( cx88[0] ) et l'IRQ 20 à ma seconde carte tuner ( cx88[1] )

mais il arrive dans 10% des cas qu'il fasse une inversion  ( IRQ 20 pour la première carte tuner et IRQ 18 pour la seconde ) et ça crée alors des warnings dans dmesg :

mon idée c'est alors de trouver un moyen de dire au noyau linux d'utiliser tel numéro d'IRQ pour tel périphérique, afin que ça ne varie jamais quand on reboot, mais j'ai encore rien trouvé comme paramètre du noyau qui permettrait cela

il est arrivé
mais il m'a foutu un sacré bordel dans la gestion de l'affichage

et non, rien à voir avec x.org puisque je n'ai effectué aucune mise à jour depuis l'installation de ce noyau

bordel

même résultat avec le dernier noyau. je comprends mieux

edit : évidemment c'était le pilote proprio que j'utilisais depuis un moment qui n'est plus compatible
l'alternative libre fonctionne bien cette fois-ci

test du 4.16 : aucun changement apparent de mon côté. rien non plus dans les en-têtes du noyau, les modules se construisent parfaitement si c'était le cas avec la version 4.15

Question bête.
Quelqu'un utilise la fonction localmodconfig? Cela ne compile que les modules chargés à l'instant de la compilation et, en zieutant sur des forums, j'ai des doutes sur le fait que cela compile des modules qui pourraient être déchargés vu qu'ils n'ont plus ou peu d'intérêt à cet instant genre des trucs liés à Systemd et au boot?
 
Je demande cela parce que je suis "à la recherche" d'un bug matériel ou de pilotes qui font planter mon pc et que je voudrais limiter mes recherches...Bon, je suis quasi sur que c'est ma CG mais bon...
 
P.S:J'avais compilé un noyau sans l'installer et j'ai vu qu'il y avait AMDgpu et Radeon de compilé. Je me demandais si cela était aussi normal?

localmodconfig compile les modules actuellement chargés en mémoire par le système au moment où tu compiles le noyau,

en faisant un lsmod tu peux voir les modules chargés par ton système,

ça permet un temps de compilation nettement plus rapide ( genre 15 minutes au lieu de 2 heures avec un CPU de type core 2 quad ),

l'inconvénient c'est qu'il manquera des modules lorsque tu voudras connecter certains périphériques qui n'étaient pas présents en mémoire lorsque tu as fait la compilation ( clé USB, insertion d'un dvd-rom, webcam )

Finalement, je crois que je ne vais pas tenter.
 
P.S:Sur Archlinux et Kernel-zen.

bizarre, j'ai pas eu de warning avec localmodconfig,  
 
dans le PKGBUILD essaie de mettre ça ( j'ai utilisé celui du noyau mainline ) :
 

Je retenterais à l'occasion.

Pour info, je connais cette technique pour forcer l'accélération graphique sur Firefox (désactiver par défaut sur linux)
 
Dans about:config passer la variable layers.acceleration.force-enabled à true et redémarrer Firefox.
 
On peut vérifier la prise en compte de la configuration dans about:support au niveau de HW_COMPOSITING.
 
   au passage  
 
Edit : j'ai rien dit... je viens de lire la dernière page  

à confirmer mais le 4.18 me pose quelques soucis avec 2/3 hardwares intégrés (webcam, micro, ...) . pas bien méchant mais si quelqu'un a l'utilité d'un de ces objets et qu'il n'a rien en rechange...

l'acceleration graphique, c'est pour l'interface de firefox , pas pour les videos

https://www.phoronix.com/scan.php?p [...] arch&num=1
Des benchs sur le noyau. Otan dire que c'est déprimant surtout pour ceux qui ont passé du temps dessus.

Au final, je comprends que l'upstream les a refusés. J'imagine que même Gentoo a été incapable de présenter un cas de figure où la différence est significative.

D'ailleurs est-ce que quelqu'un a tester ça récemment, sur NVIDIA par exemple ?
J'avais recompilé un Chrome avec le patch et installé le connecteur vdpau vers va pour NVIDIA et ça n'a jamais marché.

Je travaille sur un système de vidéo surveillance basé sur WebRTC pour ceux qui se demandent.

Du coup j'ai demandé des CPU de porc (Ryzen 8 cores) pour chaque contrôleur, mais j'aurais bien aimé profiter des 1060 que je met dans la machine (nécessaire pour le nombre de sorties vidéos)

Chrome ne permet pas l’accélération graphique sous Linux, même quand tu forces son activation dans les flags (il te dit que c’est activé, mais il te ment).

Linux 5.0 fuck yeah !

Il y a un patch qui active le support mais pour.moi ça n'a marche pas sur NVIDIA

attention aux utilisateurs de SUSE https://www.cert.ssi.gouv.fr/avis/CERTFR-2019-AVI-127/

Je suis tombé sur un petit article en anglais qui dit/confirme en gros que les problèmes de sécurité des proco Intel lié à l'exécution spéculative ne sont pas ré-solvables globalement.
 

https://www.zdnet.com/article/top-l [...] oing-away/
 
Mais du coup, les procos sans HT sont secure ?

Oui, du moins beaucoup plus (car l'HT permet d'accéder de manière concurrent au même cœur physique, et donc de leaker). Sans HT + des patches appropriés, t'es OK.

edit : d'ailleurs, étant présent pendant la keynote, il m'a semblé que GKH a fait une faute concernant Zombieload, appelé Zombieland par lui-même

 
   
 
Autres infos :
https://linuxfr.org/news/automne-sa [...] chez-intel

https://mdsattacks.com/

 
 
Pour tenter de reformuler, désactiver l'HT ne fait pas disparaître les problèmes mais les patchs ont des chances d'être plus efficaces.
 
Pas des pressions sur les fournisseurs de cloud pour qu'ils passent à AMD ? Les utilisateurs ne paniquent pas un peu ? Ce sont des questions qui me viennent à l'esprit mais c'est un peu HS.

Les gens s'en battent les couilles surtout ^^

Plus trop a jour le titre

Ping un modérateur de la catégorie pour reprendre le sujet, en espérant ne pas avoir trop de latence

Je veux bien me dévouer pour maintenir la FP

Je vote vergie !

Magicpanda a disparu ?

Dernier message le 14 juin 2019

c'est pour ça que je demande

Un panda ce n'est déjà pas nerveux alors un vieux.

Arch est passé au 5.4 :