Quand je parlais de l'UEFI, regarde dans le premier post de ce fil ce qui avait du être fait pour arriver à installer un Linux sur une machine de ce genre.
Dans le lien ci-dessus, il s'agit d'une autre machine, mais la démarche doit sans doute être sensiblement la même,
parce que même si les fichiers firmwares sont indispensables pour faire fonctionner certains périphériques,
encore faut-il que l'UEFI et le BIOS en permettent l'accès.
=======
Et comme il s'agit dune machine très récente, il se peut aussi qu'une nouvelle version du BIOS viennent corriger certains bugs.
Bumblebee-nvidia, et freeze au boot Le sujet est résolu
- Dunatotatos
- Membre
- Messages : 426
- Inscription : 11 mai 2016, 20:56
- Status : Hors-ligne
Wow, je ne pensais pas avoir un tel support ! Merci à tous pour votre aide :)
Par le passé, j'ai fait quelques recherches pour vois si d'autres personnes avaient les mêmes soucis (voir les liens postés précédemment), mais rien de concluant n'en est sorti. À part les options lors de la compilation du noyau (que je n'ai pas encore tentée).
Concernant l'installation de testing directement sans passer par stable, j'ai fait la même chose avec l'UEFI. C'était un choix stratégique, pensant que testing était plus à jour que stable et avait donc avait plus de chance de supporter du matériel récent. Je persiste dans ce choix pour ce message, mais si j'ai toujours des problèmes, je peux tenter une installation de stable.
Pour l'installation de Bumblebee, je ne suis pas un tuto en particulier. J'installe juste bumblebee-nvidia sur un système fraîchement installé, et je redémarre. Est-ce une erreur ?
Voici les tentatives du jour :
J'ai mis à jour le bios de E16K4IMS.103 à E16K4IMS.108
J'ai changé les options du bios pour correspondre au lien donné par MicP :
Lorsque l'installateur m'indique des des microcodes sont manquants, je lui donne une clef USB avec différents contenus.
Au démarrage, je fais les mises à jour, installe linux-misc-nonfree, copie les fichiers pour supprimer les erreurs de firmwares manquants pour ath10k, redémarre, arrête le serveur X, installe bumblebee-nvidia, redémarre, et ça bloque encore.
J'ai essayé d'ajouter les drapeaux nouveau.blacklist=1 et acpi=off dans Grub. Le système démarre jusqu'à l'interface graphique, mais le touchpad ne fonctionne pas, et le module nvidia-driver n'est même pas chargé.
EDIT : J'essaie de forcer un peu cette installation qui démarre. J'ai installé mesa-utils pour avoir accès à glxgears et glxinfo. J'ai chargé le module nvidia-current, re-démarré le service bumblebeed, puis ai lancé glxgears (qui fonctionne), puis optirun glxgears (qui rend la main sans rien afficher, ni message dans la console, ni fenêtre avec une roue qui tourne). Par contre, si je regards la sortie de dmesg en même temps, j'ai ces messages :
Dans l'état actuel des choses, c'est l'option "acpi=off" qui fait al différence entre un système qui plante au démarrage, ou qui démarre, mais sans pouvoir utiliser la carte nvidia.
EDIT 2 : Un petit résultat intéressant : j'ai supprimé tous les paquets nvidia-*, ainsi que bumblebee-nvidia, et ai réinstallé bumblebee tout court (pour utiliser le driver nouveau). Et là encore, le système plante au démarrage.
Par le passé, j'ai fait quelques recherches pour vois si d'autres personnes avaient les mêmes soucis (voir les liens postés précédemment), mais rien de concluant n'en est sorti. À part les options lors de la compilation du noyau (que je n'ai pas encore tentée).
Concernant l'installation de testing directement sans passer par stable, j'ai fait la même chose avec l'UEFI. C'était un choix stratégique, pensant que testing était plus à jour que stable et avait donc avait plus de chance de supporter du matériel récent. Je persiste dans ce choix pour ce message, mais si j'ai toujours des problèmes, je peux tenter une installation de stable.
Pour l'installation de Bumblebee, je ne suis pas un tuto en particulier. J'installe juste bumblebee-nvidia sur un système fraîchement installé, et je redémarre. Est-ce une erreur ?
Voici les tentatives du jour :
J'ai mis à jour le bios de E16K4IMS.103 à E16K4IMS.108
J'ai changé les options du bios pour correspondre au lien donné par MicP :
- Dans l'onblet Boot:
- Fast Boot: disabled
- Boot mode select: Legacy
- Dans l'onglet Avanced:
- PCI Latency Timer: J'ai pas
- Intel SpeedStep: Disabled
- Super Charger: J'ai pas
- ERP: J'ai pas
- Intel Virtualization: Disabled (le tuto précédemment mentionné indique qu'on peut le laisser actif)
- VT-d: Disabled
- Hyper-threading: Disabled
- CPU C states: Disabled
Lorsque l'installateur m'indique des des microcodes sont manquants, je lui donne une clef USB avec différents contenus.
- http://cdimage.debian.org/cdimage/unoff ... are.tar.gz ne lui convient pas (même message après avoir scanné la clef)
- firware-misc-nonfree_20161130-3_all.deb ne convient pas non plus (toujours le même message)
- linux-firmware_1.157.11_all.deb semble convenir en partie. Il reste trois fichiers manquants, les mêmes que lors des précédentes installations
- ath10k/pre-cal-pci-0000:3e:00.0.bin
- ath10k/cal-pci-0000:3e:00.0.bin
- ath10k/QCA6174/hw3.0/firmware-5.bin
Au démarrage, je fais les mises à jour, installe linux-misc-nonfree, copie les fichiers pour supprimer les erreurs de firmwares manquants pour ath10k, redémarre, arrête le serveur X, installe bumblebee-nvidia, redémarre, et ça bloque encore.
J'ai essayé d'ajouter les drapeaux nouveau.blacklist=1 et acpi=off dans Grub. Le système démarre jusqu'à l'interface graphique, mais le touchpad ne fonctionne pas, et le module nvidia-driver n'est même pas chargé.
EDIT : J'essaie de forcer un peu cette installation qui démarre. J'ai installé mesa-utils pour avoir accès à glxgears et glxinfo. J'ai chargé le module nvidia-current, re-démarré le service bumblebeed, puis ai lancé glxgears (qui fonctionne), puis optirun glxgears (qui rend la main sans rien afficher, ni message dans la console, ni fenêtre avec une roue qui tourne). Par contre, si je regards la sortie de dmesg en même temps, j'ai ces messages :
Code : Tout sélectionner
[...] NVRM: failed to register with the ACPI subsystem!
[...] vgaarb: this pci device is not a vga device
[...] vgaarb: this pci device is not a vga device
[...] glxgears[1767]: segfault at 0 ip 00007f68aa3ae292 sp 00007ffc72ed2450 error 4 in libGL.so.1[7f68aa389000+41000]
[...] NVRM: failed to unregister from the ACPI subsystem!
EDIT 2 : Un petit résultat intéressant : j'ai supprimé tous les paquets nvidia-*, ainsi que bumblebee-nvidia, et ai réinstallé bumblebee tout court (pour utiliser le driver nouveau). Et là encore, le système plante au démarrage.
- Dunatotatos
- Membre
- Messages : 426
- Inscription : 11 mai 2016, 20:56
- Status : Hors-ligne
Dans /etc/bumblebee/bumblebee.conf, dans la section [driver-nouvea], j'ai changé PMMethod=auto en PMMethod=none, et mon l'interface graphique démarre !
Le souci n'est pas totalement résolu parce-que optirun renvoie encore une erreur :
Mais cette erreur est bien plus répandue et plus facile à débugguer sans blocage complet de l'ordi :D
Je tente de réparer ce dernier souci, puis je garde PMMethod=None jusqu'à ce qu'une mise à jour de bbswitch et/ou du noyau résolve le problème du blocage.
EDIT : J'ai réinstallé bumblebee-nvidia, changé la configuration dans /etc/bumblebee/bumblebee.conf, redémarré l'ordi pour blacklister nouveau, et là,
EDIT 2 : Je ne passe pas encore en résolu parce-qu'il y a encore ce souci de PMMethod à None, et je veux écrire un article sur le wiki pour détailler le process. Tant que je laisse mon portable branché sur secteur, avoir la carte graphique sous tension n'est pas vraiment un souci. C'est juste dommage de ne pas profiter de cet avantage sur du plus long terme. Peut-être qu'il y a moyen de réparer ça en passant par un acpi_call à la place de bbswitch. Ou de soumettre le problème aux dev de bbswitch directement.
Mais là, je pars en week-end jusqu'à vendredi midi.
Merci beaucoup à tous pour votre aide
Le souci n'est pas totalement résolu parce-que optirun renvoie encore une erreur :
Code : Tout sélectionner
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0)
Je tente de réparer ce dernier souci, puis je garde PMMethod=None jusqu'à ce qu'une mise à jour de bbswitch et/ou du noyau résolve le problème du blocage.
EDIT : J'ai réinstallé bumblebee-nvidia, changé la configuration dans /etc/bumblebee/bumblebee.conf, redémarré l'ordi pour blacklister nouveau, et là,

Code : Tout sélectionner
$ optirun glxgears
310 frames in 5.0 seconds = 61.843 FPS
Mais là, je pars en week-end jusqu'à vendredi midi.
Merci beaucoup à tous pour votre aide

- PengouinPdt
- Contributeur
- Messages : 1343
- Inscription : 23 avr. 2016, 23:37
- Localisation : 47/FR
- Diaspora* : https://framasphere.org/u/hucste
- Contact :
- Status : Hors-ligne
Donc, si je comprends bien, tu cherches à utiliser Bumblebee avec le pilote 'nouveau', n'est-ce pas ?Dunatotatos a écrit : 08 juin 2017, 15:01 Dans /etc/bumblebee/bumblebee.conf, dans la section [driver-nouvea], j'ai changé PMMethod=auto en PMMethod=none, et mon l'interface graphique démarre !
(...)
Si c'est le cas, éEtant donné le fait que ton PC soit récent, je ne suis pas du tout surpris des problèmes que tu rencontres...
Et, sinon, je repose la question : as-tu lu les tutoriels que je t'ai mentionné ? (sinon à quoi ça sert que Ducros se décarcasse à créer ou à collaborer) - juste comme cela au cas où, hein !?...
----
Concernant la gestion de l'accélération vidéo des cartes nvidia par le pilote nouveau, lire la page suivante : https://nouveau.freedesktop.org/wiki/VideoAcceleration/
Bref, si ta carte n'est pas nommée, oublies et utilises Bumblebee avec le pilote privatif nvidia ! <= ceci n'est pas du tout une suggestion, c'est un impératif !
Faut que je rajoute un laïus à ce propos sur les tutoriels sus-nommées ;)
PengouinPdt { le seul, le vrai } ~ " Libre as a Pengouin "
- DIY - Debian Sid | Devuan Ceres
----
Ne réponds pas aux PM d'assistance
- DIY - Debian Sid | Devuan Ceres
----
Ne réponds pas aux PM d'assistance
- Dunatotatos
- Membre
- Messages : 426
- Inscription : 11 mai 2016, 20:56
- Status : Hors-ligne
Non. Je souhaite utiliser les pilotes propriétaires, mais ai tenté cette configuration pour voir si le souci de blocage venait du pilote nvidia ou d'autre part. Le fait que le noyau bloque aussi avec nouveau m'a fait supposé que le problème était autre part.PengouinPdt a écrit : 08 juin 2017, 17:18Donc, si je comprends bien, tu cherches à utiliser Bumblebee avec le pilote 'nouveau', n'est-ce pas ?
Non, je ne les ai pas lu. Du moins pas récemment. J'ai utilisé la page de notre wiki il y a quelques temps quand j'avais des soucis pour faire fonctionner un précédent portable lui aussi doté de la technologie Optimus. Mais pas depuis. Alors pour faire plaisir à Ducros, je vais les lire de ce pas, et éventuellement y découvrir la pépite qu'il me manque.Et, sinon, je repose la question : as-tu lu les tutoriels que je t'ai mentionné ? (sinon à quoi ça sert que Ducros se décarcasse à créer ou à collaborer) - juste comme cela au cas où, hein !?...
-
- Messages : 4
- Inscription : 01 oct. 2017, 13:08
- Status : Hors-ligne
Ahhhhh, merci !!
Ca fait un moment que je galère avec mon portable MSI GL62 (6QD-027XFR). Freezes dans de nombreuses situations, selon les mises à jour, au démarrage, aléatoirement, ...
Je suis sous Buster avec Bumblebee et le driver propriétaire de Nvidia. Ca marchait pas trop mal depuis quelques mois, à part quelques freezes de temps en temps au boot et certains programmes à éviter, jusqu'au dernier upgrade (pas fait depuis 2 semaines). Kernel panic au boot...
Même conclusion que toi, j'ai désactivé l'ACPI (option du kernel acpi=off) permet de booter, mais sans touchpad et autres fonctions acpi. La souris usb fonctionnait, mais un portable sans acpi c'est pas viable.
Du coup, mille fois merci pour cette info qui permet de savoir que c'est bbswitch qui plante le boot. J'ai réussi à démarrer avec l'acpi en mettant PPMethod=none dans /etc/bumblebee/bumblebee.conf.
Mais sans bbswitch, la carte est tout le temps ON. J'aimerais quand même bien résoudre le problème pour quand je suis sur batterie.
Ce qui était étonnant, c'est qu'après le boot, je pouvais l'utiliser en le lançant à la main :
Par ailleurs, j'ai reproduit le même plantage que quand PPMethod=bbswitch au boot en laissant PPMethod=none et en ajoutant bbswitch à /etc/modules qui le charge automatiquement au démarrage.
Ca n'est pas l'interaction avec le power management des ports pcie car le désactiver (option du kernel pcie_port_pm=off) ne résout pas le problème.
En attendant une meilleure idée, ou une mise-à-jour, j'ai désactivé le service bumblebeed (update-rc.d bumblebeed disable) et j'ai créé un démarrage "manuel automatisé" dans /etc/rc.local avec :
Et ça marche (ne pas oublier de changer les permission à 755 si vous créez le rc.local).
Visiblement bbswitch ou une dépendance est lancé trop tôt dans le processus d'init, c'est la seule manière que j'ai trouvé pour lancer bumblebee plus tard (rc-local est lancé tout en dernier). J'ai aussi essayé de changer sa priorité avec init en augmentant NN dans /etc/rcX.d/SNNbumblebeed mais ça n'a pas résolu le problème (je sais même pas si systemd l'a pris en compte).
Ca fait un moment que je galère avec mon portable MSI GL62 (6QD-027XFR). Freezes dans de nombreuses situations, selon les mises à jour, au démarrage, aléatoirement, ...
Je suis sous Buster avec Bumblebee et le driver propriétaire de Nvidia. Ca marchait pas trop mal depuis quelques mois, à part quelques freezes de temps en temps au boot et certains programmes à éviter, jusqu'au dernier upgrade (pas fait depuis 2 semaines). Kernel panic au boot...

Même conclusion que toi, j'ai désactivé l'ACPI (option du kernel acpi=off) permet de booter, mais sans touchpad et autres fonctions acpi. La souris usb fonctionnait, mais un portable sans acpi c'est pas viable.
Du coup, mille fois merci pour cette info qui permet de savoir que c'est bbswitch qui plante le boot. J'ai réussi à démarrer avec l'acpi en mettant PPMethod=none dans /etc/bumblebee/bumblebee.conf.
Mais sans bbswitch, la carte est tout le temps ON. J'aimerais quand même bien résoudre le problème pour quand je suis sur batterie.
Ce qui était étonnant, c'est qu'après le boot, je pouvais l'utiliser en le lançant à la main :
Code : Tout sélectionner
$ modprobe bbswitch
$ nano /etc/bumblebee/bumblebee.conf (mettre PPMethod=bbswitch)
$ service bumblebee start/restart
$ cat /proc/acpi/bbswitch
0000:01:00.0 OFF
$ optirun glxgears&
$ cat /proc/acpi/bbswitch
0000:01:00.0 ON
$ killall glxgears
$ cat /proc/acpi/bbswitch
0000:01:00.0 OFF
Ca n'est pas l'interaction avec le power management des ports pcie car le désactiver (option du kernel pcie_port_pm=off) ne résout pas le problème.
En attendant une meilleure idée, ou une mise-à-jour, j'ai désactivé le service bumblebeed (update-rc.d bumblebeed disable) et j'ai créé un démarrage "manuel automatisé" dans /etc/rc.local avec :
Code : Tout sélectionner
#!/bin/sh
service bumblebeed start
exit 0

Visiblement bbswitch ou une dépendance est lancé trop tôt dans le processus d'init, c'est la seule manière que j'ai trouvé pour lancer bumblebee plus tard (rc-local est lancé tout en dernier). J'ai aussi essayé de changer sa priorité avec init en augmentant NN dans /etc/rcX.d/SNNbumblebeed mais ça n'a pas résolu le problème (je sais même pas si systemd l'a pris en compte).
- Dunatotatos
- Membre
- Messages : 426
- Inscription : 11 mai 2016, 20:56
- Status : Hors-ligne
Salut Will, et bienvenue sur le forum !
Merci pour les infos supplémentaires. (En particulier le fait que lancer bumblebeed après le démarrage ne fait pas crasher le système !)
J'espérais qu'une mise à jour corrige rapidement ce bug, mais rien n'arrive. Je pense qu'un rapport de bug est nécessaire. Je m'en charge dans ~une semaine et vous tiens au courant dans ce fil.
Merci pour les infos supplémentaires. (En particulier le fait que lancer bumblebeed après le démarrage ne fait pas crasher le système !)
J'espérais qu'une mise à jour corrige rapidement ce bug, mais rien n'arrive. Je pense qu'un rapport de bug est nécessaire. Je m'en charge dans ~une semaine et vous tiens au courant dans ce fil.
-
- Messages : 1
- Inscription : 10 mai 2018, 21:55
- Status : Hors-ligne
Hello tout le monde!
Alors merci et bravo car j'ai passé une journée entière sur Debian / Ubuntu / Arch avec ce problème qui était similaire sur toutes ces distributions.
Pour information, j'ai eu donc le même souci sur un DELL XPS 9560.
L'astuce de @Dunatotatos et @Will (avec le rc.local) fonctionne bien, il m'a fallu faut tout de même rajouter une option dans grub ("acpi_osi=") car mon système se figeait lorsque j’exécutais la commande > lspci (alors que optirun fonctionnait correctement). Sans cette option et PPMethod à none, plus de soucis non plus avec la commande lspci, ce qui confirme toujours la même source du problème => bbswitch, même démarré à un moment ultérieur au boot.
Vu que je trouve des fil de discussions (notamment sur github -> https://github.com/Bumblebee-Project/Bu ... issues/764 ) à ce propos, que aucun guide ne détaille vraiment le problème et que je ne vois pas de ticket ouvert sur https://bugs.debian.org/cgi-bin/pkgrepo ... witch-dkms , je m'apprête à faire un peu de rédaction autour de ça!
Merci encore, car c'est grâce à vous que je peux continuer à mettre en place mon GPU Passthrough en utilisant Intel GVT-G et QUEMU.
Alors merci et bravo car j'ai passé une journée entière sur Debian / Ubuntu / Arch avec ce problème qui était similaire sur toutes ces distributions.
Pour information, j'ai eu donc le même souci sur un DELL XPS 9560.
L'astuce de @Dunatotatos et @Will (avec le rc.local) fonctionne bien, il m'a fallu faut tout de même rajouter une option dans grub ("acpi_osi=") car mon système se figeait lorsque j’exécutais la commande > lspci (alors que optirun fonctionnait correctement). Sans cette option et PPMethod à none, plus de soucis non plus avec la commande lspci, ce qui confirme toujours la même source du problème => bbswitch, même démarré à un moment ultérieur au boot.
Vu que je trouve des fil de discussions (notamment sur github -> https://github.com/Bumblebee-Project/Bu ... issues/764 ) à ce propos, que aucun guide ne détaille vraiment le problème et que je ne vois pas de ticket ouvert sur https://bugs.debian.org/cgi-bin/pkgrepo ... witch-dkms , je m'apprête à faire un peu de rédaction autour de ça!
Merci encore, car c'est grâce à vous que je peux continuer à mettre en place mon GPU Passthrough en utilisant Intel GVT-G et QUEMU.
- Dunatotatos
- Membre
- Messages : 426
- Inscription : 11 mai 2016, 20:56
- Status : Hors-ligne
Salut 3KyNoX, et bienvenue sur le forum.
Merci pour ton retour. N'hésite pas à partager ici ton futur travail sur le sujet. J'ai toujours le même ordinateur portable avec le même souci, et n'ai toujours pas créer de rapport de bug. Travail, quand tu nous tient...
Merci pour ton retour. N'hésite pas à partager ici ton futur travail sur le sujet. J'ai toujours le même ordinateur portable avec le même souci, et n'ai toujours pas créer de rapport de bug. Travail, quand tu nous tient...
-
- Messages : 4
- Inscription : 01 oct. 2017, 13:08
- Status : Hors-ligne
Salut !
Content que ça t'ai été utile, c'est un vrai casse-tête.
Je me tâtais à faire un upgrade du système, mais d'après ce que tu racontes, le bug semble être d'actualité. Je crois que je vais procrastiner mon upgrade... (souvent elles font péter ma config locale et j'en ai pour une journée ou plus de débogage).
On se tient au courant s'il y a du nouveau.
Content que ça t'ai été utile, c'est un vrai casse-tête.
Je me tâtais à faire un upgrade du système, mais d'après ce que tu racontes, le bug semble être d'actualité. Je crois que je vais procrastiner mon upgrade... (souvent elles font péter ma config locale et j'en ai pour une journée ou plus de débogage).
On se tient au courant s'il y a du nouveau.
-
- Membre
- Messages : 11
- Inscription : 03 juil. 2017, 14:01
- Status : Hors-ligne
j'avais le même soucis mais sur mon pc Toshiba avec technologie Optimus.
ma Nvidia est très mal gérée par nouveau, elle tourne en permanence, chauffe du pc, tearing, blocage complet, et crash au reboot avec écran noir.
l'installation des pilotes Nvidia a longtemps été un casse tete, avec blocage du pc, écran noir après le chargement de Lightdm.
que ce soit sur ubuntu, mint, debian ou fedora (prime ou bumblebee même résultat)
seul archlinux arrivait a tout faire tourner correctement, mais arch avait d'autres soucis de stabilité donc pas top sur le long terme..
comme j'aime ma debian, je suis revenue dessus mais avec une autre technique d'approche.
au lieu d'installer Cinnamon via l'installateur, j'ai fais une installation ultra minimale, et j'ai ensuite installé Cinnamon à la main ainsi que tous les paquets (de Xorg à Mesa, une installation un peu à la façon Arch), et là pour une raison que je n'explique pas, le pilote nvidia fonctionne nickel, optirun gère super bien ma GPU (mais nouveau est toujours aussi foireux en revanche)
à croire que certains paquets installés par l'installateur entraient en conflit avec le pilote Nvidia..
Je suis sur Debian Sid Cinnamon et Debian Stretch Cinnamon et Xfce avec le pilote nvidia sur les deux, ça va faire un an et demi maintenant, et aucun problème avec le pilote proprio ;)
c'est stable, les upgrades se font sans le moindre problème, et je peux enfin utiliser steam avec optirun, que du bonheur quoi :)
la seule différence d'avec vous tous, c'est que mon pc a 5 ans (puissant, et encore d'actualité en terme de performance malgré son âge avancé)
j'apporte pas une solution concrète j'en suis désolée, c'est juste une petite expérience personnelle qui m'en faisait tomber ma chevelure LöL
ma Nvidia est très mal gérée par nouveau, elle tourne en permanence, chauffe du pc, tearing, blocage complet, et crash au reboot avec écran noir.
l'installation des pilotes Nvidia a longtemps été un casse tete, avec blocage du pc, écran noir après le chargement de Lightdm.
que ce soit sur ubuntu, mint, debian ou fedora (prime ou bumblebee même résultat)
seul archlinux arrivait a tout faire tourner correctement, mais arch avait d'autres soucis de stabilité donc pas top sur le long terme..
comme j'aime ma debian, je suis revenue dessus mais avec une autre technique d'approche.
au lieu d'installer Cinnamon via l'installateur, j'ai fais une installation ultra minimale, et j'ai ensuite installé Cinnamon à la main ainsi que tous les paquets (de Xorg à Mesa, une installation un peu à la façon Arch), et là pour une raison que je n'explique pas, le pilote nvidia fonctionne nickel, optirun gère super bien ma GPU (mais nouveau est toujours aussi foireux en revanche)
à croire que certains paquets installés par l'installateur entraient en conflit avec le pilote Nvidia..
Je suis sur Debian Sid Cinnamon et Debian Stretch Cinnamon et Xfce avec le pilote nvidia sur les deux, ça va faire un an et demi maintenant, et aucun problème avec le pilote proprio ;)
c'est stable, les upgrades se font sans le moindre problème, et je peux enfin utiliser steam avec optirun, que du bonheur quoi :)
la seule différence d'avec vous tous, c'est que mon pc a 5 ans (puissant, et encore d'actualité en terme de performance malgré son âge avancé)
j'apporte pas une solution concrète j'en suis désolée, c'est juste une petite expérience personnelle qui m'en faisait tomber ma chevelure LöL