Как устранить полное зависание системы

У меня новый ноутбук System76 Lemur Pro с Ubuntu 20.04. Я действительно хочу полюбить это, но я обнаруживаю, что он полностью блокируется несколько раз в неделю, что как бы подавляет мои чувства. Я обращаюсь в службу поддержки System76, но я также пытаюсь самостоятельно устранить неполадки. Я новичок в Linux и надеюсь узнать не только о том, как починить свою машину, но также и общие шаги по устранению неполадок, которые будут полезны в будущем.

Система : System76 Lemur Pro, i7, 40 ГБ ОЗУ , одиночный SSD. Ubuntu 20.04. Все обновления установлены. Только периферийные устройства - это USB-концентратор с подключенными мышью и клавиатурой, а также внешний монитор, подключенный через адаптер USB-C к DisplayPort. Ничего экзотического.

Авария : Несколько раз в неделю я возвращаюсь к своему ноутбуку (обычно утром, после того как он простаивает всю ночь) и обнаруживаю, что он полностью не реагирует на мышь / клавиатуру. Использование ALT + F_ для переключения на терминал ничего не дает. ALT + PRTSCR + REISUB ничего не делает. Нажатие на кнопку питания ничего не делает. Попытка включить внутренний ЖК-дисплей ничего не дает. Только удерживание кнопки питания и полный сброс настроек позволяют мне восстановиться. Это произошло только один раз, когда я активно использовал машину, и рабочий стол Gnome оставался видимым, мышь и клавиатура заблокированы, и около 1/4 секунды песни, которую я слушал, просто застряло в цикле. Для восстановления ничего не помогало, кроме аппаратного сброса.

Что я пробовал:

  • Стресс-тестирование процессора. Я отслеживал температуру процессора во время стресс-теста в течение нескольких минут. Температура никогда не превышала 80-х, и вентилятор ЦП включился, чтобы держать ее под контролем. Это кажется безопасным, учитывая, что горячие / критические температуры указаны как 100.
  • Запуск memtester. Прошло 5 раз, все прошло успешно.
  • Установка всех обновлений, рекомендованных Ubuntu.
  • Просмотр системных журналов (/ var / log / syslog). Эти журналы просто становятся пустыми, когда система зависает, и остаются пустыми, пока я не перезагружу их. Ничто непосредственно перед аварией не выглядит очень интересным.
  • Отключение сна. Был уже отключен, но подумал, что упомяну об этом.

На данный момент я не совсем уверен, какими должны быть мои следующие шаги. Могу ли я посмотреть другие журналы? Другую диагностику я могу запустить? Должен ли я считать, что это периферийное устройство, и отключать клавиатуру / мышь / монитор / концентратор по одному, чтобы попытаться изолировать? Вряд ли это обычное периферийное устройство, но кто знает.

Изменить: по запросу, вот журналы из /var/log/kern.log прямо перед одним из сбоев. Он включает много информации об управляемом троттлинге ЦП. Однако такие сообщения появляются регулярно, когда компьютер также стабилен ...

Oct 22 07:52:00 system76-pc kernel: [44320.095989] mce: CPU4: Package temperature above threshold, cpu clock throttled (total events = 7775)
Oct 22 07:52:00 system76-pc kernel: [44320.095990] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 4669)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 719)
Oct 22 07:52:00 system76-pc kernel: [44320.095992] mce: CPU6: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.095994] mce: CPU7: Package temperature above threshold, cpu clock throttled (total events = 752)
Oct 22 07:52:00 system76-pc kernel: [44320.096970] mce: CPU2: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU0: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096972] mce: CPU5: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096973] mce: CPU3: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU6: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096974] mce: CPU7: Core temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096975] mce: CPU4: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096976] mce: CPU1: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU6: Package temperature/speed normal
Oct 22 07:52:00 system76-pc kernel: [44320.096977] mce: CPU7: Package temperature/speed normal
0
задан 23 October 2020 в 18:16

2 ответа

Это ошибка ядра, связанная с управлением питанием процессора. Это исправлено в ядре 5.8, которое поставляется с Ubuntu 20.10. Я обновился до 20.10, отключил все обходные пути, и теперь я работаю стабильно.

Если обновление до 5.8 / 20.10 - не то, что вам нужно, вы также можете обойти ошибку, не давая вашему ЦП понижаться. -состояния питания (это, очевидно, сократит срок службы батареи). Откройте / etc / default / grub и добавьте intel_idle.max_cstate = 1 к содержимому значения для GRUB_CMDLINE_LINUX_DEFAULT . Сохраните, запустите sudo update-grub , затем перезагрузите компьютер. Поверните процесс в обратном порядке, чтобы отменить обходной путь.

Возможно, значение cstate выше 1 все же будет стабильным обходным путем, но я никогда не экспериментировал достаточно, чтобы проверить.

0
ответ дан 4 January 2021 в 08:19

Это частичный ответ, основанный на текущей информации, в том числе из комментариев.

В файлах журнала есть указания на то, что речь идет о высоких температурах процессора , так что система продолжает достигать предела температуры дросселирования. Однако стресс-тесты ЦП не выявили проблем.

В качестве теста найдите рабочую точку системы, в которой тепловые проблемы ЦП невозможны, и запустите ее достаточно долго, чтобы определить влияние на стабильность системы. Стоимость этого теста будет производительностью. Позже, надлежащий тепловой демон (thermd, tlp, ...) должен быть исследован как способ восстановления максимальной производительности.

Драйвер масштабирования частоты процессора по умолчанию для i7-10510U - intel_pstate, и этот ответ написан для этот водитель. Проверьте через:

doug@s15:~$ grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu4/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu5/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu6/cpufreq/scaling_driver:intel_cpufreq
/sys/devices/system/cpu/cpu7/cpufreq/scaling_driver:intel_cpufreq

Тест mprime (prime95) с высокой температурой используется в качестве стресс-теста ЦП, потому что он потребляет больше всего энергии из всех стресс-тестов ЦП, которые я когда-либо тестировал. Для защиты моего примера компьютера, на котором не запущен тепловой демон, желаемая рабочая точка около 80 градусов будет найдена с нижней стороны. Во-первых, обратите внимание на текущий процент максимальной частоты процессора, отметьте также и минимальный (ваш будет другим):

cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
doug@s15:~$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
42

Это может быть не 100%, если какой-то тепловой демон уже что-то ограничивает. В любом случае, я начну с 50%:

doug@s15:~$ echo 50 | sudo tee /sys/devices/system/cpu/intel_pstate/max_perf_pct
50

Затем постепенно увеличиваю максимальную частоту процессора в процентах, скажем, с шагом 10 процентов, и нахожу рабочую точку для температуры корпуса процессора примерно 80 градусов:

doug@s15:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 6
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt GFXWatt

0.25    1754    725     25      3.81    0.12
0.02    1600    288     26      3.70    0.12
0.06    1600    360     26      3.70    0.12
38.82   1899    7740    39      16.28   0.12
100.00  1900    17594   41      36.20   0.12   <<< mprime torture test started
100.00  1900    17541   42      36.44   0.12
100.00  1900    17552   43      36.39   0.12
100.00  1900    17517   44      36.25   0.12
100.00  1927    17474   48      36.95   0.12
100.00  2300    17389   49      46.51   0.12
100.00  2300    17367   50      46.60   0.12
100.00  2300    17362   52      46.69   0.12
100.00  2300    17438   53      46.77   0.12
100.00  2552    18440   56      54.18   0.12
100.00  2700    17672   58      58.48   0.12
100.00  2700    17590   58      58.59   0.12
100.00  2700    17710   61      58.74   0.12
100.00  2953    17780   66      67.91   0.12
100.00  3100    17876   68      73.38   0.12  <<<< First time at 80%, temp lags.
100.00  3100    17843   69      73.55   0.12
100.00  3100    17860   70      73.64   0.12
100.00  3100    18794   71      73.78   0.12
100.00  3231    17826   77      79.69   0.12
100.00  3500    18305   80      92.33   0.12
100.00  3500    17765   81      92.66   0.12
100.00  3457    17747   80      90.72   0.12
100.00  3300    17720   81      82.62   0.12
100.00  3300    17723   81      82.72   0.12
100.00  3300    17708   80      82.81   0.12
100.00  3300    17712   83      82.95   0.12  <<<< Opps too high
100.00  3300    17788   82      83.08   0.12
100.00  3204    17882   81      79.25   0.12
100.00  3100    17778   80      74.78   0.12
100.00  3100    18571   81      74.83   0.12
100.00  3100    17806   80      74.85   0.12
100.00  3100    17787   80      74.89   0.12 <<<< 80 percent seems stable
100.00  3100    17772   81      74.84   0.12
100.00  3100    17824   81      74.85   0.12
100.00  3100    17777   80      74.89   0.12
100.00  3100    17799   81      74.95   0.12
100.00  3100    17867   81      74.77   0.12

Итак, для моей системы ограничение частота процессора до 80% от максимальной убережет их от любого встроенного дополнительного терморегулирования. Запустите систему таким образом на некоторое время.

0
ответ дан 4 January 2021 в 08:19

Другие вопросы по тегам:

Похожие вопросы: