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
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
A voir également:
- Un GPU qui tombe du bus...
- Controleur de bus sm ✓ - Forum Windows 10
- Sms bus - Guide
- Contrôleur de bus sm ✓ - Forum Pilotes (drivers)
- Gpu 0 3d - Forum Carte graphique
- A d3d11-compatible gpu (feature level 11.0 shader model 5.0) is required to run the engine - Forum Jeux PC
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 ?
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 ?
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...
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...
"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.
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.
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
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 !
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=debugdans 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 !
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.
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.
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
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
@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
@ 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
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
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)
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)
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
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 :-)
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 :-)