Beaucoup de gens ont des problèmes avec Ubuntu 14.04, 16.04 et 16.10 où le système se fige complètement, et je suis l'un d'entre eux.
Je veux savoir si Ubuntu 17.04 va corriger 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 la télécharger et de la tester.
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 BaytrailCe problème est apparu en amont dans le noyau 4.2, et nous rencontrons des problèmes depuis lors. Comme expliqué dans Réponse de heynnema (et ce poste où j'ai essayé de rassembler des informations ), il existe une solution simple et efficace qui consiste à passer un paramètre de démarrage qui désactive les états de faible consommation.
La version bêta de la 17.04 actuellement disponible utilise la version 4.9 (elle est basée sur la version 4.9.6 en amont, d'après ce que j'ai compris), et d'ici la sortie de la version en avril, je pense que la version 4.9.6 sera utilisée. il utilisera la version 4.10 . Le problème persiste dans ces noyaux, et j'en ai donc conclu qu'il s'agit d'un problème de sécurité. pas encore corrigé . J'ai vérifié le journal des modifications du noyau Ubuntu, et je n'ai rien trouvé, mais je vous prie de me corriger si je me trompe.
J'ai suivi l'évolution de la bogue de l'état c ici sur kernel.org pendant longtemps. En janvier 2017, Mika Kuoppala a ajouté ce correctif au fil de discussion. Apparemment, il annule le commit antérieur qui a causé le problème. Le correctif s'appelle
drm/i915/byt: Avoid tweaking evaluation thresholdsLes tests indiquent de très bons résultats avec ce correctif, qui a été soumis aux propriétaires du pilote i915 le 25 janvier. Si tout va bien, il pourrait être fusionné dans la fenêtre 4.11. Le noyau 4.11 pourrait être publié vers la fin du mois d'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 la version 4.11.
Chacun des processeurs BayTrail problématiques se comporte un peu différemment avec chaque noyau. En 16.04 (noyau 4.4), mon temps de fonctionnement sur l'Atom Z3735F sans le paramètre intel_idle était d'environ 15 minutes avant de se figer. J'ai testé la version beta 17.04 ISO en mode live, et je n'ai pas eu de freeze en 90 minutes, donc il semble 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 - faites simplement une clé USB amorçable et "essayez Ubuntu sans l'installer" et testez-la aussi longtemps que possible.
Lorsque la version 17.04 est sortie, je l'ai installée et, au cours des deux premières semaines, je l'ai fait fonctionner sans l'option intel_idle je n'ai eu que trois blocages d'état, 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. D'après mes recherches, je m'attends à ce que le bogue soit corrigé dans la version 17.10 (et dans d'autres versions de distro plus tard dans l'année) qui utilisera un noyau >=4.11, mais pas en 17.04.
Cependant, il est toujours possible que l'équipe Ubuntu Kernel Team apporte elle-même un correctif. Si vous pouvez tolérer de faire fonctionner un système instable de temps en temps, vous pouvez surveiller les progrès en exécutant des mises à jour régulières ( sudo apt update && sudo apt full-upgrade ) et de tester chaque nouveau noyau sans le paramètre de démarrage lorsqu'il arrive. Vous pouvez également lire le journal des modifications au fur et à mesure de l'installation de nouveaux paquets 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 .
Unter terminal , type :
gksudo gedit /etc/default/grubet changez cette ligne :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"pour inclure ceci :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"alors faites-le :
sudo update-grub
rebootC'est un problème Intel, pas un problème Ubuntu, mais Dieu merci, nous avons une solution.
Personne ne sait si Ubuntu 17.04 nécessitera ce correctif ou non.
Selon le commentaire 1013 dans rapport de bogue c'est maintenant corrigé :
Je n'ai pas consulté ce fil depuis longtemps, mais j'ai pensé que je devais le faire. mais j'ai pensé que je devais poster mes résultats au cas où ils seraient utiles à quelqu'un.
Un ordinateur bas de gamme équipé d'un Intel N2807 qui n'a jamais fonctionné davantage. plus de 30 mn sans planter quand je ne mettais pas ...max_cstates=1, fonctionne désormais fonctionne parfaitement bien avec un noyau stock v. 5.3.1 ou 4.19.75. Je l'ai fait tourner pendant quelques jours avec chaque version sans aucun problème. La consommation moyenne consommation d'énergie moyenne a également diminué d'un peu plus de 10%.
Il a fallu environ quatre ans pour corriger ce bug signalé pour la première fois le 8 décembre 2015.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
