Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Et ces deux dernières erreurs apparaissent sur la Ubuntu 14.04 exactement dans les mêmes conditions que les erreurs ACPI sur la Debian testing (au VT switching).
Sinon la comparaison des «dmesg» des deux distributions est en cours, mais il ne semble pas y avoir de différences majeures.
À propos de différences majeures, systemd et libinput ne sont pas présents sur la Ubuntu 14.04…
c'est dommage , j'aime bien la marque H.P. , ils font du bon matériel (en imprimantes surtout) .
je suis surpris mais pas étonné au fond , tu n'es pas le premier à le mentionner , ses portables sont souvent bridés .
Et encore je n’ai pas parlé du BIOS bridé où seules quelques options sont disponibles, ni de l’hibernation qui n’a jamais marché...
p.s.: au pif , tiens , tu peux nous communiquer le résultat de la commande suivante : ?lspci -nnk | grep -iE "vga|3d|display" -A3
Jette aussi un œil à mon #5
Déjà, à cause de problème d’affichage, il m’a fallu attendre très longtemps avoir de pouvoir installer une distribution Linux dessus, d’abord une Ubuntu.
Puis j’ai dû encore patienter avant de pouvoir installer une Debian testing, (près de 2 ans après l’achat du PC si ma mémoire est bonne).
Ensuite pendant un court laps de temps, il a semblé fonctionner normalement (enfin il en avait l’air, rien ne prouve que la radeon marchait, je ne connaissais pas PRIME et vgaswitcheroo à l’époque).
Puis est apparu le temps de latence à la connexion, que j’ai contourné en blacklistant la radeon, et ce pendant très longtemps.
Donc non, je pense pas qu’il fonctionnait mieux avec un kernel plus ancien, il n’y a pas eu de régression apparente.
Mais j’essaierai quand même un live USB d’une vieille version de Debian ou d’Ubuntu, pour vérifier si les erreurs ACPI étaient les mêmes.
Mais honnêtement, je crois plutôt que la solution, si solution il y a, viendra des paramètres de boot du kernel, car il y a là plein d’option acpi et pci à essayer.
Le PC date de 2013, mais le bios est à jour.
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).
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
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 ?
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 :
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)
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)
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
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:
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.
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.
Je viens de tenter de regarder une vidéo avec VLC en activant la carte dédiée, eh bien ça fait de la bouillie…
Il suffit de changer dans le menu de VLC:
Outils->Préférences->Entrée/Codecs ->Hardware-accelerated decoding
VDPAU ou VA-API via DRM fonctionnent avec ma radeon.
amoeba -windowedactive la carte radeon grâce à cette variable d'environnement,
!
À reproduire, un peu plus proprement, sur tes autres utilisateurs quand tu auras fini de tester.
Je pense tout de même queeheintzmann a écrit :Tout au plus tu pourras changer le DynOff/DynPwr en Pwr (à l’aide du paramètre de boot amdgpu.runpm=0), mais je suis pas sûr que cela ait un intérêt.
présente un intérêt.
Pas sûr, d’après ce que j’ai pu glaner dans les différents wikis et autres forums, sur les laptops, les cartes additionnelles, comme la Radeon, ne servent que pour faire les calculs 3D (et peut-être le décodage des vidéos). Seule la carte principale, la Intel sur ton PC, est reliée physiquement aux différents écrans et connecteurs.
Il est donc inutile voire couteux de passer d'abord par la radeon pour faire de la 2D.
Pour te convaincre de tout ça:
Ouvre un teminal et lance radeontop (laisse le ouvert toute la durée des tests) :
Ouvre un second terminal (laisse le ouvert toute la durée des tests) et lance :
Et maintenant lance différentes commandes avec DRI_PRIME=1 et aussi des applis graphiques depuis le menu gnome en activant la carte dédiée.
Tu vas voir que la radeon ne s’active que pour la 3D.
Caramba ! Encore raté !
!
C’est-à-dire ?
Connecté en tant que test, que donne un
?
et il n’existe pas de ficher "/home/test/.bash_profile"
juste ".bash_history" ".bash_logout" ".bashrc"
C’est plutôt une bonne nouvelle, ça va te simplifier la vie.
Les fichiers à modifier dans /home/test/ sont donc .bashrc et .profile
La nuit porte conseil https://debian-facile.org//img/smilies/xtras/merci.gif beaucoup pour tout déjà !
Bonne nuit.
A lancer avec
( depuis gdm ? c'est à dire Gnome ? C'est une connection classique quoi ? )
Oui, c’est bien une connexion classique.
,mais je ne pense pas que ça aie modifié l’ordre car si j’exécute cette commande :cat /sys/kernel/debug/vgaswitcheroo/switchelle donne
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :DynOff:0000:01:00.0
Non tu ne pourras pas changer l'ordre des cartes dans/sys/kernel/debug/vgaswitcheroo/switch, c’est géré automatiquement par le noyau LInux.
Tout au plus tu pourras changer le DynOff/DynPwr en Pwr (à l’aide du paramètre de boot amdgpu.runpm=0), mais je suis pas sûr que cela ait un intérêt.
Ce qu’il te faut vérifier c’est DRI_PRIME est bien définie comme variable d’environnement pour l’utilisateur test :
Ensuite tu lances *gears* comme précédemment mais sans définir DRI_PRIME et tu vérifies avec radeontop ce qu’il se passe.
Le plus simple c’est de rajouter
à la toute première ligne ou à la toute dernière ligne de ces deux fichiers.
Ensuite tu fermes la session de test, si elle est ouverte, puis tu te connectes depuis gdm en tant que test.
Restera à vérifier que les commandes utilisent la radeon sans redéfinir DRI_PRIME.
Edit à toto : Pour que la lecture du code sur le forum soit lisible par tous, il faut utiliser Autre Code. Modif fête. 
