Sommaire
- PC sous Debian testing
- Le problème
- Tentative d'analyse
- Contournements du problème
- Demande d'aide
- EDIT : Problème identifié
Bonjour à tous,
PC sous Debian testing
Je possède un ordinateur portable HP Pavilion 17-e050sf sous Debian testing.
C'est un système à cartes graphiques hybrides Intel / AMD,
avec pilote "i915" pour la carte intégrée, et pilote "radeon" pour la carte additionnelle AMD (alternativement le pilote "amdgpu" peut-être utilisé pour la carte AMD).
lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / Radeon 520 Mobile]
07:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter (rev 01)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 07)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 paramètre kernel "radeon.modeset=0" résout 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 :
modprobe -r radeon
...
[ 134.810044] ACPI Error: Aborting method \AMD3._ON due to previous error (AE_AML_LOOP_TIMEOUT) (20191018/psparse-529)
...
[ 134.811473] acpi device:02: Failed to change power state to D0
...modprobe radeon
...
[ 382.899240] acpi device:02: Failed to change power state to D0
...
[ 389.158051] acpi device:02: Cannot transition from (unknown) to D3hot
...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 :
ls -al /sys/bus/acpi/devices/device\:02/physical_node
lrwxrwxrwx 1 root root 0 avril 16 12:57 /sys/bus/acpi/devices/device:02/physical_node -> ../../../../pci0000:00/0000:00:01.0et
lspci -s 0000:00:01.0
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 24
Bus: primary=00, secondary=01, subordinate=06, sec-latency=0
I/O behind bridge: 00005000-00005fff [size=4K]
Memory behind bridge: c2000000-c2ffffff [size=16M]
Prefetchable memory behind bridge: 00000000a0000000-00000000afffffff [size=256M]
Capabilities: [88] Subsystem: Hewlett-Packard Company Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [a0] Express Root Port (Slot+), MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [140] Root Complex Link
Capabilities: [d94] Secondary PCI Express
Kernel driver in use: pcieportDonc l'acpi device:02 c'est un port PCI express.
Et la radeon est branchée sur ce port PCI express :
ls /sys/bus/acpi/devices/device\:02/physical_node
0000:00:01.0:pcie010
0000:01:00.0
...lspci -vs 0000:01:00.0
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / Radeon 520 Mobile]
DeviceName: Radeon HD 8670M
Subsystem: Hewlett-Packard Company Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / Radeon 520 Mobile]
Flags: bus master, fast devsel, latency 0, IRQ 35
Memory at a0000000 (64-bit, prefetchable) [size=256M]
Memory at c2000000 (64-bit, non-prefetchable) [size=256K]
I/O ports at 5000 [size=256]
Expansion ROM at c2040000 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 <?>
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Capabilities: [150] Advanced Error Reporting
Capabilities: [270] Secondary PCI Express
Kernel driver in use: radeon
Kernel modules: radeon, amdgpuIl semble en effet qu'il ait un problème avec le "power state" sur ce port PCI Express :
cat /sys/bus/acpi/devices/device\:02/power_state
(unknown)cat /sys/bus/acpi/devices/device\:02/real_power_state
D0Contournements 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"
cat /etc/udev/rules.d/01-pci_pm.rules
DRIVER=="radeon", SUBSYSTEM=="pci", ATTR{power/control}="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:
cat /etc/default/grub
...
GRUB_CMDLINE_LINUX="pcie_port_pm=off"
...Ç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
cat /sys/bus/acpi/devices/device\:02/power_state
D0)
Demande d'aide
J'ai aussi essayé des kernel vanilla (5.5 et 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.
EDIT : Problème identifié
Finalement, j'ai signalé le problème sur le Gitlab de freedesktop.org consacré aux carte graphique AMD :
https://gitlab.freedesktop.org/drm/amd/-/issues/3229
Mario Limonciello d'AMD a identifié le problème et proposé un patch pour le kernel :
Hewlett-Packard HP Pavilion 17 Notebook PC/1972 is an Intel Ivy Bridge
system with a muxless AMD Radeon dGPU. Attempting to use the dGPU fails
[…]
The issue is that the root port the dGPU is connected to can't handle
the transition from D3cold to D0 so the dGPU can't properly exit runpm.The existing logic in pci_bridge_d3_possible() checks for systems that
are newer than 2015 to decide that D3 is safe. This would nominally work
for an Ivy Bridge system (which was discontinued in 2015), but this system
appears to have continued to receive BIOS updates until 2017 and so this
existing logic doesn't appropriately capture it.Add the system to bridge_d3_blacklist to prevent port pm from being used.
# tu as déja bien avancé
Posté par NeoX . Évalué à 4.
je dirais que l'option "pcie_port_pm=off" semble la plus probante
pour la consommation, là c'est à toi de voir, batterie pleine, mettre cette option au démarrage avoir un usage "standard" de ta machine, voir combien de temps elle tient
idem batterie pleine, ne pas mettre l'option, voir combien tu gagnes ?
y a aussi des outils pour savoir ce qui consomme, mais j'ai perdu le nom.
sinon pour changer des valeur dans /sys/bus/acpi tu dois pouvoir le faire avec sysctl*
sysctl -w bus.acpi.devices.....=D0ouecho D0 >/sys/bus/acpi/devices.....ou via son fichier de config /etc/sysctl.conf
[^] # Re: tu as déja bien avancé
Posté par Eric . Évalué à 2.
powertop ?
Certes oui, mais le fichier en question doit contenir l'état du périphérique :
- D0 (actif)
- D1 (état optionnel)
- D2 (état optionnel)
- D3Hot (désactivé)
- D3Cold (complètement désactivé)
Comment savoir quel état écrire ? Et à quels moments écrire cet état ?
Sinon il y a un paramètre de boot kernel, "acpi.power_nocheck" qui est censé faire que le kernel ignore cet état mais il n'est pas documenté sur kernel.org.
Je l'ai déjà essayé, mais ça ne change rien
[^] # Re: tu as déja bien avancé
Posté par hitmanu . Évalué à 2.
Je vais peut être dire une bêtise mais, ça ressemble a un bug du firmware du pc ( bios problème ACPI ) comme il existe sur le thinkpad x31 depuis plus de 15 ans qui ne sera donc pas corriger.
La tu mis a jour par curiosité.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: tu as déja bien avancé
Posté par Eric . Évalué à 2. Dernière modification le 19 avril 2020 à 23:31.
Oui, j’ai bien pensé à un bug du BIOS, d’ailleurs j’ai d’autres messages d’erreur ACPI que je peux faire disparaître en blacklistant le module kernel lpc_ich.
Je l’ai bien mis à jour régulièrement.
Mais HP parle, sur son site web, d’une version F.28 Rev.A, parue le 23/03/2017, mais le ficher téléchargé installe une version F.28, parue le 14/03/2017. Une piste serait de trouver cette version F.28 Rev.A, si elle existe.
Sinon j’ai compilé un noyau avec le debug ACPI et PCI. J’ai bien des messages supplémentaires pour le PCI, mais pour l’ACPI, rien de plus. Je vais donc essayer de trouver les options de boot qui activent les messages de debug de l’ACPI.
Il y a d’autres options de boot pour l’ACPI que je n’ai pas encore tenté comme « acpi_rev_override » car je comprends pas encore très bien ce qu’elle fait.
(si quelqu’un a des liens…)
Sinon je me disais que je pouvais mettre le « power mangement » sur « off » juste pour le port PCI Express incriminé, ça pourrait fonctionner. À essayer aussi.
[^] # Re: tu as déja bien avancé
Posté par Eric . Évalué à 1.
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é aucunes bonnes explications sur ces paramètres acpi_osi=
Si quelqu’un sait comment ça marche, ou a des liens, je suis preneur de ses explications.
# radeon.rupm=0
Posté par Eric . Évalué à 1.
Si je démarre le PC avec le paramètre « radeon.runpm=0 », les erreurs ACPI disparaissent, ainsi que le temps de latence après la connexion avec gdm3.
Malheureusement cela désactive la gestion dynamique de la carte additionnelle, la radeon restant allumé en permanence:
[^] # amdgpu.rupm=0
Posté par Eric . Évalué à 1. Dernière modification le 22 avril 2020 à 01:10.
En utilisant le paramètre de boot amdgpu.rupm=0, j’arrive aux mêmes résultats.
À condition de blacklister le module radeon, et bien entendu d’activer le support du module amdgpu pour ma carte Radeon — Sun XT / HAINAN, famille Sea Islands (SI).
# VT switching
Posté par Eric . Évalué à 2.
J’ai trouvé une autre piste:
En effet, je me suis aperçu qu’avec lightdm je n’avais pas le temps de latence à la connexion contrairement à GDM !
Après lecture des logs, la différence entre les deux c’est que GDM fait un VT switching (changement de terminal virtuel) et pas lightdm.
GDM se lance sur le tty1, et après la connexion il lance la session sur le tty2.
Alors que lightdm se lance sur le tty7 et lance la session sur le même tty7.
Du coup j’ai effectué des tests de VT switching manuel (à coup de Ctrl+Alt+F(1-6)).
Il y a bien un temps de latence la première fois que l’on passe d’un VT graphique à un VT texte (ou l’inverse, selon que le paramètre de boot splash est activé ou non) et des erreurs ACPI à chaque VT switching.
A priori le VT switching c’est de la responsabilité du noyau et de logind (systemd).
Du coup, après de multiple essais, j’ai enlevé la radeon ainsi que le DisplayPort de la i915 (y a pas de DisplayPort sur mon laptop) du seat0 avec une règle udev que voici:
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)
# /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02/
Posté par Eric . Évalué à 1.
Dans le post initial, je pensai que l’acpi device:02 était un port PCI Express.
En fait j’ai maintenant comme un doute à ce sujet.
En fait /sys/bus/acpi/devices/device:02 est un lien vers ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02
et :
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 identifier le hardware correspondant ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.