Vous n'êtes pas identifié(e).
Le problème
Le problème c'est que lorsque je démarre l'ordinateur, tout ce passe normalement jusqu'à l'invite GDM.
Mais lorsque je me connecte (via GDM) avec mon nom d'utilisateur et mon mot de passe, il y a presque une minute de latence avant que GNOME se lance. C'est cela le problème.(J'ai aussi testé xfce, enlightment, GNOME sous Xorg...sans plus de succès)
(Notez bien que le problème ne se produit qu'après un reboot ou démarrage à froid, mais pas après une fermeture de session)
Après de nombreux test j'ai constaté que blacklister le module "radeon" résolvait le problème ... au prix de la désactivation de la radeon.
(Alternativement booter avec le parametre kernel "radeon.modeset=0" résoud aussi le problème de la même manière)
Après lecture des logs il semble qu'il y ait des erreurs ACPI lors de du chargement ou du déchargement du driver de la carte graphique additionnelle AMD :
On pourrait penser que le problème est dû au driver radeon,
mais en fait j'ai exactement les mêmes messages d'erreur avec les drivers "amdgpu" (avec le support activé pour les cartes "si" et "cik" )
Tentative d'analyse
D'après :
et
Donc l'acpi device:02 c'est un port PCI express.
Et la radeon est branchée sur ce port PCI express :
Il semble en effet qu'il ait un problème avec le "power state" sur ce port PCI Express :
alors que
Contournements du problème
J'ai bien trouvé quelques contournements pour faire fonctionner le système malgré tout :
- Soit écrire une règle udev pour régler le power/control de la radeon à "on"
Ça marche, le temps de latence disparait ainsi que les erreurs ACPI, mais les températures données par la commande sensors ont augmenté et le ventilateur reste toujours allumé
- Soit passer le paramètre de boot "pcie_port_pm=off" dans GRUB:
Ça marche aussi, mais je me demande ce qu’il en est de la consommation des autres cartes PCi express (les 2 cartes Realtek Wifi et ethernet) ?
(Notez qu'avec cette solution : on a
)
Demande d'aide
J'ai aussi essayé des kernel vanilla (5.5 & 5.6), sans succès.
Quant à une Debian stable, j'ai le même problème avec et on peut même dire que ça fonctionne moins bien car le paquet switcheroo-control est bugué dans sa version buster.
Je ne sais pas quoi tenter d'autre, si quelqu'un a une idée.
Dernière modification par eheintzmann (17-04-2020 14:40:39)
Hors ligne
Hors ligne
ça va te donner le gpu utilisé quand,tu te trouve sur le bureau
pour les erreurs sur la machine
en root
a mon avis tu demande l' impossible afficher sur intel et faire travailler le gpu amd
L’état des cartes graphiques peut-être contrôlé par un simple fichier :
Voici un es2gears_wayland avec la carte Intel (la carte "discrète", la radeon est bien sur DynOff) :
Voici un es2gears_wayland avec la carte AMD Radeon (la carte "discrète", la radeon est bien sur DynPwr et radeontop voit de l'activité sur cette carte) :
Donc a priori, les cartes fonctionnent déjà correctement ensemble.
Ce que je cherche à faire c'est supprimer le temps de latence à la connexion, un peu plus proprement qu'avec un "pcie_port_pm=off" au boot (qui j'imagine doit impacter les autres cartes PCI Exrpess)
Hors ligne
Dernière modification par eheintzmann (21-04-2020 22:35:40)
Hors ligne
Dernière modification par eheintzmann (22-04-2020 01:00:10)
Hors ligne
Après de multiples relectures de mes logs, j’ai trouvé le message suivant :
En utilisant le paramètre de boot acpi_osi=Linux, le message devient :
Mais, d’après les logs, ça n’a pas l’air de changer grand-chose.
De plus, il y a ces autres messages dans les logs :
J’arrive à les faire disparaître à l’aide de du paramètre de boot acpi_osi=!<string>.
Par exemple, acpi_osi=!Linux-HPI-Hybrid-Graphics acpi_osi=!Linux-Lenovo-NV-HDMI-Audio fait disparaître les 2 dernières lignes.
Mais là non plus, je n’obtiens pas de résultats tangibles
Sur le web, je n'ai trouvé aucune bonne explication sur ces paramètres acpi_osi=.
Si quelqu’un sait comment ça marche, ou a des liens, je suis preneur de ses conseils.
Dernière modification par eheintzmann (25-04-2020 06:00:41)
Hors ligne
je vois pas pourquoi tu fixes sur les erreurs acpi , à cause de la latence pour arriver sur le bureau ?
En effet, 40 secondes de latence c’est beaucoup trop.
Comme je crois que les erreurs ACPI sont liées à ce délai, j’essaie de les fixer.
Si je pense que ces erreurs sont liées, c’est qu’il y a dans les logs cette erreur qui arrive toujours après la connexion avec gdm, mais juste avant que celui-ci lance un deuxième serveur X.Org sur le Virtual Terminal 2 (J’ai réglé gdm en mode X11 pour quelques tests).:
Preuve supplémentaire, avec ligthdm, je n’ai plus ce temps de latence à la connexion, et, comme par hasard, les erreurs ACPI disparaissent (mais j’ai d’autres problèmes à la mise en veille et à la déconnexion, je n’ai pas encore cherché pourquoi).
J’imagine que gdm réinitialise (mal) les 2 cartes avant de lancer le second serveur. Mais je n’ai pas encore compris ce que fait lightdm, car il génère peu de logs.
Dernière modification par eheintzmann (25-04-2020 18:31:53)
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
gdm utilise wayland alors que lightdm utilise X11, derrière, ils n'utilisent probablement pas les mêmes modules graphiques.
Par défaut c'est complètement vrai, mais pour comparer les deux, j'ai mis, dans /etc/gdm3/daemon.conf:
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
gdm utilise wayland alors que lightdm utilise X11, derrière, ils n'utilisent probablement pas les mêmes modules graphiques.
c'est pour çà que je ne trouve pas gnome sous wayland sur Lightdm ?
Dernière modification par Debian Alain (25-04-2020 19:44:21)
Hors ligne
c'est pour çà que je ne trouve pas gnome sous wayland sur Lightdm ?
En effet, chez moi non plus, GNOME sous Wayland n’est proposé ni par Lightdm, ni par GDM sous X
Hors ligne
Et la, je n’ai plus aucun temps de latence avec GDM, mais les erreurs ACPI perdurent au VT Switching...
(J’ai bien vérifié que la radeon continue de s’activer avec un DRI_PRIME=1)
Dernière modification par eheintzmann (29-04-2020 10:56:38)
Hors ligne
Wayland
Xorg
Avec Xorg, j’ai essayé différents drivers: intel, radeon, modesetting (*man 4 modesetting*)
J’ai essayé de lancer Xorg de différente manière: lightdm, GDM (sans puis avec l’option *enableWayland=false*), a la main (*startx*)
J'ai tenté d'utiliser un fichier monitors.xml avec GDM.
Quant aux logs de X, ils ne disent rien de particulier (normal, le VT Switching ne faisant pas au niveau de X)
Au niveau de la console, j’ai tenté de changer de mode graphique, depuis grub:
J’ai tenté de passer différents paramètres de boot aux drivers de la radeon et de la i915.
Tout ça sans succès, seul le bricolage sur les seats enlève le temps de latence mais pour les erreurs ACPI rien à faire (sauf blacklister la radeon)
Dernière modification par eheintzmann (30-04-2020 03:51:31)
Hors ligne
au pif , comme çà , tu as pensé à tester le noyau de sid ?
(arf ! , j'ai relu ton fil , j'ai vu que oui .... pardon) .
(5.6.0-1 , je crois) des fois , çà règle ce genre de souci (pas toujours) .
de mémoire , les erreurs ACPI sont souvent dues à une incompatibilité kernel / bios .
elles sont donc quasi irrésolvables .
(mais souvent mineures ) .
sauf à moins de mettre à jour son bios , et encore ... pas sûr .
Dernière modification par Debian Alain (30-04-2020 08:59:30)
Hors ligne
de mémoire , les erreurs ACPI sont souvent dues à une incompatibilité kernel / bios .
elles sont donc quasi irrésolvables .
(mais souvent mineures ) .
sauf à moins de mettre à jour son bios , et encore ... pas sûr .
Oui, j’ai vu des posts sur le web où des utilisateurs résolvaient leurs problèmes ACPI en flashant leur BIOS.
Malheureusement le mien est déjà à jour, je m’en sortirais pas aussi facilement
EDIT : J’ai mis à jour avec le kernel de sid :
Dernière modification par eheintzmann (30-04-2020 11:31:33)
Hors ligne
Je n’arrive pas à savoir à quel matériel cet acpi device:02 est associé.
J’ai tenté, en vain, divers outils pour le découvrir : acpi, acpitail, hardinfo, lshw, dmidecode, discover , inxi.
Comment faire pour trouver le hardware correspondant ?
Hors ligne
chez moi ,
donne ceci
tu pourrai pas trouver une ligne "information bus" comme ici , (ci dessus) qui te donnerai un identifiant pci , par exemple .
et donc , te permettrai de retrouver ton périphérique ?
ah ben si .
si ton post est exact , tu as cette ligne :
chez moi
donc , que donne chez toi la commande suivante : ?
pour commencer ....
Dernière modification par Debian Alain (30-04-2020 19:11:56)
Hors ligne
puisque tu sembles parti pour investiguer les méandres de ton kernel ,
le dernier que tu as essayé , c'était lequel ?
le 5.6.8 ou le 5.7-rc3 ?
Pour le kernel Debian, le dernier que j’ai utilisé c’est le 5.6.7-1.
Pour le kernel vanilla, j’ai fait un git clone puis un git checkout v5.6, je ne m’étais pas inquiété du sublevel.
Maintenant que tu le dis, ça a l’air d’être un 5.6.0
Hors ligne
ceux que je t'ai cités sont à compiler , suivant ce fil : https://debian-facile.org/doc:systeme:kernel:compiler
Dernière modification par Debian Alain (30-04-2020 19:23:26)
Hors ligne
Il y en 3 autres comme ça:
En fait j’avais déjà fait un lspci sur ce physical node, c’est juste que je sais quel est exactement le lien entre le device lui-même et son physical node. (ça doit bien être documenté quelque part).
Hors ligne