Catalyst sous Wheezy

Support Debian
#1

Salut à tous !

Sur une machine utilisant une carte graphique MSI R4350-MD512H/D3 Radeon HD 4350 512MB, il s’avère que si je n’utilise pas à la fois le micro-programme (contenu dans le paquet « firmware-linux-nonfree ») et le pilote propriétaire Catalyst, alors la consommation électrique de la carte graphique est trop importante. En conséquence, elle surchauffe et l’affichage gel. Si le micro-programme et le pilote propriétaire sont installés, aucun problème.

L’installation du pilote propriétaire est expliqué dans le wiki de Debian, sur une installation de base pas de problème. Seulement, j’ai besoin d’un noyau temps réel. Jusqu’à présent, j’utilisais Debian Squeeze, pour lequel je n’ai pas trouvé de noyau temps réel dans les dépôts de base. Il y a bien le dépôt Pengutronix, mais impossible d’avoir un micro-programme fonctionnel sur le noyau temps réel (même stable).

En revanche, j’ai trouvé un noyau temps réel dans les dépôts de base pour Wheezy. Du coup, je compte migrer vers wheezy. Seulement, impossible de trouver Catalyst dans les paquets de Wheezy. Pourtant, le wiki Debian indique qu’il fonctionne sous Wheezy. Avant que je me lance dans de grands travaux, quelqu’un peut-il me confirmer que le paquet « fglrx-driver » est bien disponible sous Wheezy ?

À bientôt.

Le Farfadet Spatial

#2

[quote=“Le Farfadet Spatial”]Salut à tous !

Sur une machine utilisant une carte graphique MSI R4350-MD512H/D3 Radeon HD 4350 512MB, il s’avère que si je n’utilise pas à la fois le micro-programme (contenu dans le paquet « firmware-linux-nonfree ») et le pilote propriétaire Catalyst, alors la consommation électrique de la carte graphique est trop importante. En conséquence, elle surchauffe et l’affichage gel. Si le micro-programme et le pilote propriétaire sont installés, aucun problème.

L’installation du pilote propriétaire est expliqué dans le wiki de Debian, sur une installation de base pas de problème. Seulement, j’ai besoin d’un noyau temps réel. Jusqu’à présent, j’utilisais Debian Squeeze, pour lequel je n’ai pas trouvé de noyau temps réel dans les dépôts de base. Il y a bien le dépôt Pengutronix, mais impossible d’avoir un micro-programme fonctionnel sur le noyau temps réel (même stable).

En revanche, j’ai trouvé un noyau temps réel dans les dépôts de base pour Wheezy. Du coup, je compte migrer vers wheezy. Seulement, impossible de trouver Catalyst dans les paquets de Wheezy. Pourtant, le wiki Debian indique qu’il fonctionne sous Wheezy. Avant que je me lance dans de grands travaux, quelqu’un peut-il me confirmer que le paquet « fglrx-driver » est bien disponible sous Wheezy ?

À bientôt.

Le Farfadet Spatial[/quote]

Salut ,
J’ai une radeonhd 6870 et wheezy 64. Le bon fonctionnement des carte graphique ati depend de la carte mes aussi de la version de debian( stable, testing ou instable )

En premier lieu j’ai installé les drivers sur le site ati,amd avec le catalyst 12.x. Réinstallation car plantage de x. Apparemment beaucoup d’utilisateurs se plaignent de ce style de pilotes. J’avais réussi à les installer sur une lmde,mais j’avais quelques bugs.

Deuxièmement ,je décide de me tourner vers fglrx .mais il a été enlevé du dépôt pour cause d’erreur critique. Chaque année ce problème survient car le developpement surserveur x sur wheezy avance plus vite que celui des pilote catalyst ( je crois,mais c’est dans le style.

Troisièmement , en plus de mes drivers free( radeon,etc…) j’ai installé les firmware-linux-nonfree qui sont moins craignons que le catalyst. Ça fonctionne ,j’arrive maintenant à utiliser gnome 3 en mode standard( et pas en fallback.)et mon écran est reconnu avec la bonne résolution et en 16:9.
L’accélération matérielle marche mais c’est pas encore ça: le test donne 602 frame en 5s = 120.258fps ( je crois que c’est pas terrible.
Je suis donc en train de voir si dans les options de ces paquets je peux paufiner des réglages de ma carte pour qu’elle soit plus puissante( être en gnome3 haut. Si ça existe). Je t’en ferai part quand j’aurais trouvé.
Nb : attention compiz ne marche qu’avec le fallback ( mode restreint de gnome3) mais pas avec gnome 3. Sur nvidia aussi on rencontre des problèmes.
Si ça peut déjà te donner des idées

Ps : peut tu m’expliquer en vulgarisant ce qu’est un noyau temps réel et qu’elles applications intéressantes s’en dégage? Merci

Cordialement
Herbert the serial killer

#3

Salut à tous !

Pour ma part, j’ai fait des tests dans tous les sens, y compris sous Fedora : point de salut, si je n’utilise pas le pilote propriétaire, systématiquement l’affichage gel. Malheureusement, le pilote libre n’est pas encore au niveau en ce qui concerne la consommation d’énergie.

Aïe ! Cela n’arrange pas mes affaires. Est-ce que quelqu’un a récemment réussi à installer Catalyst téléchargé directement chez AMD sur Wheezy (version 64 bits) ?

Un système temps réel est un système pour lequel le respect de contraintes de temps est important : non seulement le traitement doit être effectué, mais il doit l’être dans un délai raisonnable. Par exemple, lorsque l’on écoute de la musique, le fait qu’une note arrive en retard pose autant de problèmes (si ce n’est plus) que si elle n’arrive pas.

Pour l’utilisateur domestique, le cas typique d’utilisation d’un noyau temps réel est la musique assistée par ordinateur : lorsque l’on enregistre par-dessus une piste existante (qu’elle soit MIDI ou déjà enregistrée), on souhaite éviter un décalage entre ce qui est joué en direct et la piste sur laquelle le musicien essaye de se caler.

Il ne faut pas confondre faible latence (traitement effectué rapidement) et temps réel (traitement effectué dans un temps imparti), même si les deux vont souvent de paire.

À bientôt.

Le Farfadet Spatial

#4

Je suppose que tu as vérifié qu’il n’y a pas de noyau temps réel dans les backports de Squeeze ? Cela éviterait tout le tremblement avec Wheezy… Bon j’ai la flemme, je compte également passer en noyau temps réel cet été, pour le moment je suis en prod…

A+

Sergio

#5

Salut à tous !

Ta question m’a fait réaliser que j’avais oublié les backports. Il y a bien un noyau temps réel dans les backports. Je vais donc utiliser ce noyau, je pense que c’est la meilleure solution. Merci.

Maintenant, je voudrais donc supprimer tous les paquets venant du dépôt Pengutronix que j’ai installé, avant d’installer le noyau temps réel dans les backports. Est-ce qu’il y a un moyen de supprimer automatiquement tous les paquets venant d’un dépôt donné ?

À bientôt.

Le Farfadet Spatial

#6

C’est quand même un 3…

Si tu travailles avec Synaptic, il y a au moins un historique, qui te permet de les repérer tous. Je m’en suis souvent servi, même avec des trucs alambiqués comme Boost. En prenant bien le temps, on arrive à s’en sortir sans erreur. Sinon, toujours dans Synaptic, il y a un onglet “installés manuellement” ou un libellé proche : si tu n’as pas déjà mis trop de Wheezy (ce qui est mon cas avec le driver Nvidia et ses acolytes…), tu devrais y retrouver assez facilement tes Pengutronix ; là il faut quand même les sélectionner un à un, puis si on le désire les supprimer tous d’un seul coup.

#7

Salut à tous !

Il vient de Wheezy… Cela dit, j’ai pu tester des noyaux de la série trois, ils ne sont pas mal (à part un petit souci de régression dans les 3.2).

J’utilise un mixe savant d’Aptitude et de Synaptic, avec parfois un peu d’Apt-get… Cela dit, je n’ai encore rien installé venant des backports, je devrais m’en sortir. De Pengutronix, je n’ai installé que le noyau OSADL et les en-têtes qui vont avec. Après, il faudra supprimer les dépendances. J’utiliserais bien Computer janitor, mais il n’existe que dans Sid…

Je vais essayer de faire ça ce soir, je vous tiens au courant.

À bientôt.

Le Farfadet Spatial

#8

Je ne comprend pas trop ou est le problème :
Le paquet Fglrx-driver est bien dans les dépots testing (a condition bien sur d’avoir activé les dépots contrib et non-free)

J’ai déja essayé de l’installer sur ma testing en faisant simplement dans un terminal root

puis j’ai généré le xorg.cong en faisant

suivi du redémarrage du système.

Cependant je me suis alors confronté a 2 problèmes avec catalyst
-je n’avais plus accès aux TTY
-l’animation plymouth ne fonctionnait plus au shutdown et le système se figeait sur un écran blanc.

J’ai donc finalement remis le pilote libre en réglant le profil d’alimentation sur low (la raison pour laquelle je voulais le pilote proprio était pour éviter le bruit gonflant du ventilateur de la carte graphique)

#9

Salut à tous !

Sur http://packages.debian.org, il apparaît sous Squeeze, dans les backports et sous Sid, mais pas dans Wheezy. D’après Herbert West, il aurait été récemment supprimé de Wheezy pour cause d’incompatibilité avec X.org. Cela dit, Wheezy va prochainement subir une phase de forte instabilité, je préférerais utiliser Squeeze si possible – possible signifiant que je dois pouvoir utiliser le noyau temps réel sans que l’affichage ne fige.

[quote]
J’ai donc finalement remis le pilote libre en réglant le profil d’alimentation sur low (la raison pour laquelle je voulais le pilote proprio était pour éviter le bruit gonflant du ventilateur de la carte graphique)[/quote]

Voilà qui m’intéresse : si je peux éviter d’utiliser le pilote propriétaire, cela m’arrangerait. Comment as-tu fait pour passer en profil faible consommation ? Sous Gnome 2 (Squeeze) et sous Gnome 3 (Wheezy) ? J’ai regardé dans « Système > Écrans » et « Système > Gestion de l’énergie », je n’ai pas trouvé.

À bientôt.

Le Farfadet Spatial

#10

Au temps pour moi : je viens de vérifier avec synaptic et effectivement je ne trouve plus trace de fglrx-driver pour testing.

Pour passer le profil en consommation basse avec le pilote libre radeon (la solution est la même pour squeeze et wheezy) :

En root dans /etc/rc.local il faut rajouter a la fin juste avant le exit 0 la ligne :

D’autres réglages que “low” existent (“low”, “mid”, “high”, “auto” et “default” ce dernier étant le réglage par défaut)

Il est aussi possible d’avoir une gestion dynamique de la consommation (mais plante régulièrement chez moi) avec la ligne suivante :

#11

Salut à tous !

Merci Dannyleconte pour ces précisions. Je vais tester ça.

Il y a-t-il un moyen (je pense que oui) de passer temporairement sous le pilote libre sans désinstaller le pilote propriétaire pour que je puisse tester les différents réglages et facilement revenir au pilote propriétaire si besoin ? Je précise que j’ai lancé plusieurs fois « aticonfig » dans la mesure où j’ai installé plusieurs noyaux, je crains donc de ne pas avoir de sauvegarde du fichier « xorg.conf » correspondant au moment où j’utilisais le pilote libre.

À bientôt.

Le Farfadet Spatial

#12

[quote=“Le Farfadet Spatial”]Salut à tous !

Merci Dannyleconte pour ces précisions. Je vais tester ça.

Il y a-t-il un moyen (je pense que oui) de passer temporairement sous le pilote libre sans désinstaller le pilote propriétaire pour que je puisse tester les différents réglages et facilement revenir au pilote propriétaire si besoin ? Je précise que j’ai lancé plusieurs fois « aticonfig » dans la mesure où j’ai installé plusieurs noyaux, je crains donc de ne pas avoir de sauvegarde du fichier « xorg.conf » correspondant au moment où j’utilisais le pilote libre.

À bientôt.

Le Farfadet Spatial[/quote]

Le pilote libre n’utilisant pas de xorg.conf, je pense qu’il suffit juste de supprimer ou renommer le fichier xorg.conf puis redémarrer pour passer sur le pilote libre. Inversément restaurer le xorg.conf en le renommant ou avec la commande aticonfig --initial (et redemarrer) pour repasser sur le pilote propriétaire.

#13

Salut à tous !

Très bien, je teste ça.

Au fait, concernant la ligne suivante (à placer dans « /etc/rc.local ») :

echo "dynpm" > /sys/class/drm/card0/device/power_method

Doit-elle être placée en plus ou bien à la place de cette ligne :

echo "low" > /sys/class/drm/card0/device/power_profile

À bientôt.

Le Farfadet Spatial

#14

Elle doit être mis a la place!

il y a 2 méthodes de gestion de l’énergie :
“dynpm” qui est la gestion dynamique
ou
"profile" (activé par défaut) qui permet de choisir plusieurs profils :
-profil “low” : bloque la gestion de la carte graphique sur le profil basse ressource
-profil “mid” : bloque la gestion de la carte graphique sur le profil intermédiaire
-profil “high” : : bloque la gestion de la carte graphique sur le profil haute performance
-profil “auto” : qui alterne “high” et “mid” selon que l’écran soit ouvert ou rabattu (pour les portables)
-profil “default” (activé par défaut) qui je crois est équivalent a “high”

Je n’utilise pas la méthode “dynpm” car chez moi ca finit toujours par planter a plus ou moins brêve échéance.

#15

Salut à tous !

J’avance, mais tout n’est pas encore réglé.

Tout d’abord, Synaptic dispose d’un onglet « Origine », qui permet de sélectionner les paquets d’un dépôt. Ainsi, j’ai pu retrouver tous les paquets que j’avais installés à partir de Pengutronix et les supprimer sans problème, avant de supprimer le dépôt. Cette phase s’est déroulée sans problème.

Ajouter le dépot « backports » a été très simple également, ainsi que d’installer le noyau temps réel.

Concernant le pilote graphique libre, j’arrive désormais à le faire fonctionner sur le noyau classique aussi bien avec le profil de consommation faible qu’automatique, ce qui est une bonne chose. En revanche, sur le noyau temps réel, quel que soit le profil, l’affichage fini par geler. Je dois donc utiliser le pilote propriétaire. C’est là où le bas blesse : j’ai beau installer les paquets des backports correspondant à « fglrx », Module-assistant ne compile un pilote que pour le noyau classique. Quelqu’un sait-il comment faire pour réaliser un pilote pour le noyau temps réel ?

À bientôt.

Le Farfadet Spatial

#16

Il faudrait peut-être n’avoir en place que les headers correspondant au RT ?

#17

Salut,

Je me permet d’intervenir dans votre discution. Je n’ai plus le driver ATI suite à la MAJ de wheezy. Et pour réduire la consommation de la carte j’ai voulus suivre les conseils de dannyleconte

Mais

# ls /sys/class/drm/card0/device/power_method
ls: impossible d'accéder à /sys/class/drm/card0/device/power_method: Aucun fichier ou dossier de ce type
# ls /sys/class/drm/card0/device/power_profile
ls: impossible d'accéder à /sys/class/drm/card0/device/power_profile: Aucun fichier ou dossier de ce type
#18

Salut à tous !

Oui, mais non : il faut placer les lignes données par Dannyleconte dans « /etc/rc.local ». Ainsi, la configuration est réalisée à l’initialisation de la machine. Modifie « /etc/rc.local » comme conseillé.

À bientôt.

Le Farfadet Spatial

#19

Salut à tous !

Je ne pense pas que le problème vienne de là.

Voici le journal donné par Module-assistant :

/usr/bin/make  -f debian/rules clean                                        
 │ make[1]: entrant dans le répertoire « /usr/src/modules/fglrx »              
 │ dh_testroot                                                                 
 │ rm -f configure-stamp                                                       
 │ rm -f fglrx.o fglrx.mod.c *.o libfglrx_ip.a                                 
 │ rm -f .version .*.o.flags .*.o.d .*.o.cmd .*.ko.cmd                         
 │ rm -rf .tmp_versions                                                        
 │ rm -rf patch                                                                
 │ dh_clean                                                                    
 │ rm -f /usr/src/modules/fglrx/debian/control                                 
 │ rm -f /usr/src/modules/fglrx/debian/dirs                                    
 │ make[1]: quittant le répertoire « /usr/src/modules/fglrx »                  
 │ /usr/bin/make  -f debian/rules binary_modules                               
 │ make[1]: entrant dans le répertoire « /usr/src/modules/fglrx »              
 │ if [ -f /usr/src/modules/fglrx/debian/control.template ]; then \            
         cat /usr/src/modules/fglrx/debian/control.template >                
 │ /usr/src/modules/fglrx/debian/control; \                                    
 │         fi                                                                  
 │ dh_testdir                                                                  
 │ touch configure-stamp                                                       
 │ dh_testdir                                                                  
 │ KERNEL_PATH=/lib/modules/3.2.0-0.bpo.2-rt-amd64/build                       
 │ uname_r=3.2.0-0.bpo.2-rt-amd64 ./make.sh --nohints                          
 │ AMD kernel module generator version 2.1                                     
 │ ./make.sh: line 382: [: trop d'arguments                                    
 │ ./make.sh: line 388: [: trop d'arguments                                    
 │ doing Makefile based build for kernel 2.6.x and higher                      
 │ ./make.sh: line 421: cd: 2.6.x: Aucun fichier ou dossier de ce type         
 │ make[2]: entrant dans le répertoire « /usr/src/modules/fglrx »              
 │ rm -rf *.c *.h *.o *.ko *.GCC* .??* *.symvers                               
│ make[2]: quittant le répertoire « /usr/src/modules/fglrx »                  
 │ make[2]: entrant dans le répertoire « /usr/src/modules/fglrx »              
 │ make -C /lib/modules/3.2.0-0.bpo.2-rt-amd64/build                           
 │ SUBDIRS=/usr/src/modules/fglrx modules                                      
 │ make[3]: entrant dans le répertoire «                                       
 │ /usr/src/linux-headers-3.2.0-0.bpo.2-rt-amd64 »                             
 │ make[6]: *** Pas de règle pour fabriquer la cible «                         
 │ /usr/src/modules/fglrx/firegl_public.c », nécessaire pour «                 
 │ /usr/src/modules/fglrx/firegl_public.o ». Arrêt.                            
 │ make[5]: *** [_module_/usr/src/modules/fglrx] Erreur 2                      
 │ make[4]: *** [sub-make] Erreur 2                                            
 │ make[3]: *** [all] Erreur 2                                                 
 │ make[3]: quittant le répertoire «                                           
 │ /usr/src/linux-headers-3.2.0-0.bpo.2-rt-amd64 »                             
 │ make[2]: *** [kmod_build] Erreur 2                                          
│ make[2]: quittant le répertoire « /usr/src/modules/fglrx »                  
 │ build failed with return value 2                                            
 │ make[1]: *** [build] Erreur 1                                               
 │ make[1]: quittant le répertoire « /usr/src/modules/fglrx »                  
 │ make: *** [kdist_image] Erreur 2

À bientôt.

Le Farfadet Spatial

#20

  1. Ton paquet fglrx est-il le plus récent possible ? Je veux dire, n’y en a-t-il pas un dans les backports qui soit plus récent que celui de Squeeze ?

  2. Je débarque un peu sur ce front-là (je suis en Nvidia), mais… J’imagine que ces fglrx ne sont pas liés au noyau, quand même ? Il n’y en aurait pas un par noyau ? Hypothèse curieuse, mais au point où on en est…

  3. En prenant maintenant le problème par le petit bout, as-tu ce fichier /usr/src/modules/fglrx/firegl_public.c ? Apparemment non, mais s’il était ailleurs dans le voisinage, un sous-répertoire etc. ?

On voit bien que c’est ce make.sh qui ne va pas, il est fait pour du 2.6. Il faudrait que tu essaies de le localiser, est-il au moins dans le /usr/src ? Ceci fait, de quel paquet (par dpkg -I) provient-il exactement ? Normalement d’après ton log il est bien dans le /usr/src/modules/fglrx, on retombe donc sur ce problème d’un fglrx pour noyau 3. Et de toutes manières, en 2.6 ou en 3, il ne devrait pas se plaindre de ne pas trouver firegl_public.c, sans parler des quelques autres indices d’inadaptation.

  • ce Catalyst (je ne vois pas trop ce que cela représente, à vrai dire), c’est aussi le plus récent, le plus adapté ? Et si c’était lui (hypothèse au hasard) qui, justement, te fourguait un make.sh pour 2.6 et non 3 ?