Erreur ACPI avec une radeon sur un PC Intel

[eheintzmann]

Bonjour à tous,

PC sous Debian testing

Je possède un ordinateur portable HP Pavilion 17-e050sf sous Debian testing :
https://support.hp.com/fr-fr/document/c03817695
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)

Code : Tout sélectionner

$ 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 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 :

Code : Tout sélectionner

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

Code : Tout sélectionner

$ 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 :

Code : Tout sélectionner

$ 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.0

et

Code : Tout sélectionner

$ 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: pcieport

Donc l'acpi device:02 c'est un port PCI express.
Et la radeon est branchée sur ce port PCI express :

Code : Tout sélectionner

$ ls /sys/bus/acpi/devices/device\:02/physical_node
0000:00:01.0:pcie010
0000:01:00.0   
...

Code : Tout sélectionner

$ 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, amdgpu

Il semble en effet qu'il ait un problème avec le "power state" sur ce port PCI Express :

Code : Tout sélectionner

$ cat /sys/bus/acpi/devices/device\:02/power_state
(unknown)

alors que

Code : Tout sélectionner

$ cat /sys/bus/acpi/devices/device\:02/real_power_state
D0

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"

Code : Tout sélectionner

$ 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:

Code : Tout sélectionner

$ 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

Code : Tout sélectionner

$ cat /sys/bus/acpi/devices/device\:02/power_state
D0

)

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.

[piratebab]

Bonjour,
as tu essayer de mettre à jour le BIOS (ou UEFI) ?

[eheintzmann]

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.

[piratebab]

Il y a un paquet pour le firmware des proc intel, regarde si tu l'as d'installé.

[eheintzmann]

Tu veux parler de intel-microcode ?
Oui, il est déjà installé, ainsi que:
firmware-amd-graphics
firmware-linux-free
firmware-linux-nonfree
firmware-misc-nonfree
firmware-realtek

[piratebab]

A part te conseiller de prendre les versions les plus récentes dans testing ou SID, mes compétences sur le sujet s'arrêtent là!

Toucher aux variables de config du bus par le kernel n'est pas encore dans mes compétences, ça fait bien longtemps que je n'y ai plus touché

[eheintzmann]

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 aussi la gestion dynamique de la carte additionnelle, la radeon restant allumée en permanence:

Code : Tout sélectionner

$ cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0

En utilisant le paramètre de boot amdgpu.runpm=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 Radeon — Sun XT / HAINAN, famille Southern Islands (SI).

[dezix]

Malheureusement cela désactive aussi la gestion dynamique de la carte additionnelle, la radeon restant allumée en permanence:

Bonjour,
ça n'a peut-être rien de commun mais j'ai un vague souvenir du même genre d'histoire avec portable ASUS optimus qui nécessite quelque-chose du style dumbelbee
si mon souvenir est correct il y avait 2 cartes vidéo une puissante et l'autre moins pour usage courant et le système devait permettre de passer de l'une à l'autre automatiquement,
sans-doute pour l'autonomie sur batterie.

[eheintzmann]

ça n'a peut-être rien de commun mais j'ai un vague souvenir du même genre d'histoire avec portable ASUS optimus qui nécessite quelque-chose du style dumbelbee
si mon souvenir est correct il y avait 2 cartes vidéo une puissante et l'autre moins pour usage courant et le système devait permettre de passer de l'une à l'autre automatiquement,
sans-doute pour l'autonomie sur batterie.

Tes souvenirs sont exacts, c'est exactement ça.
Malheureusement bumblebee ne concerne que les cartes Nvidia

[dezix]

Malheureusement bumblebee ne concerne que les cartes Nvidia

Dommage !... J'aurais tenté ma chance...

[piratebab]

Blumblebee et AMD rdeon, c'est un vieux sujet: https://github.com/Bumblebee-Project/Bu ... /issues/52
Aucune effos sur l'avancement.
Les drivers radeon ne supportent pas ces doubles cartes. Je vois passer des choses sur le driver fglrx qui le supporterait, essaie de voir de ce coté là si ce n'est pas déja fait.

[eheintzmann]

Merci pour le lien piratebab: c'est le genre de chose qui m'aide dans mes recherches.
Pour les drivers proprio, je les essaierai si je n'arrive pas à faire fonctionner correctement les drivers libres.
(En fait ils marchent, c'est juste ce temps de latence à la connexion qui est gênant)..
Mais je suis pas persuadé que ça viennent des drivers de la carte puisque que j'ai exactement les mêmes erreurs avec les drivers radeon et les nouveaux drivers officiels amdgpu.

Concernant le BIOS et les erreurs ACPI:

• Après de multiples relectures de mes logs, j’ai trouvé le message suivant :

  Code : Tout sélectionner

  kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

  En utilisant le paramètre de boot acpi_osi=Linux, le message devient :

  Code : Tout sélectionner

    kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query honored via cmdline

  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 :

  Code : Tout sélectionner

  kernel: ACPI: Added _OSI(Module Device)
  kernel: ACPI: Added _OSI(Processor Device)
  kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
  kernel: ACPI: Added _OSI(Processor Aggregator Device)
  kernel: ACPI: Added _OSI(Linux-Dell-Video)
  kernel: ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
  kernel: ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
  

  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.

[piratebab]

Quand on voit les explcations sur kernel.org
https://www.kernel.org/doc/html/v5.2/fi ... i/osi.html
ça ne donne pas envie de creuser.

[eheintzmann]

https://www.kernel.org/doc/html/v5.2/fi ... i/osi.html

Ce lien est bon début.
Reste le plus dur : trouver quels paramètres acpi_osi sont reconnus par mon BIOS et voir si un (ou plusieurs) de ces paramètres résout mon problème de latence.

[piratebab]

Tu as regardé dans /proc ? il y a quelques répertoires qui parlent d'acpi

[eheintzmann]

Il y a 2 fichiers sous /proc/acpi :
- button/lid/LID0/state
- wakeup

Ce dernier contient :

Code : Tout sélectionner

Device  S-state   Status   Sysfs node
P0P1      S4    *disabled
PS2K      S3    *enabled   pnp:00:02
PS2M      S3    *disabled  pnp:00:03
PEG0      S4    *enabled   pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEGA      S4    *disabled
EHC1      S3    *enabled   pci:0000:00:1d.0
EHC2      S3    *enabled   pci:0000:00:1a.0
XHC       S3    *enabled   pci:0000:00:14.0
HDEF      S0    *disabled  pci:0000:00:1b.0
RP01      S0    *enabled   pci:0000:00:1c.0
RP02      S4    *enabled   pci:0000:00:1c.1
PXSX      S5    *disabled  pci:0000:08:00.0
RP03      S0    *disabled  pci:0000:00:1c.2

Je ne vois pas la i915 mais la radeon est bien là (pci:0000:01:00.0).

[eheintzmann]

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:

Code : Tout sélectionner

# There is no DiplayPort on this laptop, remove from seats
SUBSYSTEM=="drm", KERNEL=="card0-DP-1", TAG-="seat", TAG-="master-of-seat"

# Remove radeon from seats
SUBSYSTEM=="drm", KERNEL=="card1", TAG-="seat", TAG-="master-of-seat"
SUBSYSTEM=="drm", KERNEL=="renderD129", TAG-="seat", TAG-="master-of-seat"

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)

[piratebab]

Une erreur pas simple à identifier!

[eheintzmann]

Dans le premier post de ce fil, 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 :

Code : Tout sélectionner

 
$ ls  -Al /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0A08\:00/device\:02/
total 0
-r--r--r--  1 root root 4096 avril 30 17:39 adr
drwxr-xr-x  3 root root    0 avril 30  2020 device:0b
drwxr-xr-x 13 root root    0 avril 30  2020 LNXVIDEO:00
-r--r--r--  1 root root 4096 avril 30 17:39 path
lrwxrwxrwx  1 root root    0 avril 30 17:39 physical_node -> ../../../../pci0000:00/0000:00:01.0
drwxr-xr-x  2 root root    0 avril 30 17:39 power
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D0
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D2
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D3hot
-r--r--r--  1 root root 4096 avril 30 17:39 power_state
-r--r--r--  1 root root 4096 avril 30 17:39 real_power_state
lrwxrwxrwx  1 root root    0 avril 30  2020 subsystem -> ../../../../../bus/acpi
-rw-r--r--  1 root root 4096 avril 30  2020 uevent
drwxr-xr-x  3 root root    0 avril 30  2020 wakeup

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 ?

[MicP]

Bonjour

Regarde dans les options du BIOS de ta machine
pour voir s'il n'y a pas quelques options modifiables concernant les cartes graphiques.