Le problème de processeur Intel Bay Trail sera-t-il résolu en 17.04?
Beaucoup de gens ont des problèmes avec Ubuntu 14.04, 16.04 et 16.10 où le système se bloque complètement, et je suis l’un d’eux.
Je veux savoir si Ubuntu 17.04 corrigera ce problème ou non, s'il a déjà été corrigé sur l'image ISO d'essai de 17.04, avant d'essayer de le télécharger et de le tester.
TL; DR - mes recherches suggèrent que cela n’est pas résolu dans l’image 17.04 bêta ou dans le communiqué, mais j’espère beaucoup pour 17.10.
Ces blocages se produisent lorsque le processeur tente d'entrer dans un état de faible consommation (état c) que le noyau ne prend pas en charge. Ce problème a été introduit par
commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date: Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail
Cela est passé en amont dans le noyau 4.2, et nous avons eu des problèmes depuis lors. Comme expliqué dans réponse de heynnema (et ce message où j'ai essayé de rassembler des informations ), il existe une solution simple et efficace, qui passe un paramètre de démarrage qui désactive les états de faible consommation.
La version bêta de 17.04 actuellement disponible utilise la version 4.9 (elle est basée sur la version amont 4.9.6 si je comprends bien) et, au moment de la publication de la publication en avril, je crois que elle utilisera la version 4.1 . Le problème existe toujours dans ces noyaux, j'ai donc conclu qu'il n'est pas résolu à partir de maintenant . J'ai vérifié les changelogs du noyau Ubuntu et je n'ai rien trouvé, mais corrigez-moi s'il vous plaît si je me trompe.
Je traque le bogue de l'état c ici sur kernel.org depuis longtemps. En janvier 2017, Mika Kuoppala a ajouté ce correctif au fil de discussion. Apparemment, il annule le commit précédent à l'origine du problème. Le patch s'appelle
drm/i915/byt: Avoid tweaking evaluation thresholds
Les tests indiquent de très bons résultats avec ce correctif, qui a été soumis aux propriétaires de pilotes i915 le 25 janvier. Tout va bien, il pourrait être fusionné dans la fenêtre 4.11. Le noyau 4.11 pourrait être publié fin avril. Une version de ce correctif a été fusionnée dans la fenêtre 4.11 et des rapports indiquent que le bogue est corrigé dans 4.11.
Chacun des processeurs gênants BayTrail se comporte un peu différemment avec chaque noyau différent. Dans la version 16.04 (noyau 4.4), mon temps de disponibilité sous Atom Z3735F sans le paramètre intel_idle était d’environ 15 minutes avant le gel. J'ai testé la version bêta 17.04 ISO en mode direct, et je n'ai pas obtenu un gel en 90 minutes, il semble donc que j'ai de la chance avec ce noyau. Vous pouvez faire la même chose pour tester n’importe quelle image sur votre système - créez simplement une clé USB amorçable et "essayez Ubuntu sans l’installer" et testez-la aussi longtemps que possible.
Lorsque 17.04 est sorti, je l'ai installé et, au cours des deux premières semaines, je l'ai exécuté sans le paramètre intel_idle. Je n'ai eu que trois blocages de l'état c, ce qui représente une énorme amélioration par rapport aux versions précédentes.
La solution la plus sûre consiste à utiliser le paramètre de démarrage. D'après mes recherches, je m'attends à ce que le bogue soit corrigé dans 17.10 (et dans d'autres versions de distro plus tard cette année) qui utilisera un noyau> = 4.11, mais pas en 17.04.
Cependant, il est toujours possible que l'équipe du noyau Ubuntu puisse le corriger eux-mêmes. Si vous pouvez tolérer l’exécution occasionnelle d’un système instable, vous pouvez surveiller les progrès réalisés en exécutant des mises à jour régulières (Sudo apt update && Sudo apt full-upgrade) et en testant chaque nouveau noyau sans le paramètre de démarrage lorsqu’il arrive. Vous pouvez également lire les journaux des modifications lorsque de nouveaux packages sont installés ou (à nouveau, si vous pouvez tolérer l'instabilité) installer un noyau principal .
Il existe un correctif pour cela dans Comment définir intel_idle.max_cstate = 1 .
Dans terminal, tapez:
gksudo gedit /etc/default/grub
et changez cette ligne:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
inclure ceci:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
alors fais:
Sudo update-grub
reboot
C'est un problème d'Intel, pas un problème d'Ubuntu, mais heureusement que nous avons une solution.
Personne ne sait si Ubuntu 17.04 aura besoin de ce correctif ou non.