Ответы:
Эти зависания происходят, когда процессор пытается перейти в состояние низкого энергопотребления (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) и тестируя каждое новое ядро без параметра загрузки, когда оно прибывает. Вы также можете прочитать журналы изменений при установке новых пакетов или (опять же, если вы можете терпеть нестабильность) установить основное ядро .
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, теперь прекрасно работает со стандартным ядром версии 5.3.1 или 4.19.75. Я запускал его в течение нескольких дней с каждой версией без каких-либо проблем. Среднее энергопотребление также снизилось чуть более чем на 10%.
Исправление этой ошибки заняло около четырех лет, о чем впервые было сообщено 8 декабря 2015 года.