Будет ли проблема с процессором Intel Bay Trail исправлена ​​в 17.04?

У многих людей есть проблемы с Ubuntu 14.04, 16.04 и 16.10, где система полностью зависает, и я один из них.

Я хочу знать, исправит ли Ubuntu 17.04 эту проблему или нет, была ли она уже исправлена ​​в пробном ISO-образе 17.04, прежде чем я попытаюсь загрузить его и протестировать.

TL; DR - мое исследование показывает, что оно не зафиксировано ни в бета-образе 17.04, ни в релизе, но я очень надеюсь на 17.10.

Эти зависания происходят, когда процессор пытается перейти в состояние низкого энергопотребления (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-состояния здесь, на 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-состояния, что является огромным улучшением в более ранних версиях.

Самое безопасное - использовать параметр загрузки. Исходя из моих исследований, я ожидаю, что ошибка будет исправлена ​​в 17.10 (и в других выпусках дистрибутива позже в этом году), в котором будет использоваться ядро> = 4.11, но не в 17.04.

Однако всегда есть вероятность, что команда ядра Ubuntu может исправить это самостоятельно. Если вы иногда допускаете запуск нестабильной системы, вы можете следить за прогрессом, выполняя регулярные update ( sudo apt update && sudo apt full-upgrade) и тестируя каждое новое ядро ​​без параметра загрузки, когда оно прибывает. Вы также можете прочитать журналы изменений при установке новых пакетов или (опять же, если вы можете терпеть нестабильность) установить основное ядро .

Это исправлено в разделе Как установить 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, теперь прекрасно работает со стандартным ядром версии 5.3.1 или 4.19.75. Я запускал его в течение нескольких дней с каждой версией без каких-либо проблем. Среднее энергопотребление также снизилось чуть более чем на 10%.

Исправление этой ошибки заняло около четырех лет, о чем впервые было сообщено 8 декабря 2015 года.