Le noyau 4.19 de Stretch-backports ne permet aucune sortie vidéo (Radeon)

Support Debian
, ,
Tags: #<Tag:0x00007f509f2f0098> #<Tag:0x00007f509f2fbee8> #<Tag:0x00007f509f2fbc18>
#1

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 :

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7340]

Extrait de lshw

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 ?

#2

Bonjour,

Pourquoi avoir installé le noyau depuis backports si tout fonctionnait ?

Sur grub, démarrer avec le noyau 4.9 corrige le problème ?

#3

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.

#4

Toutes mes excuses, j’ai bien lu “stretch” mais j’ai encore du mal à intégré que ça y est, buster est sortie :persevere:

Bon du coup je vais laisser des gens plus caler que moi te répondre.

#5

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:

Ca, c’est une vraie bonne raison. :smiley:

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 ?

#6

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

qui actuellement pointe sur
https://packages.debian.org/fr/buster/linux-image-4.19.0-5-amd64
pour info
https://security-tracker.debian.org/tracker/source-package/linux

#7

À 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
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 :frowning:.

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.

#8

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.

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 ?

#9

Regarde par là, sinon:
https://forums.gentoo.org/viewtopic-t-1091062-start-0.html
qui ressort en premier sur la recherche “linux 4.19 radeon black screen”

#10

Rien n’y fait.

Apparemment, c’est un bogue du noyau à propos de la mémoire vidéo :

[    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.