Reprise du message précédent :

 
Pareil.

J'avais eu le même problème, faut vérifier si un programme ne tournerai pas encore et bloquerait la fin de la session. Sinon, il faut réduire la durée du timeout d’arrêt des services dans la conf de systemd (j'ai pas le fichier à modifier sous la main, je pourrais dire ça ce soir si je n'oublie pas).

Bon là je craque...  
 
J'avais pas de soucis avec la fury. Je teste une autre 290X ultra récente et même problème qu'avec l'autre...

j'ai le bug aussi sur un autre PC, un portable où le bug se produit à chaque reboot/arrêt, avec une legère variante : pas de message " stop job" mais une attente de 90 secondes sans aucun messsage, juste après la ligne "[Ok] generate shutdown ramfs",

pour atténuer le bug on peut en effet réduire le délai d'attente quand un service ne répond pas, en modifiant deux lignes dans le fichier /etc/systemd/system.conf

une valeur de 15 secondes au lieu de 90 secondes,

on peut aussi fixer la limite en secondes dans le fichier service du service en question, par exemple dans le fichier  /usr/lib/systemd/system/user@.service :

Merci pour l'astuce.

Malheureusement l'astuce ne marche pas, j'ai toujours un timeout de 90 secondes...

 
#chezmoiçamarche

vérifie que tu as bien modifié le bon fichier : /etc/systemd/system.conf

tu vires le "#" dans les deux lignes concernées et tu mets à la place la valeur "15s" au lieu de "90s",

puis au prochain redémarrage la valeur du timeout sera de 15 secondes au lieu de 90 secondes ( quand tu vois la ligne "stop job machin chose" )

C'est seulement le defaut que tu modifies dans system.conf, si son service en definit un, ca ne changera rien.

 
Oui j'ai bien fait ça. Je revérifierai, si ça se trouve c'est quand j'ai reboot que ça n'a pas marché (alors qu'il y a une ligne dédiée au timeout du reboot, que je n'avais pas modifiée). Je reessaierai.

J'ai testé avec un autre mec d'HFR qui a le asus MG279Q et une 290X et il a aussi le même problème. J'ai également essayé trois 290X différentes.  
 
Je crois qu'on peut considérer qu'il est impossible d'avoir du 144 avec une 290X et un MG279Q sous linux...  
 
J'ai fait un nouveau rapport de bug mais chez kernel pour la partie AMDGPU. Je ne sais vraiment pas si c'est chez eux ou chez freedesktop que j'aurais du le faire...
https://bugzilla.kernel.org/show_bug.cgi?id=113251

Hey !

J'ai un petit problème, depuis aujourd'hui je ne peux plus installer de paquets à partir de AUR :

Une idée d'où ça peut venir ?

J'ai l'impression que le server d'où je tire le paquet est down nan ?

Si tu n’en dis pas plus, on ne pourra rien faire.

Quelles infos tu voudrais ?

Des choses comme mon pacman.conf (partie Repository) ?

AUR, yaourt, sudo  

C'est quoi le problème ?

Tu invoques une chaine de compilation qui prend ses commandes depuis un script non vérifié, directement en root.

Ah okay
 
Du coup j'ai cherché une façon de faire sans le root : https://wiki.archlinux.org/index.php/makepkg
 

 
Ça parait bizarre que le wiki ne donne pas de solution et renvoi vers un blog qui donne une solution bricolée.
 
Du coup comment installer un paquet AUR sans le root ?

De plus, yaourt s’utilise directement, sans passer par sudo avant (d’ailleurs, il ne fonctionne même pas depuis le compte root).

Autant pour moi concernant l'utilisation de sudo (une mauvais habitude acquise quand j'avais ubuntu)

Yaourt à lui tout seul est une mauvaise habitude (Quand on sait pas vraiment ce qu'on fait)

et rien n'empêche de télécharger à la main le paquet AUR en question, sans passer par "yaourt" :

https://aur.archlinux.org/packages/?SB=l&SO=d

puis de l'installer via "pacman -U"

sinon perso j'ai quasiment pas de paquets AUR, juste un pilote d'imprimante, et les rares paquets exotiques sont ceux que j'ai moi même crée via makepkg ( abs ), ce qui fait que je n'ai pas besoin de "yaourt",

AUR c'est pas assez sécurisé, n'importe qui peut proposer un paquet avec un PKGBUILD mal écrit dedans, ne respectant pas certaines bonnes pratiques, moins on utilise AUR mieux c'est

Mal écrit ou qui fait un petit rm -rf /home 2>/dev/null
Je crois que c'est dans les cartons depuis pas mal d'années de chrooter makepkg mais je sais pas où ça en est.

J'ai eu enfin un retour sur mon bug ! Par contre j'ai besoin d'une traduction car je n'ai absolument rien capté . Du coup je ne sais pas quoi lui répondre.   . C'est un dév AMD    
 
 Alex Deucher 2016-02-27 14:11:28 UTC
 
The pll divider combination that is getting selected doesn't seem to agree with that monitor.  You can try adjusting the algorithm in radeon_compute_pll_avivo() or the pll flags passed to radeon_compute_pll_avivo() in atombios_adjust_pll()
 
Quelqu'un peut m'aider à avancer à partir de ce retour car là sa réponse me dépasse? J'ai juste compris qu'il voulait que j'édite les sources du driver... Je vais peut être enfin pouvoir revenir sur linux avec mon écran  

en gros il suggère de modifier la fonction radeon_compute_pll_avivo(), ou la valeur passée à cette fonction depuis la fonction atombios_adjust_pll()

la fonction radeon_compute_pll_avivo se trouve dans le fichier /drivers/gpu/drm/radeon/radeon_display.c, dans le code source du noyau linux :

http://lxr.free-electrons.com/sour [...] _display.c

la fonction atombios_adjust_pll se trouve dans le fichier /drivers/gpu/drm/radeon/atombios_crtc.c dans le code source du noyau linux :

http://lxr.free-electrons.com/sour [...] ios_crtc.c

là il faut lui demander quelle valeur précisément modifier et quoi mettre, puis tu compiles tout ça pour voir si ça résout le problème, idéalement il aurait dû te proposer un patch, patch qu'il suffit d'intégrer au PKGBUILD du noyau linux ( il y a une partie dans le PKGBUILD où l'on voit déjà des patchs appliqués, ça peut te servir d'exemple pour ajouter le tien, c'est pas compliqué au niveau syntaxe ),

https://projects.archlinux.org/svnt [...] ages/linux

ensuite un petit "makepkg -c" pour créer le paquet de ce noyau linux modifié ( ne pas oublier avant d'ajouter la référence à ton patch dans le PKGBUILD au niveau de la liste des fichiers, puis de recalculer les signatures sha256 dans le PKGBUILD  via makepkg -g )

si ce développeur fait son radin et refuse de te donner un patch alors essaie de le créer toi même à l'aide du programme diff, d'abord tu modifies l'un des deux fichiers du code source, puis à l'aide de ce script bash tu peux créer le patch :

tu lances ton script avec 2 arguments : $1 est le fichier d'origine, $2 le fichier modifié, ça va te générer un fichier patch ( ou diff ) qui indiquera les différences entre les 2 fichiers, c'est en gros ton patch,

dans le fichier patch il faudra ensuite modifier le chemin des deux fichiers pour que ça puisse être pris en compte quand tu feras le makepkg ( ou la compilation manuelle ), la racine doit correspondre à celle des fichiers du code source linux ( faut supprimer toute référence à ton home et ses sous-dossiers ), un truc du genre :

Enfin si tu sais pas comment paramétrer les PLL tu vas pas aller bien loin
Les PLL c'est des chips qui génèrent/modifient des fréquences.

Petite maj :
lex thank you for your return. > > Since my monitor works from scratch with a 7950 or fury but not with three > 290X tested, is that it is possible to retrieve the values that work ? The same algorithm is used on all of those parts. The only reason there would be different dividers selected would be if the pll limits in the vbios or the reference clock were different. However, looking at various vbioses for those different asics indicate that the vbios limits are the same for all of them. I doubt they would be different on your boards. As such. that combination of dividers seems to be disagreeable to your monitor on that specific hw. The underlying hw implementation of the pll varies a bit from asic to asic, so the pll selection probably needs to be tweaked a bit for that hw to be stable at that combination as per comment 17.

Je lui répond : unfortunately i'm not an expert. Can you offert me a pkgbuild patch or tell me what value i need to change in atombios.CRTC.c and what to pût there?

Nan car c'est bien de retrouver espoir après un mois de windows mais la c'est un peu high level le trifouillage des sources

Bonne chance pour qu'Alex te donne un pkgbuild .
Et c'est plus du bas niveau que du haut niveau

Ouais enfin c'est quand même bien pratique les packages AUR et c'est d'ailleurs la raison de mon passage sous Arch   .
J'utilise yaourt pour des logiciels non disponibles dans les dépôts, je vérifie les PKGBUILD quand même avant d'installer et je les modifies la plupart du temps.
Avant Arch, j'étais sur du Debian ou Ubuntu. Pour des logiciels proprio ou opensource qui ne sont pas dans les dépôts, j'allais sur le site en question, téléchargeais et des fois bataillais à installer. Ensuite, j'ai découvert AUR et je m'inspirais des PKGBUILD pour faire mes compilations mais au final je me rends compte que c'est bien plus simple d'être sous Arch que de reprendre le script sous une base Debian ou d'aller sur le site officiel, télécharger le .tar.gz, faire une install propre, faire des raccourcis executables, etc ... Là il y a déjà quelqu'un qui a fait les 3/4 ! Sans compter que ça peut être toi aussi la personne qui fait le PKGBUILD...

C'est ce que j'avais fait au débout mais il y a beaucoup de dépendances, (15-20), et plus de la moitié dans AUR

Tu pouvais juste lui dire que tu sais pas quoi tester et c'était pareil
A la limite il peut te filer un patch/diff mais un PKGBUILD tu rêves
Et puis c'est même pas pratique pour débugger. Je sais que c'est Elbarto qui t'a mis cette idée en tête qu'il fallait un package pour chaque composant de ton système mais dans ces cas là c'est vraiment pas pratique, c'est pas du tout adapté.

Je n'ai pas critiqué AUR.

ABS avec ccache ça va aussi vite ( tout en étant plus secure grâce au filet de sécurité apporté par pacman et la cohérence du PKGBUILD ) qu'une compilation à la main faite à la barbare dans un dossier,

le PKGBUILD est déjà écrit, il faut juste ajouter la référence au patch dedans, et faire un pacman -U à la fin, en fait c'est même beaucoup plus rapide car on a pas besoin de connaitre les commandes permettant de compiler ( qui peuvent varier selon les logiciels, les types d'options avec ./configure, les arguments ) et les éventuels workarounds, tout est déjà prémâché dans le PKGBUILD

sinon un vrai débogage c'est utiliser gdb, mettre des points d'arrêt pour comprendre le bug et identifier la zone à problème dans le code source, mais ici c'est pas ce qu'on demande à Farika, il a juste besoin de savoir ce qu'il faut modifier dans le code source ( quelle valeur mettre s'il s'agit d'une variable ), et ça c'est le boulot du développeur qui a répondu dans le rapport de bug,

je suis prêt à passer à Farika le PKGBUILD modifié avec le patch et tous les fichiers nécessaires pour qu'il crée son paquet, mais il faut déjà savoir précisément quoi modifier, que le développeur fasse une suggestion précise ( comme ajouter une condition dans un  bloc "if" pour prendre en compte un nouveau scénario permettant d'éviter le bug 144hz sur son écran )

On en a déjà débattu, pas envie de paraphraser
Je dis pas que c'est pas faisable, juste overkill et une étape de plus qui apporte pas grand chose.
Supprimer un kernel installé manuellement ça prend 2 secondes

sur un paquet c'est pareil aussi quand on le désinstalle si tu veux engager le débat sur le temps gagné/perdu

tu as une étape supplémentaire ( pacman -U le_paquet ) mais qui n'a rien d'insupportable en terme de temps,

c'est plus cohérent/secure de passer par un paquet dès qu'on veut installer/tester quoique ce soit sur une distribution, et c'est plus confortable car on se base déjà sur un PKGBUILD propre et bien fait ( je parle pas du dépôt AUR ), gain de temps, pas besoin de lire le readme.txt pour connaitre les options d'installation du ./configure par exemple,

mais chacun fait comme qu'il le sent selon ses habitudes

On va demander à Linus ou à GregKH et consorts s'ils font des RPM/DEB/etc... quand ils développent ou débuggent

là ils s'agit de développeurs, pas d'utilisateurs finaux

après un truc simple en java ou en C# --> à priori tu fais tout dans l'IDE ( eclipse, visual studio ) niveau compilation/execution/débogage sans rien installer en root sur le système,

tout ce qui est setup/installation qui va toucher à ton / ( ou c:\windows ) moi je dis prudence, jamais de "make install" en root par principe, soit j'installe ça dans mon /home avec un "prefix=" si je veux à tout prix gagner 5 secondes, soit je fais un paquet si je suis sûr de l'installer pour de bon

   
Non mais sur le fond je suis d'accord avec toi.
A l'heure actuelle j'ai aucun truc installé manuellement d'ailleurs, tout est packagé. Je parle juste pour les cas de dev/debug et pour moi là, on est dans ce cas.
 

Sinon pour le souci avec yaourt, c'est lié à package-query. Il a été mis à jour hier: https://github.com/archlinuxfr/package-query/issues/108

J'utilise yaourt depuis qu'il existe et même si je l'utilise plus en tant que "maker" de paquet aur (j'utilise à présent le couple cower/repoctl pour me faire un repo perso), il faut reconnaître qu'après tant d'années à l'utiliser, mes doigts écrivent yaourt automatiquement, même au boulot
Et puis j'aime bien le query simple qui affiche les résultats des repos binaires et aur en même temps.
Ensuite on est tous responsable de sa machine donc à chacun de faire attention à ce qu'il installe via aur mais des pkgbuild vraiment pourris, ça fait quand même très longtemps que j'en ai pas vu.

Je suis d'accord avec Elbarto sur les pkgbuilds (sauf en cas de bisection, la c'est moins pratique).

Et on est quasiment dans ce cas puisqu'il s'agit de tâtonner sur les valeurs

bah dans le cas de la création du paquet on ne touche qu'au patch quand on veut tester différentes valeurs,

on peut désactiver la vérification de la signature sha256 du patch dans le PKGBUILD ( mot clé "SKIP" ) pour ne pas avoir à modifier à chaque fois ce fichier quand on modifie le patch, ça permet de gagner du temps,

j'avais procédé de cette manière pour résoudre un bug lié à une carte controleur sata/ide Jmicron, pour tester des patchs proposés par un développeur linux,

grosso modo ça revient au même que la compilation manuelle, sauf que tout est automatisé via makepkg, avec l'assurance qu'on bousillera pas son système,

après c'est vrai que c'est un peu moins pratique pour les git-bisect, quand je déboguais mesa j'avais opté pour l'installation dans le /home avec le truc du "prefix=", puis une variable d'environnement LD_LIBRARY_PATH qui pointe dans mon /home au moment de tester les librairies