Ubuntu 16.10, перегревающая проблему
Я недавно установил Ubuntu 16.10 и с тех пор перезагрузки Ubuntu саму. вывод: last | grep "Oct 31" :
aegefel tty7 :0 Mon Oct 31 15:15 gone - no logout
reboot system boot 4.8.0-26-generic Mon Oct 31 15:14 still running
aegefel tty7 :0 Mon Oct 31 15:02 - down (00:04)
reboot system boot 4.8.0-26-generic Mon Oct 31 15:02 - 15:06 (00:04)
aegefel tty7 :0 Mon Oct 31 14:33 - crash (00:28)
reboot system boot 4.8.0-26-generic Mon Oct 31 14:33 - 15:06 (00:33)
aegefel tty7 :0 Mon Oct 31 14:12 - crash (00:20)
reboot system boot 4.8.0-26-generic Mon Oct 31 14:12 - 15:06 (00:54)
aegefel tty7 :0 Mon Oct 31 13:08 - crash (01:04)
reboot system boot 4.8.0-26-generic Mon Oct 31 13:08 - 15:06 (01:58)
Который приводит меня к believr, он вызывается катастрофическим отказом
Я не знаю то, что вызывает это, но это произошло, когда я пытался посмотреть фильм или когда я сделал резервное копирование
Как я должен продолжить двигаться?
РЕДАКТИРОВАНИЕ 1
Команда more /var/log/syslog* дает мне:
Nov 6 18:18:17 aegefel-Akoya-E6424-MD99850 gnome-terminal-[2674]: Allocating size to GtkBox 0x55558d2b47b0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Nov 6 18:18:17 aegefel-Akoya-E6424-MD99850 gnome-terminal-[2674]: Allocating size to GtkBox 0x55558d2b47b0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Nov 6 18:18:31 aegefel-Akoya-E6424-MD99850 gnome-terminal-[2674]: Allocating size to GtkBox 0x55558d2b4120 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Nov 6 18:18:31 aegefel-Akoya-E6424-MD99850 gnome-terminal-[2674]: Allocating size to GtkBox 0x55558d2b4120 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Nov 6 18:18:36 aegefel-Akoya-E6424-MD99850 systemd[1]: Starting Stop ureadahead data collection...
Nov 6 18:18:36 aegefel-Akoya-E6424-MD99850 systemd[1]: Started Stop ureadahead data collection.
Затем ничего не произошло в течение почти 1 минуты, таким образом, я предполагаю перезагруженный ПК.
Команда ls -alt /var/crash дает мне на сегодняшний день:
total 21672
drwxrwsrwt 2 root whoopsie 4096 Nov 6 14:26 .
-rwxrwxrwx 1 root whoopsie 0 Nov 6 14:26 .lock
РЕДАКТИРОВАНИЕ 2
Это добавляет только, когда мой ЦП используется в 40% - 50%, или больше (Моим ЦП является Intel Core i5 6267U 2.9GHz),
РЕДАКТИРОВАНИЕ 3
Команда sensors дает мне следующее:
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +37.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +34.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +36.0°C (high = +100.0°C, crit = +100.0°C)
acpitz-virtual-0
Adapter: Virtual device
temp1: +38.0°C (crit = +98.0°C)
pch_skylake-virtual-0
Adapter: Virtual device
temp1: +35.0°C
Высокая температура равна критическому. Возможно, мой ноутбук просто перегревается, и вентилятор не имеют времени для понижения температуры. Я пытался понизить высокую температуру, но это автоматически понижает критическое (критическое должно быть равно верхнему уровню),
РЕДАКТИРОВАНИЕ 4
Здесь Вы имеете
И вот катастрофические отказы с 20 ноября
РЕДАКТИРОВАНИЕ 5
После некоторого теста я думаю, что проблемой является перегрев GPU. На самом деле, моя перезагрузка ноутбука только, когда я пытаюсь смотреть кино, когда я протестировал с некоторыми бесплатными играми на моем Ноутбуке или когда я использовал Нереальный Механизм 4. Причина, которую мой ПК не перезагружал с Блендером, состоит в том что использование Блендера, по умолчанию, ЦП (не GPU). Я имею Intel Iris Graphics 550 (Skylake GT3e) Какая-либо идея?
2 ответа
Если Вы действительно обеспокоены перезагрузка из-за паники ядра, как заголовок Вашего сообщения предполагает, можно проверить файл /etc/sysctl.conf на директиву, подобную kernel.panic = n, где n некоторое число, которое указывает, сколько секунд для задержки прежде, чем перезагрузить в даже ядра паникует. Исследование указывает, что оно, как предполагается, не перезагружает по умолчанию.
, Если вместо этого, поскольку я подозреваю Вас, более касаются определения первопричина из этих перезагрузок (некоторый связанный с аппаратными средствами отказ является моим мнением) Вы захотите рассмотреть события Машинного контроля для определения, какие аппаратные средства неправильно функционируют. Если у Вас нет файла /var/log/mcelog, Вы, возможно, должны установить mcelog пакет путем включения репозитория Вселенной (если не уже включенный в источниках) и издание команды sudo apt install mcelog, Затем продвигающейся, эти события будут зарегистрированы к /var/log/mcelog
Для ясности, вот выборка от man mcelog
X86 CPUs report errors detected by the CPU as machine check events
(MCEs). These can be data corruption detected in the CPU caches, in
main memory by an integrated memory controller, data transfer errors on
the front side bus or CPU interconnect or other internal errors. Pos‐
sible causes can be cosmic radiation, instable power supplies, cooling
problems, broken hardware, or bad luck.
Most errors can be corrected by the CPU by internal error correction
mechanisms. Uncorrected errors cause machine check exceptions which may
panic the machine.
, системы Linux обычно не перезагружают из-за паники ядра по умолчанию, таким образом, Вы можете widh для проверки файла /etc/sysctl.conf, упомянутого ранее.
Источники:
http://www.techrepublic.com/blog/linux-and-open-source/auto-reboot-linux-after-a-kernel-panic/
http://mcelog.org/logfile.html
На основе Вашего mcelog, 1 ЦП и 3 в Вашей системе перегревается. снижая скорость, остывая и возвращая к исходному состоянию (все это дизайном для защиты ЦП от перегрева). Первопричиной мог быть плохо прикладной тепловой составной объект между ЦП, и теплоотвод, свободный теплоотвод, заблокировал вентиляторы или чрезмерно пыльное или провальное холодильное оборудование (вентилятор?). Другая (маловероятная) возможность является отказом в тепловых возможностях обнаружения ЦП.
Заголовок этой темы не является четким.
Так или иначе, если Вы нуждаетесь в помощи для исследования на системном катастрофическом отказе, и все предыдущие комментарии не были полезны, пробуют их:
- Ядро увеличения регистрирует многословие.
- Остановите ядро к автоматически перезагрузке с катастрофическим отказом/паникой.
- Попытайтесь удаленно войти в систему (например, ssh) в Вашей системе и проверить журналы.
- как @user.dz указанный, используйте, например, memtest86 + из http://www.memtest.org/ для глубокой проверки RAM.
- Поскольку Вы сказали "... Это добавляет только, когда мой ЦП используется в 40% - 50% или больше...", могла быть проблема PSU? Я подразумеваю, что Ваша система требует большего количества питания, чем PSU может дать ему.