Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Le 3200G fonctionne très bien avec bullseye.
Ou peut-être aussi avec buster + backports.
J'ai cependant une question, puisque chez moi ça ne veut rien savoir, c'est toujours l'écran vide alors que je peux me connecter sans problème à la machine avec ssh (après avoir ouvert une session en aveugle).
La question est : est-ce que cette affirmation se base sur des lectures du web (auquel cas les liens vers les sources sont les bienvenus, car des sites, depuis trois semaines, j'en explore de tous les côtés avec différents mots-clé pour solliciter les moteurs de recherche mais je n'arrive pas à trouver la solution pour mon contexte), ou sur une expérience personnelle, et je vais pouvoir avancer ?
Ma config est très simple :
Il y a 16 Go de mémoire DDR4, un ssd de 256 Go pour le système et 2 classiques de 2 To pour les datas et leur sauvegarde.
J'avais commencé avec un noyau 4.19.118 mais en voyant les consoles Ctrl-Alt-F1...6 en 640x480 (alors que sur une vieille machine à côté et un écran en 1920 x 1200 les consoles sont bien à ces dimensions, sans avoir rien fait de particulier au noyau 3.8.13), j'ai retourné tout le web, ça a fini avec le passage en 5.7.0-0.bpo.2-amd64 par les backports (manip que je ne connaissais pas) et même, sans que je sache trop comment (mais j'ai fait tellement de choses cet été…), je me retrouve en 5.7.10 mais l'écran est toujours aussi vide. 
Pas éteint (sa led reste bleue, ce n'est pas le noir d'une dalle non alimentée) mais vide, aussi bien sur le bureau que sur les consoles.
J'avoue que je ne sais pas par quel bout prendre ce problème qui se résume, en fin de compte, à l'erreur
dans /var/log/Xrog.0.log.
Mais peut-être que je fais fausse route avec cette erreur ? Je n'en sais rien.
Et je ne sais pas comment la corriger.
Pour les infos que vous allez me demander, j'anticipe, je me suis inspiré de commandes (résultats un peu édités sinon je vous perds 
) trouvées ici et ailleurs, ça donne ça :
Vous êtes toujours là ? 
Je peux donner d'autres résultats, mais je ne sais pas quelles commandes sont utiles, j'attends vos retours.
Au plaisir de vous lire,
Dernière modification par jpt (28-09-2020 16:12:25)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Au plaisir de vous lire,
et dans l'attente, il me restait une dernière manip à tenter, suite à lecture d'un post ici, qui dit en substance :
# apt install -t buster-backports linux-image-amd64
Was all I had to do, restart and then configure through System Settings.
Je suis donc parti d'une clé uzbe sur laquelle j'avais fait l'install de l'iso (et dont il a fallu que je rattrape le boot, qui avait foiré lors de l'install il y a 2 jours 
), j'ai modifié le /etc/apt/source.list pour prendre en compte les backports, apt-get update puis apt-get dist-upgrade, j'ai vu arriver le noyau 5.7.0-0.bpo.2-amd64 mais pas moyen de le faire prendre en compte pour l'avoir au menu de grub, 
Question subsidiaire : à quoi peut bien correspondre "System Settings" dans les menus francisés de D-F ?
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
après redémarrage du PC, ce n'est pas mieux ?
mais pas moyen de le faire prendre en compte pour l'avoir au menu de grub,
Normalement une fois le noyau plus récent installé, on redémarre le PC et grub démarre par défaut avec le noyau le plus récent.
> Débuter sur Debian
Principales commandes Linux+ISOs DF+Les cahiers du débutant
> Débuter sur openSUSE
Site officiel + Wiki fr + Forum fr +Guide du débutant sur Leap 15.x
Hors ligne
Dernière modification par Debian Alain (14-09-2020 17:52:40)
Hors ligne
Bonjour,
Et avecapt -t buster-backports install linux-image-amd64 firmware-amd-graphics
après redémarrage du PC, ce n'est pas mieux ?
Bah nan, voilà les dernières lignes de l'apt -t ... :
Pourquoi ce process me bassine avec sda2, qui n'est même pas monté ?
Normalement une fois le noyau plus récent installé, on redémarre le PC et grub démarre par défaut avec le noyau le plus récent.
Oui mais chez moi rien n'est normal, et je ne sais même pas pourquoi…
Je viens de redémarrer suite à l'apt... et pas mieux : toujours pas de 5.7 proposé par grub. 
dans le pire des cas (vraiment dans ...) tu peux mettre les kernels des backports sur stable et même des drivers des backports.
C'est ce par quoi j'ai commencé, + make menuconfig et re-création de noyaux en veux-tu en voilà, pour rien…
mais si c'est pour mettre backports à toutes les sauces, autant passer en testing.
d'ailleurs, le ryzen 3 (comme le ryzen 5) est tellement particulier que testing est plus que recommandé.
Et je fais ça comment, sans tout reformatter ?
C'est une question qui va paraître bête à plein de lecteurs, alors j'explique : la machine avec laquelle je vous écris ce soir a été installée début 2013 et n'a plus été touchée depuis, du point de vue du moteur, si je puis dire. Et pourtant, elle en a avalé, des kilomètres, à faire du traitement d'image, de vidéo, de son, du code et j'en oublie.
Alors les passages d'une version à l'autre, ça n'a jamais été mon truc sauf avec un tuto béton à côté.
tu as peu de chances (j'ai pas dit impossible, seulement difficile) de voir buster tourner dessus.
Oh non, tu me décourages, là.
Ce que je ne comprends pas, c'est qu'il semblerait que certains y soient arrivés, donc c'est faisable ?
note : tu peux mettre les noyaux des backports mais évite les noyaux de testing / sid sauf à moins de créer une franken - debian ou de tout casser.
On va éviter, 
Dernière modification par jpt (14-09-2020 18:58:21)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Dernière modification par Debian Alain (14-09-2020 19:17:17)
Hors ligne
> Débuter sur Debian
Principales commandes Linux+ISOs DF+Les cahiers du débutant
> Débuter sur openSUSE
Site officiel + Wiki fr + Forum fr +Guide du débutant sur Leap 15.x
Hors ligne
tu peux aussi installer
et le lancer :
Dernière modification par Debian Alain (14-09-2020 20:17:52)
Hors ligne
jpt, les noyaux debian, qu'ils soient backports ou pas, normalement, tu les installes directement.
et après j'installe les sources, je lance make menuconfig et je me configure un noyau aux petits oignons,
tu n'as pas à y retoucher ou à les recompiler. sauf besoins très particuliers.
mais en général, ils sont génériques (ou standards, comme tu veux) et couvrent des cas d'utilisation très vastes et variés.
parce qu'un noyau, maintenant, c'est une quantité hallucinante de modules qui sont recompilés à chaque microscopique changement de configuration des options, résultat ça prend un temps dément totalement décourageant, résultat du résultat je passe un temps fou à virer tout ce qui ne m'intéresse pas mais au moins ça me génère des noyaux plus petits et plus rapides à recompiler.
pour passer à bullseye (actuelle testing) depuis buster c'est assez simple.
on appelle ça une migration.
Oui, et ça se lance comment ?
mais faut déjà avoir une machine en parfait état avant de la faire (la migration).
Mais elle est en parfait état, ma machine neuve de juin, juste cette cochonnerie de couple AMD3 3200G / Buster 10.5 qui ne veut pas piloter des consoles correctes.
Il faudrait en dire plus sur le PC, il y a plusieurs systèmes dessus ? Tu as choisi une installation chiffrée ?
Non et non: il y a un système simple Buster 4.19.0 que j'ai migré en 4.19.118 puis en 5.7.10 grâce aux backports mais ce 5.7.10 me génère l'écran vide.
Et il y a parfois un boot sur une clé uzbe générée par une autre clé uzbe embarquant le live de D-F.
Ce boot coince grave puisque j'ai installé suivant tes conseils le backport et pas moyen que le noyau généré (et que je vois dans /boot, avec son copain initrd.img-...) soit pris en compte par le grub au reboot.
Mais quelle prise de tête l'informatique maintenant !
Et pas moyen de désactiver le disque de la machine dans son bios, pour le masquer il faudrait attaquer au tournevis ! À notre époque ! On croit rêver…
déjà jpt, tu peux nous communiquer le retour de ceci s.t.p. ? :
fdisk -l
vi, le voici, avec des lignes en commentaire pour bien préciser les détails :
tu peux aussi installer
apt install boot-info-scriptet le lancer :
bootinfoscriptdonnera des infos sur ton(tes) secteur(s) de démarrage
Résumé succint de RESULTS.txt avec juste les disques système :
le fichier résultat est dans /root, tu peux nous le communiquer (copier / coller)
le voilà ci-dessous, avec les grub.cfg qui sont àmha une véritable horreur à analyser.
Ah le bon vieux temps de lilo…
------------------------------------------------------------------------------------------------------------------------
Il y a quand même un truc hallucinant, c'est que le boot avec la clé présente me propose un noyau "(sur /dev/sdd1)" alors qu'ils sont sur sdc1, voir juste au-dessus la fin de RESULTS.txt
Courage pour l'analyse, merci pour les retours.
Et si je peux me permettre, je propose qu'on ne passe pas trop de temps sur cette histoire de clé uzbe qui n'est pas prioritaire (même si ça pourrait être utile), mais plutôt sur le problème des consoles 80x25, même si la clé pourrait nous donner des pistes (puisqu'il y a dessus un 5.7.0 backport non encore tripatouillé).
Mais si une simple migration résout le 'blème, ça m'irait bien. 
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
jpt, les noyaux debian, qu'ils soient backports ou pas, normalement, tu les installes directement .
tu n'as pas à y retoucher ou à les recompiler. sauf besoins très particuliers.
mais en général, ils sont génériques (ou standards, comme tu veux) et couvrent des cas d'utilisation très vastes et variés.
Ce qui est mon cas : il manque une petite option au module parport_pc pour pouvoir faire fonctionner mon imprimante laser de 20 ans d'âge mais toujours vaillante, bien qu'elle soit de la classe "winprinter" sur port parallèle -- un dinosaure,
Mais quelqu'un a fait du reverse engineering pour fournir au pingouin un petit .c qui fait du bon boulot, donc hors de question de la jeter, et la planète m'en remercie 
Dernière modification par jpt (15-09-2020 11:27:16)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
La question est : est-ce que cette affirmation se base sur des lectures du web . . .
Avec le 3200G j'ai essayé buster+backports et j'avais des soucis, puis installé bullseye et ça a fonctionné.
La question est : est-ce que cette affirmation se base sur des lectures du web . . .
les assertions au sujet de testing se basent en effet sur quelques pages web de l'époque et surtout sur les retours des utilisateurs .
j' en ai pas parlé tout à fait en l'air , comme çà . si tu cherches bien , tu devrai trouver quelques retours à ce sujet .
https://www.reddit.com/r/debian/comment … amd_ryzen/
Dernière modification par Debian Alain (15-09-2020 12:29:41)
Hors ligne
de mon Xorg.0.log
pour les DRM (sur mon 2200G)
il n'a pas tout simplement un souci d' écran ?
un mode non supporté ou un souci de dialogue entre gpu et écran
a priori en mode console pure il a l'affichage (Ctrl + Alt +F2)
aucune info sur la machine
et un lspci pas du luxe
un log entier aussi de Xorg.0.log
ps: un noyau et un firmware récent a minima
sinon les erreurs donnent quoi ?
pour moi sous bullseye ça donne
Hors ligne
jpt a écrit :La question est : est-ce que cette affirmation se base sur des lectures du web . . .
Avec le 3200G j'ai essayé buster+backports et j'avais des soucis, puis installé bullseye et ça a fonctionné.
Oui, ça semble correct mais je n'ai qu'à moitié envie de réinstaller tout le disque système.
si j'ai bien compris, jpt, tu as 3 disques :
- 1 ssd
- 2 seagate 2 To (barracuda ?)
tu démarres sur lequel ? le ssd ? ou l'un des 2 seagate ?
Le ssd : les deux autres sont réservés à mes data et à leur sauvegarde.
Par contre, pour éviter de casser encore plus le ssd, j'ai généré une clé uzbe et elle, bien qu'ayant deux noyaux à son bord (4.9 et 5.7), ne voit pas le 5.7.
https://www.reddit.com/r/debian/comment … amd_ryzen/
So my guess would be Debian Testing or Experimental. If you are looking at Stable, no way. My guess would be that you just need the latest Kernel you can get.
Et le lien dont tu tires ça a deux ans. On peut y lire qu'il faut Mesa 18.0 ou .1 absolument, ça tombe bien je suis en .3,
ceci sur son #1
[ 1.066532] amdgpu 0000:29:00.0: [drm] Cannot find any crtc or sizes
[ 1.079755] [drm] Initialized amdgpu 3.37.0 20150101 for 0000:29:00.0 on minor 0
J'ai les mêmes lignes, lire + bas la section "drm"
de mon Xorg.0.log
[ 13.174] (II) AMDGPU(0): Setting screen physical size to 508 x 285
Chez moi la commande renvoie une ligne vide.
pour les DRM (sur mon 2200G)
je reprends ta sortie, j'y rajoute des commentaires, genre je n'ai pas les lignes commençant par "* " :
il n'a pas tout simplement un souci d'écran ?
Qu'est-ce que tu appelles un souci ? En ce qui le concerne, il fonctionne très bien, c'est juste qu'il est mal piloté.
a priori en mode console pure il a l'affichage (Ctrl + Alt +F2)
Pour moi, Ctrl + Alt + F2 n'est pas de la console pure, c'est de la console émulée, la console pure c'était quand on faisait, à l'époque, init=single
aucune info sur la machine
C'est normal, il n'y a rien à en dire si ce n'est que c'est une carte-mère MSI, peut-être pas au top, mais je ne suis pas un joueur, alors l'overclocking et les tunings de la mort-qui-tue, je m'en balek, si je peux me permettre.
et un lspci pas du luxe
Un complet ? Voili voilou :
Mais avec ce truc-là tu ne vois quasiment rien de Picasso, donc :
un log entier aussi de Xorg.0.log
Tout ? C'est énorme, tu l'as juste après :
cependant, en se concentrant sur "EE", je remonte ça, qui est intéressant -- sauf que je ne sais pas comment corriger...
ps: un noyau et un firmware récent a minima
Noyaux 4.19.118 ou 5.7.10, firmware trié sur ii/un :
sinon les erreurs donnent quoi ?
Les mêmes que chez toi :
En gros on a les mêmes, donc pas d'erreur.
Et pourtant…
j' y pense , jpt : un ch'tit inxi ?
apt install inxi
inxi -Fr
Tout semble normal mais attention !, je me suis loggué et ai lancé ssh en aveugle, comme ça je peux récupérer les infos depuis l'ancienne machine.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
linux-source-5.7 ou autre, hein, je ne suis pas chauvin,
Voilà mon résultat :
Ou alors il faudrait "libérer" le microcode (lequel ? De quoi on parle, là ?) ?
Parce que ces 3 lignes de anonyme me titillent les neurones :
d'autant plus que je ne les ai pas...
Et juste après il a ça :
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Debian Alain a écrit :https://www.reddit.com/r/debian/comment … amd_ryzen/
So my guess would be Debian Testing or Experimental. If you are looking at Stable, no way. My guess would be that you just need the latest Kernel you can get.
Et le lien dont tu tires ça a deux ans. On peut y lire qu'il faut Mesa 18.0 ou .1 absolument, ça tombe bien je suis en .3,
oui , mais on y parle de testing . à l'origine , le noyau 4.19 , étant le dernier sorti , était plus que recommandé . actuelle buster .
mais même sous le noyau de buster , la prise en charge n'est pas très bonne .
parcours le forum , tu trouvera nombre de posts qui parlent de l'actuelle testing bullseye pour les ryzen 3 et les ryzen 5 .
sur le net , sans doute pas bien cherché , j'ai du mal à trouver des infos récentes .
je terminerai sur ceci , jpt .
si tu peux achète toi une clé neuve de bonne qualité : -- celle là -- par exemple .
et copie une image de testing dessus : -- tu as le choix --
cette image te permettra de tester ta distribution avant l'install (live) .
-- copier avec dd --
teste et installe si ok ....
Dernière modification par Debian Alain (17-09-2020 16:40:45)
Hors ligne
le mien
a priori l' APU est mal détecté , moi j'ai bien "modeset enable" et "amdgpu" chargé toi non
voila ce que tu devrais avoir , a la différence de l' APU , moi un 2200G toi un 3200G (j'ajoute aussi je suis en Bullseye , pourtant ma machine fonctionne en Buster (mais moins bien ) ).
le driver est "amdgpu" , et le "modeset" du noyau (il faut les deux )
pour cela il faut un bon noyau , un bon firmware , une bonne version des libdrm et mesa , ainsi que le bon paquet xserver-xorg-video-amdgpu
en mode console pure c'est "modeset" qui te donne la prise en charge du gpu/écran
le serveur X met sa couche a l'invite de connexion graphique
après tout le blabla inutile , l'écran est éteint parce que le gpu n' existe pas
tu n'a pas ceci
et ceci
chez moi le seul souci c'est le chipID et le texte correspondant (aucune importance pour le bon fonctionnement
voila c'est résolu 
Force et Courage
un complément
pour ta question sur DRM
ceci confirme que tout vabien
tu devrais trouver l' ID RAVEN 0x1002:0x15DD 0x1043:0x876B 0xC8
moi c'est "0x15DD"
je suis pas barbu mais c'est le noyau qui alimente /dev/dri/
donc dans ton cas vide 
j'en ai terminé
Dernière modification par anonyme (15-09-2020 18:10:22)
je suis pas barbu mais c'est le noyau qui alimente /dev/dri/
[ 7.806] (EE) open /dev/dri/card0: No such file or directory
[ 7.806] (EE) open /dev/dri/card0: No such file or directory
donc dans ton cas vide
j'en ai terminé
il y a quelques jours (7-10 septembre) j'avais des choses genre
dans Xorg.0.log. Me reste plus qu'à retrouver ce que j'ai bien pu modifier…
@Debian Alain : je ferai ça rapidement, mais pas tout de suite -- je voudrais avoir des logs qui ressemblent à ceux de anonyme, et j'aimerais avoir une explication à propos de cette histoire de blacklistage des modules.
Quelqu'un pourrait regarder avec
si la sortie ressemble à ça
ou à ça
Et il me faut vraiment une ou deux sorties de
linux-source-5.7 ou autre, hein, je ne suis pas chauvin,
pour pouvoir comparer avec ma config.
Il n'y a pas d'autre manière de faire, je crois.
Merci,
Dernière modification par jpt (15-09-2020 19:07:47)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
essaies les mmes tests après un
voilà , après , je la ferme . bon , pas promis parceque j'en sais rien ...
amicalement ,
alain .
P.S.:
1) c'est quoi çà une clé "uzbe" ?
2) n'oublie pas de vérifier que tu as bien la ligne des backports dans ton sources ..
3)
@Debian Alain : je ferai ça rapidement, mais pas tout de suite -- je voudrais avoir des logs qui ressemblent à ceux de anonyme, et j'aimerais avoir une explication à propos de cette histoire de blacklistage des modules.
Quelqu'un pourrait regarder aveccat /etc/modprobe.d/amd64-microcode-blacklist.conf
anonyme est en testing bullseye , sauf erreur , sur son ryzen 3 ....
Dernière modification par Debian Alain (16-09-2020 09:00:10)
Hors ligne
1) c'est quoi ça une clé "uzbe" ?
C'est une clé USB prononcée avè l'assent de Marseille, 
2) n'oublie pas de vérifier que tu as bien la ligne des backports dans ton sources.
Comme ça ? :
# backports
deb http://deb.debian.org/debian buster-backports main contrib non-free
3) le /etc/modprobe.d/amd64-microcode-blacklist.conf
J'ai testé en commentant la ligne blacklist microcode puis reboot, ça n'a rien changé.
j'avais pas l'intention de l'ouvrir mais la curiosité est la plus forte. que donnent :
cat ~/.local/share/xorg/Xorg.0.log | grep amdgpu
cat ~/.local/share/xorg/Xorg.0.log | grep "(EE)"
Ce chemin n'existant pas chez moi, c'est vite réglé.
Cependant, je peux tester ces commandes dans /var/log :
Ensuite je lance ça :
essaie les mêmes tests après un
apt -t buster-backports install --reinstall xserver-xorg-video-amdgpu firmware-amd-graphics
Pendant l'exécution de la commande :
plein d'autres lignes habituelles (dépaquetage, etc.) et ça se termine avec
Très désagréables, ces 26 lignes : ou bien c'est une vraie erreur et qu'on me le haut et fort, pas avec ces timides "W" et "Possible", ou ce n'est pas une erreur et que le process se taise. 
après le reboot :
Voili voilou,
Et puisque la machine est fraichement rebootée, soyons fou :
Et mine de rien, hier j'ai remis Device_driver / graphic_support / console_display_driver_support / framebuffer_console_support et framebuffer_console_deferred_takeover que j'avais désactivé suite à des lectures qui disaient que ceci que cela, bref, j'ai récupéré deux lignes dans Xorg.0.log :
il n'y a donc plus qu'une erreur EE,
Il me manque toujours un truc, mais lequel ?
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
voila pour moi , sur ma machine
retour
la traduction
ps: j'ai commencé avec stretch avec ce matériel
je n'ai jamais vue ce cas de figure
le microcode corrige certaines choses pour le cpu si besoin
d un autre coté tu est curieux pas forcément une mauvaise chose
tu a un dossier dans /etc/modprobe.d/ ou il est possible de blacklister des choses , mais inutile dans ton cas ,
pour le fichier "/etc/modprobe.d/amd64-microcode-blacklist.conf" c'est debian qui le crée a l'installation du microcode .
ce paquet est installé ?
tu a modifier les paquets installés par defaut de debian
Dernière modification par anonyme (16-09-2020 10:43:07)
plein d'autres lignes habituelles (dépaquetage, etc.) et ça se termine avec
update-initramfs: Generating /boot/initrd.img-5.7.10
W: Possible missing firmware /lib/firmware/amdgpu/navi12_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_gpu_info.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_ta.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_asd.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sos.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_rlc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec2.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_mec.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_me.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_pfp.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_ce.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma1.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_sdma.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi10_mes.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_vcn.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_smc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/arcturus_smc.bin for module amdgpu
W: Possible missing firmware /lib/firmware/amdgpu/navi12_dmcu.bin for module amdgpu
Très désagréables, ces 26 lignes : ou bien c'est une vraie erreur et qu'on me le haut et fort, pas avec ces timides "W" et "Possible", ou ce n'est pas une erreur et que le process se taise.
très désagréable , je sais , mais ce sont des erreurs mineures dûes à une mauvaise configuration ,
par les développeurs , des programmes du pilote .
tu peux les ignorer , elles concernent les toutes dernières versions des cartes graphiques AMD
(les radeon RX 5700 XT , par exemple (chipset navi , je crois))
Comme ça ? :
# backports
deb http://deb.debian.org/debian buster-backports main contrib non-free
oui
Dernière modification par Debian Alain (16-09-2020 10:56:15)
Hors ligne
tu dois être un bidouilleur non
un peu, oui, mais pas trop, juste ce qu'il faut quand il faut.
la solution c'est une installation propre de debian bullseye avec le firmware "firmware-amd-graphics"
Ça je le testerai en dernier recours
et un bios a jour pour ta carte mère (la série 300 de la carte mère a besoin du dernier bios pour ce cpu)
et ça va fonctionner du premier coup
La machine ayant 3 mois, j'ai quand même vérifié chez MSI et il n'y a qu'une version postérieure à la mienne, dont les informations ne parlent pas de mon problème.
ps: j'ai commencé avec stretch avec ce matériel
C'est quoi stretch ? Rappel : je n'ai jamais pu m'habituer à ces noms que je trouve stupides car non parlants utilisés chez Debian.
le microcode corrige certaines choses pour le cpu si besoin
C'est bien ce qu'il me semblait.
pour le fichier "/etc/modprobe.d/amd64-microcode-blacklist.conf" c'est debian qui le crée a l'installation du microcode.
Microcode qu'il installe mais qu'il blackliste -- go figure...
ce paquet est installé ?
Hélas oui, et avec la même version que toi.
tu as modifié les paquets installés par defaut de debian
C'est une question (sans point d'interrogation, ) ou une affirmation ?
Dans les deux cas la réponse est "non", les seules choses que je trifouille sont les options du .config pour générer des noyaux.
Et je me rajoute des scripts.
tu peux les ignorer
Oui, ça va me dégager du temps pour voir si j'ai le courage d'aller explorer les sources de X, et j'ai encore des liens à lire et des manips à faire.
Dernière modification par jpt (16-09-2020 11:12:22)
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne