Відповіді:
Ці заморозки трапляються, коли процесор намагається ввести стан низької потужності (c-стан), який ядро не підтримує. Цю проблему представив
commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date: Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail
Це пішло вище за течією ядра 4.2, і з тих пір у нас виникли проблеми. Як пояснено у відповіді гейннеми (і в цій публікації, де я спробував зібрати інформацію ), існує чітке та ефективне рішення, яке передає параметр завантаження, який вимикає стани низької потужності.
В даний час бета-версія 17.04 доступна для використання 4,9 (вона базується на версії 4.9.6, наскільки я розумію), і до моменту виходу у квітні, я вважаю, що він використовуватиме 4.10 . Проблема все ще існує в цих ядрах, тому я прийшов до висновку, що вона не виправлена зараз . Я перевірив журнали змін ядер Ubuntu, і нічого не знайшов, але, будь ласка, виправте мене, якщо я помиляюся.
Я відслідковував помилку c-state тут на kernel.org . У січні 2017 року Міка Куопала додав цей пластир до нитки. Мабуть, це скасовує більш раннє зобов'язання, що спричинило проблему. Патч називається
drm/i915/byt: Avoid tweaking evaluation thresholds
Тестування свідчить про дуже хороші результати за допомогою цього виправлення, яке було подано власникам драйверів i915 25 січня. Все добре, його можна було об'єднати у вікні 4.11. Ядро 4.11 може вийти в кінці квітня. Версія цього виправлення була об'єднана у вікні 4.11, і звіти вказують на те, що помилка виправлена в 4.11.
Кожен з проблемних процесорів BayTrail поводиться трохи по-різному з кожним різним ядром. У 16.04 (4.4 ядро) мій час роботи на Atom Z3735F без параметра Intel_idle був приблизно за 15 хвилин до заморожування. Я протестував бета-версію 17.04 ISO в режимі живого режиму, і не замерзнув за 90 хвилин, тому, схоже, мені пощастило з цим ядром. Ви можете зробити те ж саме, щоб протестувати будь-яке зображення у вашій системі - просто зробити завантажувальний USB та "спробувати Ubuntu без встановлення" та протестуйте його якомога довше.
Коли вийшов 17.04, я встановив його, і в перші два тижні запустив його без intel_idleпараметра, у мене було лише три заморозки c-state, що є величезним поліпшенням на попередніх версіях.
Найбезпечніше - використовувати параметр завантаження. На основі мого дослідження я очікую, що помилка буде виправлена в 17.10 (та в інших дистрибутивах дистрибутивів пізніше цього року), які будуть використовувати ядро> = 4.11, але не в 17.04.
Однак завжди є можливість, що команда Ubuntu Kernel може сама виправити її. Якщо ви можете терпіти час від часу нестабільної системи, ви можете стежити за прогресом, запускаючи регулярні оновлення ( sudo apt update && sudo apt full-upgrade) та тестуючи кожне нове ядро без параметра завантаження, коли воно надійде. Ви також можете прочитати журнали змін, коли встановлені нові пакети або (знову ж таки, якщо ви терпите нестабільність), встановити основне ядро .
i915, ймовірно, буде виправлений тим самим патчем, але звіт про помилку стосується проблем, виправлених параметром intel_idle, і якщо це не працює для вас, це інша помилка відповідно до ядра люди. Чи можете ви надати звіт про помилку чи тему форуму (ви кажете, що інші поділяють вашу проблему), де я можу дізнатися більше, тому я можу порадити, що вам робити далі? (Я думаю, вам може знадобитися задати нове запитання)
Для цього є виправлення в розділі Як встановити intel_idle.max_cstate = 1 .
В terminal, тип:
gksudo gedit /etc/default/grub
і змінити цей рядок:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
включити це:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
тоді зробіть:
sudo update-grub
reboot
Це проблема Intel, а не проблема Ubuntu, але дякуємо, що ми вирішили.
Ніхто не знає, вимагатиме це виправлення Ubuntu 17.04 чи ні.
Відповідно до коментаря №1013 у звіті про помилку, це тепер виправлено:
Я давно не перевіряв цю тему, але подумав, що я повинен розмістити свої висновки на той випадок, якщо комусь це буде корисно.
Комп'ютер низького рівня, що працює на базі Intel N2807, який ніколи не працював більше 30 мільйонів, без збоїв, коли я не встановив ... max_cstates = 1, зараз чудово працює з базовим ядром v. 5.3.1 або 4.19.75 Я запускав його кілька днів із кожною версією без жодних проблем. Середнє споживання електроенергії також знизилося на трохи більше 10%.
Щоб виправити цю помилку, вперше про це повідомили 8 грудня 2015 року.