# Le noyau 4.19 de Stretch-backports ne permet aucune sortie vidéo (Radeon) **URL:** \ **Category:** Support Debian\ **Tags:** stretch-backports, buster, stretch\ **Created:** [Juillet 10, 2019, 8:19 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609 "2019-07-10T20:19:28Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Rpnpif](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/43a26b/32.png) [@Rpnpif](https://www.debian-fr.org/u/Rpnpif)\ **Post date:** [Juillet 10, 2019, 8:19 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/1 "2019-07-10T20:19:28Z")
Bonjour, J’ai installé sur Stretch le noyau `4.19` à partir de Stretch-backports. Mais Debian ne démarre pas : Il affiche bien le chargement de `initramfs` puis plus aucune réaction, le logo de Debian restant affiché avec les deux premiers messages de démarrage. Ou plutôt si, le disque s’active comme si de rien n’était. Mais le clavier n’affiche rien et n’agit pas, ni la souris. Quoique il me semble que le voyant du disque dur clignote suivant ce que j’appuie. Ctrl-Alt-Fx ne fait rien. Le démarrage en console est impossible, même le mode rescue. Je n’ai aucun problème avec le noyau `4.9.` il semblerait que Xorg ne démarre pas. `lspci` : ```nohighlight 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7340] ``` Extrait de `lshw` ```nohighlight description: Ordinateur Bloc-notes produit: HP Pavilion g6 Notebook PC (D2F91EA#ABF) fabriquant: Hewlett-Packard version: 0881120000305B10000620100 ``` Auriez-vous une idée de contournement de ce blocage ? ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Juillet 11, 2019, 7:46 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/2 "2019-07-11T07:46:22Z")
Bonjour, Pourquoi avoir installé le noyau depuis backports si tout fonctionnait ? > [@Rpnpif](#): > > Je n’ai aucun problème avec le noyau 4.9 Sur grub, démarrer avec le noyau 4.9 corrige le problème ? ---
**Author:** ![Rpnpif](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/43a26b/32.png) [@Rpnpif](https://www.debian-fr.org/u/Rpnpif)\ **Post date:** [Juillet 11, 2019, 10:40 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/3 "2019-07-11T10:40:47Z")
Bonjour, Bien sûr que ce n’est pas impératif. Mais j’ai installé le noyau 4.19 pour préparer la transition vers Debian 10 afin d’avoir certains logiciels plus frais tout en étant vérifié par l’équipe Debian. Avec le temps, Stretch traîne quelques programmes plus ou moins bien suivis car l’upstream a délaissé ces versions. Bien sûr que 4.9 fonctionne très bien mais je voudrais comprendre pourquoi le 4.19 ne fonctionne pas seulement sur ce PC portable alors que j’en ai 2 autres plus une Raspberry sans soucis. ---
**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\ **Post date:** [Juillet 11, 2019, 11:02 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/4 "2019-07-11T11:02:23Z")
Toutes mes excuses, j’ai bien lu “stretch” mais j’ai encore du mal à intégré que ça y est, buster est sortie 😣 Bon du coup je vais laisser des gens plus caler que moi te répondre. ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Juillet 12, 2019, 8:54 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/5 "2019-07-12T08:54:24Z")
> [@Rpnpif](#): > > Mais j’ai installé le noyau 4.19 pour préparer la transition vers Debian 10 Inutile, les deux peuvent être upgradé indépendamment. De plus, quitte à « préparer une migration buster », autant tester un noyau buster (en téléchargeant le .deb) plutôt qu’un noyau backport destiné à tourner avec une stretch. Mais bon: > [@Rpnpif](#): > > Bien sûr que 4.9 fonctionne très bien mais je voudrais comprendre pourquoi le 4.19 ne fonctionne pas seulement sur ce PC portable alors que j’en ai 2 autres plus une Raspberry sans soucis Ca, c’est une vraie bonne raison. 😃 As tu la possibilité de te connecter en ssh ? Je soupçonne que ça ne soit que la gestion de la carte graphique mais que la machine tourne juste sans affichage. Je n’y connais rien aux cartes ATI, je n’ai jamais eu que des NVidia et des Intel, mais tu es sûr d’avoir un module radeon compilé pour ton noyau ou un truc comme ça ? ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Juillet 12, 2019, 1:32 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/6 "2019-07-12T13:32:24Z")
Le meilleur moyen d’avoir le noyau à jour de la version c’est d’installer le meta-paquet `linux-image-amd64` [https://packages.debian.org/fr/buster/linux-image-amd64](https://packages.debian.org/fr/buster/linux-image-amd64) qui actuellement pointe sur [https://packages.debian.org/fr/buster/linux-image-4.19.0-5-amd64](https://packages.debian.org/fr/buster/linux-image-4.19.0-5-amd64) pour info [https://security-tracker.debian.org/tracker/source-package/linux](https://security-tracker.debian.org/tracker/source-package/linux) ---
**Author:** ![Rpnpif](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/43a26b/32.png) [@Rpnpif](https://www.debian-fr.org/u/Rpnpif)\ **Post date:** [Juillet 12, 2019, 1:48 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/7 "2019-07-12T13:48:58Z")
À [**grandtoubab**](https://www.debian-fr.org/u/grandtoubab) : J’essaierai avec le noyau de Buster sauf s’il m’installe une nouvelle `libc` qui risque de casser ma Squeeze. Je préfère y aller en douceur surtout que Debian `10.0 Live` a les même symptômes donc le problème est le même avec le noyau de Buster. Il lui manque quelque chose. À [**mattotop**](https://www.debian-fr.org/u/mattotop) Bonne idée. La connexion `SSH` fonctionne sans problème. C’est le serveur graphique qui ne reconnaît pas la carte. Le `Xorg.0.log` le confirme. Mais je ne peux pas vous le joindre ou même y copier des extraits parce que ce forum ne l’accepte pas car je suis trop nouvel inscrit et ce forum y voit du SPAM et des liens hypertextes partout même là où il n’y en a pas ☹. J’ai essayé `nomodeset`, `noapic`, `noacpi irqpoll` comme paramètre de noyau sans succès. `/dev/dri/card0` non trouvé semble signifié qu’aucune carte n’est reconnue alors qu’elle l’est en `4.9`. J’essaie de recompiler le noyau à partir d’`upstream` mais je ne sais pas quel module activé. PS : Ce forum voit des liens hypertextes donc du SPAM dès que des crochets existent. Pénible. ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Juillet 12, 2019, 4:33 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/8 "2019-07-12T16:33:33Z")
> [@Rpnpif](#): > > sauf s’il m’installe une nouvelle `libc` Un changement de noyau qui impliquerait une mise à jour de la glibc (donc un glissement de release) ? Ca serait étonnant, et note que moi je suis en noyau 5.0 juste parce que les nvidia ne compilent pas en 5.2, et que la glibc de buster est sans incompatibilité avec le noyau 5. Donc non, un noyau ne doit pas avoir le droit de « tirer » une nouvelle glibc comme dépendance, ça serait un peu casse gueule, et surtout, le noyau ne dépend de rien pour compiler, c’est plutôt le reste qui dépend en général des headers du noyau. > [@Rpnpif](#): > > J’ai essayé `nomodeset` , `noapic` , `noacpi irqpoll` comme paramètre de noyau sans succès. Bah peut être en blacklistant le module radeon (si c’est bien ça) le temps de trouver une version qui marche, ça peut te permettre de démarrer avec un pilote vga standard, peut être ? ---
**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\ **Post date:** [Juillet 12, 2019, 4:35 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/9 "2019-07-12T16:35:29Z")
Regarde par là, sinon: [https://forums.gentoo.org/viewtopic-t-1091062-start-0.html](https://forums.gentoo.org/viewtopic-t-1091062-start-0.html) qui ressort en premier sur la recherche “linux 4.19 radeon black screen” ---
**Author:** ![Rpnpif](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/r/43a26b/32.png) [@Rpnpif](https://www.debian-fr.org/u/Rpnpif)\ **Post date:** [Juillet 13, 2019, 9:10 UTC](https://www.debian-fr.org/t/le-noyau-4-19-de-stretch-backports-ne-permet-aucune-sortie-video-radeon/79609/10 "2019-07-13T09:10:06Z")
Rien n’y fait. Apparemment, c’est un bogue du noyau à propos de la mémoire vidéo : ```nohighlight [8.583773] ------------[cut here]------------ [8.583776] ioremap on RAM at 0x0000000000000000 - 0x000000000041ffff [8.583792] WARNING: CPU: 1 PID: 1 at /build/linux-v84tij/linux-4.19.37/arch/x86/mm/ioremap.c:166 __ioremap_caller+0x286/0x300 [8.583793] Modules linked in: [8.583800] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0-0.bpo.5-amd64 #1 Debian 4.19.37-4~bpo9+1 [8.583802] Hardware name: Hewlett-Packard HP Pavilion g6 Notebook PC/188F, BIOS F.28 09/09/2013 [8.583805] RIP: 0010:__ioremap_caller+0x286/0x300 [8.583808] Code: 8d 34 3c e8 8c 49 00 00 e9 24 fe ff ff 48 8d 54 24 28 48 8d 74 24 18 48 c7 c7 17 e3 63 89 c6 05 58 44 09 01 01 e8 7a 5d 01 00 <0f> 0b 45 31 ff e9 fd fd ff ff 0f b7 05 91 09 fc 00 48 09 04 24 e9 [8.583810] RSP: 0018:ffffa36f4066bcb0 EFLAGS: 00010286 [8.583813] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8984dda8 [8.583815] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000247 [8.583817] RBP: 0000000000420000 R08: 0000000000000001 R09: 0000000000000225 [8.583818] R10: ffff8c3186ff3000 R11: 0000000000000000 R12: ffff8c318203d800 [8.583820] R13: 0000000000000001 R14: ffffffff88c548ee R15: 0000000000000000 [8.583823] FS: 0000000000000000(0000) GS:ffff8c3183080000(0000) knlGS:0000000000000000 [8.583824] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [8.583826] CR2: 0000000000000000 CR3: 000000007f60a000 CR4: 00000000000006e0 [8.583828] Call Trace: [8.583839] ? _cond_resched+0x16/0x40 [8.583845] ? __kmalloc+0x1c1/0x1f0 [8.583849] efifb_probe+0x48e/0x8a0 [8.583854] ? kernfs_add_one+0xe4/0x130 [8.583859] platform_drv_probe+0x3a/0x90 [8.583862] ? driver_sysfs_add+0x75/0xd0 [8.583865] really_probe+0x216/0x3e0 [8.583868] driver_probe_device+0x10b/0x130 [8.583871] __driver_attach+0x109/0x110 [8.583874] ? driver_probe_device+0x130/0x130 [8.583879] bus_for_each_dev+0x67/0xc0 [8.583883] ? klist_add_tail+0x3b/0x70 [8.583887] bus_add_driver+0x16a/0x260 [8.583890] driver_register+0x5b/0xe0 [8.583894] ? vesafb_driver_init+0x13/0x13 [8.583899] do_one_initcall+0x4d/0x1c5 [8.583904] ? do_early_param+0x8e/0x8e [8.583906] kernel_init_freeable+0x18f/0x21a [8.583911] ? rest_init+0xb0/0xb0 [8.583913] kernel_init+0xa/0x110 [8.583917] ret_from_fork+0x22/0x40 [8.583924] ---[end trace b7897a1cf344051a]--- [18.380495] reserve_memtype failed: [mem 0x00000000-0xffffffffffffffff], req write-combining ``` Je vais faire un rapport.