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 j'en fais partie.
Je veux savoir si Ubuntu 17.04 résoudra 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.
Réponses:
Ces blocages surviennent lorsque le processeur tente d'entrer dans un état de faible puissance (é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 allé en amont dans le noyau 4.2, et nous avons eu des problèmes depuis lors. Comme expliqué dans la réponse de heynnema (et cet article où j'ai essayé de rassembler des informations ), il existe une solution de contournement simple et efficace, en passant un paramètre de démarrage qui désactive les états de faible puissance.
La version bêta de 17.04 actuellement disponible utilise 4.9 (elle est basée sur l'amont 4.9.6 si je comprends bien), et au moment où la version sortira en avril, je pense qu'elle utilisera 4.10 . Le problème existe toujours dans ces noyaux, j'ai donc conclu qu'il n'est pas résolu pour l'instant . J'ai vérifié les journaux des modifications du noyau Ubuntu et je n'ai rien trouvé, mais veuillez me corriger si je me trompe.
J'ai suivi le bogue de l'état c ici sur kernel.org depuis longtemps. En janvier 2017, Mika Kuoppala a ajouté ce patch au fil. Apparemment, il annule la validation précédente qui a provoqué le problème. Le patch est appelé
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é vers la fin avril. Une version de ce correctif a été fusionnée dans la fenêtre 4.11 et les rapports indiquent que le bogue est corrigé dans 4.11.
Chacun des processeurs BayTrail gênants se comporte un peu différemment avec chaque noyau différent. En 16.04 (noyau 4.4) mon temps de disponibilité sur 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 live, et je n'ai pas eu de 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 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 intel_idleparamètre, je n'ai eu que trois blocages d'état C, ce qui est une énorme amélioration par rapport aux versions précédentes.
La chose la plus sûre à faire est d'utiliser le paramètre de démarrage. Sur la base de mes recherches, je m'attends à ce que le bogue soit corrigé dans 17.10 (et dans d'autres versions de distribution plus tard cette année) qui utilisera un noyau> = 4.11, mais pas dans 17.04.
Cependant, il est toujours possible que l'équipe du noyau Ubuntu le corrige lui-même. Si vous pouvez tolérer l'exécution occasionnelle d'un système instable, vous pouvez surveiller les progrè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 à son arrivée. Vous pouvez également lire les journaux des modifications à mesure que de nouveaux packages sont installés ou (encore une fois, si vous pouvez tolérer l'instabilité) installer un noyau principal .
i915donc susceptible d'être résolu par le même correctif, mais le rapport de bogue concerne les problèmes résolus par le paramètre intel_idle et si cela ne fonctionne pas pour vous, c'est un bogue différent selon le les gens du noyau. Pouvez-vous s'il vous plaît fournir un rapport de bogue ou un fil de discussion (vous dites que d'autres partagent votre problème) où je peux en savoir plus, afin que je puisse vous conseiller quoi faire ensuite? (Je pense que vous devrez peut-être poser une nouvelle question)
Il existe un correctif pour cela dans Comment définir intel_idle.max_cstate = 1 .
Dans terminal, saisissez:
gksudo gedit /etc/default/grub
et changez cette ligne:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
pour inclure ceci:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
alors fais:
sudo update-grub
reboot
C'est un problème Intel, pas un problème Ubuntu, mais Dieu merci, nous avons un correctif.
Personne ne sait si Ubuntu 17.04 aura besoin de ce correctif ou non.
Selon le commentaire # 1013 dans le rapport de bogue, il est maintenant corrigé:
Je n'ai pas vérifié ce fil depuis longtemps, mais j'ai pensé que je devrais poster mes résultats au cas où cela serait utile à quiconque.
Un ordinateur bas de gamme alimenté par un Intel N2807 qui n'a jamais fonctionné plus de 30 mn sans planter quand je n'ai pas réglé ... max_cstates = 1 fonctionne désormais parfaitement avec un noyau d'origine v. 5.3.1 ou 4.19.75. Je l'ai exécuté pendant quelques jours avec chaque version sans aucun problème. La consommation électrique moyenne a également baissé d'un peu plus de 10%.
Il a fallu environ quatre ans pour corriger ce bogue signalé pour la première fois le 8 décembre 2015.