Un GPU qui tombe du bus...

Résolu/Fermé
sebcarp - Modifié le 19 août 2021 à 16:07
mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 - 20 août 2021 à 14:04
Bonjour à tout le monde !

Je rencontre un souci avec l'utilisation de Linux (quelle que soit la distribution) sur un mini-PC acheté récemment (Zotac ZBOX-ECM73070C).

L'installation se passe comme sur des roulettes, mais le système plante régulièrement (deux à trois fois par jour) et aléatoirement - sans élément déclencheur identifié (même si aucun logiciel n'est lancé et quand je ne travaille pas sur l’ordinateur).

L'écran se fige et ne répond plus au clavier et à la souris. Il est impossible de relancer la machine à l'aide du clavier : il faut éteindre l'ordinateur avec le bouton Marche/Arrêt, ou même parfois en débranchant le cordon d'alimentation...

Le fichier journal
/var/log/syslog
semble indiquer qu’au moment de la panne il y a un problème avec l'IRQ 16, qui causerait le plantage du GPU (ou inversement ?).

Voici un exemples de contenu :

    ​Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261271] NVRM: GPU at PCI:0000:01:00: GPU-cee20ff3-1d68-4aad-8fd6-5e23837374c1
Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261274] NVRM: Xid (PCI:0000:01:00): 79, pid=0, GPU has fallen off the bus.
Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261276] NVRM: GPU 0000:01:00.0: GPU has fallen off the bus.
Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261299] NVRM: A GPU crash dump has been created. If possible, please run
Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261299] NVRM: nvidia-bug-report.sh as root to collect this data before
Aug 6 08:53:35 sebastien-ZBOX-ECM73070C-53060C kernel: [31185.261299] NVRM: the NVIDIA kernel module is unloaded.
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108150] irq 16: nobody cared (try booting with the "irqpoll" option)
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108154] CPU: 11 PID: 0 Comm: swapper/11 Tainted: P W OE 5.4.0-80-generic #90-Ubuntu
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108154] Hardware name: ZOTAC ZBOX-ECM73070C/53060C/ZBOX-ECM73070C/53060C, BIOS 5.17 03/22/2021
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108155] Call Trace:
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108157] <IRQ>
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108162] dump_stack+0x6d/0x8b
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108164] __report_bad_irq+0x3a/0xaf
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108165] note_interrupt.cold+0xb/0x60
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108168] handle_irq_event_percpu+0x73/0x80
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108169] handle_irq_event+0x3b/0x60
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108170] handle_fasteoi_irq+0x9c/0x150
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108172] do_IRQ+0x55/0xf0
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108173] common_interrupt+0xf/0xf
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108174] </IRQ>
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108176] RIP: 0010:cpuidle_enter_state+0xc5/0x450
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108177] Code: ff e8 ff f5 84 ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 65 03 00 00 31 ff e8 62 fa 8a ff fb 66 0f 1f 44 00 00 <45> 85 ed 0f 88 8f 02 00 00 49 63 cd 4c 8b 7d d0 4c 2b 7d c8 48 8d
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108178] RSP: 0018:ffffaa1d00157e38 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108180] RAX: ffff8e8f024eadc0 RBX: ffffffff98169380 RCX: 000000000000001f
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108180] RDX: 0000000000000000 RSI: 000000002c13b729 RDI: 0000000000000000
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108181] RBP: ffffaa1d00157e78 R08: 00001c5d5080911d R09: 000000007fffffff
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108181] R10: ffff8e8f024e9ac0 R11: ffff8e8f024e9aa0 R12: ffff8e8eecd72400
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108182] R13: 0000000000000001 R1indique4: 0000000000000001 R15: ffff8e8eecd72400
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108184] ? cpuidle_enter_state+0xa1/0x450
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108186] cpuidle_enter+0x2e/0x40
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108188] call_cpuidle+0x23/0x40
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108189] do_idle+0x1dd/0x270
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108190] cpu_startup_entry+0x20/0x30
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108192] start_secondary+0x167/0x1c0
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108194] secondary_startup_64+0xa4/0xb0
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108195] handlers:
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108199] [<0000000095957362>] i801_isr [i2c_i801]
Aug 6 08:53:37 sebastien-ZBOX-ECM73070C-53060C kernel: [31187.108200] Disabling IRQ #16


Voici les deux processus qui se partagent l’IRQ 16 sur le système (obtenus grâce à la commande lspci -nnkv) :
  • Non-Volatile memory controller [0108]: Sandisk Corp Device [15b7:5011] (rev 01) (prog-if 02 [NVM Express])
    ;
  • Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. Device [10ec:3000] (rev 03)
    ;


J’ai essayé plusieurs méthodes pour résoudre la panne, en m’inspirant de suggestions glanées sur internet :
  • Test avec plusieurs distributions Linux (Manjaro KDE mais aussi Mint Cinnamon, Kubuntu...) ;
  • Test avec plusieurs versions des pilotes propriétaires Nvidia ;
  • Installation du noyau stable Linux le plus récent ;
  • Mise à jour du Bios avec la version la plus récente proposée par Zotac ;
  • Carte Nvidia mise en mode persistant à l’aide de
    sudo nvidia-smi -pm 1
    ;
  • Lancement d’un test Memtest86 pour vérifier la RAM (aucun souci détecté) ;
  • Désactivation dans le BIOS du mode « Turbo » et de la prise en charge de l’hibernation ;
  • Création d’un fichier
    /etc/modprobe.d/nvidia.conf
    avec comme contenu :
    options nvidia "NVreg_DynamicPowerManagement=0x02"
    , puis lancement d’un
    update-initramfs -u
    .
  • Édition du fichier
    /etc/default/grub
    puis mise à jour du grub pour intégrer les options suivantes au kernel (jamais ensemble, toujours séparément) :
    • pcie_aspm=off
    • pci=noaer
    • pci=nomsi
    • irqpoll
    • nvme_core.default_ps_max_latency_us=0
    • processor.max_cstate=1
    • rcutree.rcu_idle_gp_delay=1 acpi_osi=! acpi_osi='Windows 2009'
    • rcutree.rcu_idle_gp_delay=1 acpi_osi=! acpi_osi='Linux'
    • nouveau.modeset=0 nvidia-drm.modeset=0
    • intel_idle.max_cstate=1


Est-ce que vous avez des pistes pour m'aider à résoudre ce problème ?...

Merci d'avance pour vos lumières !

Sébastien

3 réponses

Bonjour,
Je vois que tu n'as pas essayé l'option "nomodeset"
Et avec le pilote libre (nouveau) qu'est-ce que ça donne ? même si les performances ne sont pas au rendez-vous.
Qu'en est-il de l'utilisation de la ram ? tu as une partition de swap ?
0
Bonjour et merci pour la réponse !

J'ai testé avec et sans partition de swap, sans que ça ait un impact.

J'avais aussi testé avec "nomodeset", sans succès.

Par contre, je n'ai pas essayé avec le pilote libre. Mais je tiens à garder les performances du pilote propriétaire...
0
"Par contre, je n'ai pas essayé avec le pilote libre."
C'est surtout un moyen de cerner l'origine du problème... En principe le pilote libre est installé par défaut.
Si ça fonctionne avec le pilote libre, tu sauras que le problème est lié au pilote de la CG.
Surveille l'utilisation de la ram : lorsque qu'elle est saturée, le système se fige.
0
Mon problème est résolu, et je tenais à expliquer comment j'avais procédé - au cas où d'autres personnes y seraient confrontées à l'avenir...

Il semble qu'il s'agisse d'un conflit d'IRQ entre les contrôleurs USB et la carte graphique.
Après avoir intégré l'option
acpi=debug
dans les paramètres de grub, je n'ai plus rencontré aucun crash du système.

J'ai eu l'idée de tester cette solution après avoir consulté cette page (en allemand).

Dans tous les cas, merci à jns55 pour ses réponses !
0
Merci du retour.
Bizarre comme solution dans la mesure où l'option acpi=debug ne semble pas exister dans la documentation du kernel...
Options disponibles pour acpi :
acpi= [HW,ACPI,X86,ARM64]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
copy_dsdt }
force -- enable ACPI if default was off
on -- enable ACPI but allow fallback to DT [arm64]
off -- disable ACPI if default was on
noirq -- do not use ACPI for IRQ routing
strict -- Be less tolerant of platforms that are not
strictly ACPI specification compliant.
rsdt -- prefer RSDT over (default) XSDT
copy_dsdt -- copy DSDT to memory
For ARM64, ONLY "acpi=off", "acpi=on" or "acpi=force"
are available

https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html?highlight=kernel+parameters
Mais si ça te permet de solutionner ton problème tant mieux.
0
Encore le bot de ccm qui a viré ma réponse. Aucune idée du pourquoi. Si on ne peut plus parler de l'acpi sans être censuré !
Un modo pour la rétablir ?
0
mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 7 802 > jns55
19 août 2021 à 16:19
Bonjour,

@ jns55: Visiblement quelqu'un a été plus rapide que moi car je ne vois pas de message filtrés et écrits par toi. Ah, et moi non plus, je ne connaissais pas non plus
acpi=debug
. C'est assez étonnant, elle n'est documentée nulle part, or j'imagine que grub ou le noyau aurait râlé si une valeur invalide avait été passée ?

@sebcarp: Plus que la distribution, il aurait été intéressants de voir les noyaux incriminés, et au besoin de remonter le bug et la technique pour contourner le problème... En tout cas merci d'avoir indiqué comment tu avais procédé pour résoudre le problème.

Bonne continuation
0
jns55 > mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024
Modifié le 19 août 2021 à 18:21
"j'imagine que grub ou le noyau aurait râlé si une valeur invalide avait été passée ?"

Peut-être dans les logs mais au démarrage ça ne se voit pas lors d'un démarrage graphique. J'ai essayé de passer la chaîne "xxxx" au kernel en éditant la page de démarrage de grub. Aucun message d'erreur n'apparaît et le système a démarré normalement.
Je pense que l'explication donnée dans le lien de sbcarp tient la route et que le résultat pourrait être le même avec n'importe quelle chaîne de caractères : le temps mis à traiter le paramètre suffit à décaler légèrement l'enchaînement des opérations. (si sbcarp veut tenter l'expérience)
0
mamiemando Messages postés 33381 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 26 novembre 2024 7 802 > jns55
20 août 2021 à 14:04
Je pense que l'explication donnée dans le lien de sbcarp tient la route et que le résultat pourrait être le même avec n'importe quelle chaîne de caractères.

C'est ce que je suspecte également.

Le temps mis à traiter le paramètre suffit à décaler légèrement l'enchaînement des opérations.

Oui, ou déclencher un comportement par défaut autre que celui qui aurait été déclenché sans chaîne de caractères. C'est très étrange en tout cas :-)
0