# Erreur ACPI avec une radeon sur un PC Intel **URL:** \ **Category:** Support Debian\ **Tags:** bulleyes\ **Created:** [Avril 17, 2020, 1:51 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819 "2020-04-17T13:51:49Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 17, 2020, 1:51 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/1 "2020-04-17T13:51:50Z")
Bonjour à tous, # PC sous Debian testing Je possède un ordinateur portable [HP Pavilion 17-e050sf](https://support.hp.com/fr-fr/document/c03817695) 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). ```auto 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 : ```auto 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 ... ``` ```auto 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 : ```auto 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 ```auto 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 : ```auto ls /sys/bus/acpi/devices/device\:02/physical_node 0000:00:01.0:pcie010 0000:01:00.0 ... ``` ```auto 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 : ```auto cat /sys/bus/acpi/devices/device\:02/power_state (unknown) ``` ```auto 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 » ```auto 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: ```auto 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 ```auto 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. a ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Avril 17, 2020, 2:56 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/2 "2020-04-17T14:56:35Z")
le choix de la carte graphique n’est-il pas fait en fonction de l’alimentation du pc sur secteur ou batterie? As tu essaye les deux cas? - démarrage alimentation secteur - démarrage alimentation batterie ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 17, 2020, 5:43 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/3 "2020-04-17T17:43:43Z")
Le choix de la carte graphique est fait par les technologies du kernel : [DRI PRIME](https://doc.fedora-fr.org/wiki/Prime) et [VGA Switcheroo](https://www.kernel.org/doc/html/v5.6/gpu/vga-switcheroo.html): En pratique on peut choisir la carte graphique à utiliser en réglant la variable DRI\_PRIME à 0 ou 1. Par exemple : ```auto $ DRI_PRIME=0 es2_info | grep -i renderer GL_RENDERER: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2) ``` Alors que ```auto $ DRI_PRIME=1 es2_info | grep -i renderer GL_RENDERER: AMD HAINAN (DRM 2.50.0, 5.5.0-1-amd64, LLVM 10.0.0) ``` L’état des cartes graphiques peut-être contrôlé par un simple fichier : ```auto $ cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynOff:0000:01:00.0 ``` Je vais vérifier que le fait d’être sur batterie ne change pas la donne. ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 21, 2020, 9:25 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/4 "2020-04-21T21:25:28Z")
Si je démarre le PC avec le paramètre [« radeon.runpm=0 »](https://www.kernel.org/doc/html/v5.5/gpu/vga-switcheroo.html#driver-power-control), 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: ```auto $ cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :Pwr:0000:01:00.0 ``` ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 21, 2020, 11:15 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/5 "2020-04-21T23:15:07Z")
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 carte Radeon — Sun XT / HAINAN, famille Southern Islands (SI). ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 25, 2020, 4:23 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/6 "2020-04-25T04:23:32Z")
- Après de multiples relectures de mes logs, j’ai trouvé le message suivant : - De plus, il y a ces autres messages dans les logs : 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. ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 29, 2020, 9:58 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/7 "2020-04-29T09:58:16Z")
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: ```auto # 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) ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Avril 29, 2020, 11:55 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/8 "2020-04-29T11:55:38Z")
Simplement pour info, es tu en Xorg ou en Wayland? J’utilise Gnome/Xorg et SDDM ```auto journalctl | grep display avril 29 12:31:20 debian sddm[3437]: Adding new display on vt 7 ... avril 29 12:31:20 debian sddm[3437]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{ee2ee363-01b9-46cb-b9f0-35ae1cca9dad} -background none -noreset -displayfd 17 -seat seat0 vt7 avril 29 12:31:32 debian sddm[3437]: Running display setup script "/usr/share/sddm/scripts/Xsetup" ``` ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 29, 2020, 1:05 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/9 "2020-04-29T13:05:36Z")
Habituellement j’utilise GNOME / Wayland lancé par GDM. Mais pour comprendre ce bug j’ai tout testé GNOME / [X.Org](http://X.Org), Enlightenment, Xfce lancé par GDM (sous Wayland et sous [X.org](http://X.org)) ou lightdm( sous [X.Org](http://X.Org)). Le VT switching pose problème dans toutes les configurations. À l’occasion j’essaierai SDDM aussi. ---
**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\ **Post date:** [Avril 29, 2020, 1:32 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/10 "2020-04-29T13:32:36Z")
je dirai plutôt que c’est ta configuration graphique. j’utilise le noyau 5.6 d’experimental ```auto uname --all Linux debian 5.6.0-trunk-amd64 #1 SMP Debian 5.6.4-1~exp1 (2020-04-17) x86_64 GNU/Linux ``` je n’ai pas de pb acpi ```auto lspci -nnk | grep -i vga -A2 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] [1002:9712] DeviceName: 256 Subsystem: Hewlett-Packard Company RS880M [Mobility Radeon HD 4225/4250] [103c:1443] 02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] [1002:68e0] Subsystem: Hewlett-Packard Company Park [Mobility Radeon HD 5430/5450/5470] [103c:1443] Kernel driver in use: radeon ``` ```auto journalctl -p err -- Logs begin at Wed 2020-04-29 14:52:06 CEST, end at Wed 2020-04-29 15:26:52 CEST. -- avril 29 14:52:06 debian kernel: do_IRQ: 1.55 No irq handler for vector avril 29 14:52:16 debian kernel: Bluetooth: hci0: command 0x1009 tx timeout avril 29 14:52:24 debian smartd[3995]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 57 [> avril 29 14:52:27 debian wpa_supplicant[3998]: bgscan simple: Failed to enable signal strength monitoring avril 29 14:52:32 debian kernel: Bluetooth: hci0: unexpected event for opcode 0x1009 avril 29 14:52:32 debian bluetoothd[3978]: Sap driver initialization failed. avril 29 14:52:32 debian bluetoothd[3978]: sap-server: Operation not permitted (1) avril 29 15:22:25 debian smartd[3995]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 68 [> ``` ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 30, 2020, 2:19 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/11 "2020-04-30T02:19:30Z")
Au niveau de la config graphique j’ai essayé beaucoup de choses: - 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_), à la main (_startx_) J’ai tenté d’utiliser un fichier monitors.xml avec GDM. - Au niveau de la console, j’ai tenté de changer de mode graphique, depuis grub: ```auto #/etc/default/grub GRUB_GFXMODE=1600x900x32 GRUB_GFXPAYLOAD_LINUX=1600x900x32 ``` - 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) ---
**Author:** ![eheintzmann](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/67e7ee/32.png) [@eheintzmann](https://www.debian-fr.org/u/eheintzmann)\ **Post date:** [Avril 30, 2020, 5:21 UTC](https://www.debian-fr.org/t/erreur-acpi-avec-une-radeon-sur-un-pc-intel/81819/12 "2020-04-30T17:21:40Z")
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 : ```auto $ 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 ?