Clevo N850EL часто вылетает / зависает в Ubuntu 18.04.1
Я только что купил новый Clevo N850EL (в некоторых регионах также может быть маркирован как Prostar или Sager NP4850), с процессором i7-8750H, 32 ГБ оперативной памяти.
Ubuntu 18.04.1 устанавливает OK и, кажется, работает нормально (у меня работает, печатает, устанавливает и удаляет программное обеспечение), пока не произойдет сбой через некоторое время (через 45 минут +/- 30 минут).
(Он имеет как NVIDIA MX150, так и графику Intel HD. Я полагаю, что я использую графику Intel HD под Ubuntu).
Аварийное завершение работы полностью зависает (мышь не двигается, соединения TCP/IP замораживаются и обрываются, Ctrl+Alt+Del не отвечает, необходимо перезагрузить компьютер, нажав кнопку питания в течение 5 секунд).
Там нет ненормальной записи в /var/log/syslog
или же /var/log/kern.log
до или после замораживания.
Таким образом, это просто таинственный сбой, который я не знаю.
(Edit: 2018-08-25 Я включил SysRq, но сетевые сервисы тоже зависли, поэтому я не могу ssh
удаленно и попросите SysRq, и клавиатура Alt+SysRq+команда тоже кажется замороженной).
В первый день у него была, по-видимому, та же проблема с Windows 10, которая шла с этим ПК.
Но проблема исчезла после обновления до Windows 10 1803 (со всеми накопительными исправлениями и множественными перезагрузками). Теперь он полностью стабилен под Windows 10 1803.
Похоже на проблему "нового оборудования" в Linux, которую Windows недавно преодолела.
Что я должен делать? Должен ли я попытаться использовать исходящие ядра с Ubuntu? (Какая?) (Есть ли какая-нибудь USB-версия Ubuntu, которую я могу запускать весь день с более новым ядром, просто чтобы посмотреть, связана ли проблема с ядром? Должен ли я перейти на панель запуска и открыть проблему?)
(Я не очень хочу работать под Windows ...:-(
Редактировать: ядро 4.15.0-32-универсальный
# lspci
00:00.0 Host bridge: Intel Corporation Device 3ec4 (rev 07)
00:01.0 PCI bridge: Intel Corporation Skylake PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Device 3e9b
00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Device a379 (rev 10)
00:14.0 USB controller: Intel Corporation Device a36d (rev 10)
00:14.2 RAM memory: Intel Corporation Device a36f (rev 10)
00:16.0 Communication controller: Intel Corporation Device a360 (rev 10)
00:17.0 SATA controller: Intel Corporation Device a353 (rev 10)
00:1d.0 PCI bridge: Intel Corporation Device a330 (rev f0)
00:1d.5 PCI bridge: Intel Corporation Device a335 (rev f0)
00:1d.6 PCI bridge: Intel Corporation Device a336 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Device a30d (rev 10)
00:1f.3 Audio device: Intel Corporation Device a348 (rev 10)
00:1f.4 SMBus: Intel Corporation Device a323 (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device a324 (rev 10)
01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd Device a808
03:00.0 Network controller: Intel Corporation Device 2526 (rev 29)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01)
04:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
Изменить 2018-08-24: обновлен до ядра 44.15.0-33-generic. Проблема остается той же.
Загрузился в режиме консоли (опция GRUB systemd.unit=rescue.target), включил сетевой менеджер и WiFi из командной строки от имени пользователя root (см. https://help.ubuntu.com/community/NetworkManager) и скопировал некоторые файлы поверх сеть на несколько часов.
Проблема не возникает в режиме консоли. Я не сильно загружал систему из консольного режима, но мне удалось скопировать несколько ГБ файлов из сети, и при времени работы более 8 часов при нескольких запущенных службах и процессах, я думаю, я могу предположить, что тот же сбой / зависание не происходит в режиме консоли.
Установил nvidia-driver-390
проприетарные драйверы и переключились на NVIDIA с помощью команд:
sudo ubuntu-drivers devices
sudo ubuntu-drivers autoinstall
sudo prime-select nvidia
sudo reboot
nvidia-settings # just to check that it seems installed
Проблема остается той же с nvidia-driver-390
проприетарные драйверы.
Вернулся к Intel и занес в черный список драйвер ядра noveau:
sudo prime-select intel
sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf"
sudo update-initramfs -u
sudo reboot
Проблема остается той же с драйверами видео Intel с отключенным noveau.
Он не распознал адаптер Wi-Fi, но в режиме рабочего стола GNOME он работал стабильно в течение нескольких часов (я позволил ему работать в течение 2 ч 30 м при копировании некоторых ГБ файлов через проводной Ethernet на диск). (Более поздние попытки вернуться к этому тестированию Debian показали, что он также часто зависал / зависал.)
Но, полон новой надежды, я решил попробовать ядро Upstream (см. https://wiki.ubuntu.com/Kernel/MainlineBuilds).
Сначала я попробовал ядро 4.17.19-generic amd64. Сбой / зависание в первые 5 минут безотказной работы. (И снова... проблема остается той же)..
Затем я попробовал ядро 4.18.5-generic amd64. Казалось, что он работал в течение нескольких часов (более 2 часов), но затем завис и перезагрузился. На следующий день будет больше тестов, и проблема, похоже, останется (и всегда вылетает при перезагрузке). (Я попытался отключить Wi-Fi и использовать только проводной Ethernet, но проблема в конечном итоге повторяется. Примечание: кажется, я теряю проводной Ethernet по DHCP после горячей перезагрузки).
(Примечание 2: Между тем я удалил черный список драйвера noveau, поскольку он вызывал связанные с этим ошибки тайм-аута в /var/log/kern.log
, Утилита "Датчики" сообщает о температуре 511ºC на 3D-адаптере:-)
Edit 2018-08-26 kdump: я пытался настроить kdump
(как в https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html), но когда я тестирую его в графическом режиме, я получаю точно такую же проблему, описанную в kdump, не регистрирует сбой (система зависает, нет сообщений, нет перезагрузки, нет аварийного дампа под /var/crash/
).
Если я запускаю сбой ядра в режиме консоли с
echo c > /proc/sysrq-trigger
затем я вижу сообщения о сбое на консоли, и они частично записываются на /var/log/syslog
при следующей перезагрузке. Все еще нет аварийных свалок под /var/crash
,
Так что я немного растерялся. Что я должен попробовать?
Изменить 2018-08-27: я не обнаружил ошибок памяти DRAM (memtest86.com работал всю ночь - 6 часов и 16 минут) и не нашел ошибок.
Загрузка UEFI отключена.
Я скачал ежедневную сборку Ubuntu 18.10 по адресу http://cdimage.ubuntu.com/daily-live/20180827/cosmic-desktop-amd64.iso и несколько минут использовал ее в качестве USB-ручки в режиме реального времени, но, как обычно, зависал / зависал,
(PS: В панели управления GNOME 18.10 я не мог видеть, какая графическая карта использовалась. Она зависала / зависала, когда я запрашивал пункт "Информация").
Есть ли возможность использовать ограниченный графический режим VESA? (Я пробовал драйвер Force VESA в Ubuntu 16.10 безуспешно).
Изменить 2018-08-28: Добавление информации, запрошенной пользователем abu_bua:
root@jpsl-N8xxEL:~# hwinfo --cpu | grep -Ei "model\:|Features\:|Config Status\:" -m 4
Model: 6.158.10 "Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz"
Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,art,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,cpuid,aperfmperf,tsc_known_freq,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,sdbg,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,3dnowprefetch,cpuid_fault,epb,invpcid_single,pti,ssbd,ibrs,ibpb,stibp,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,tsc_adjust,bmi1,avx2,smep,bmi2,erms,invpcid,mpx,rdseed,adx,smap,clflushopt,intel_pt,xsaveopt,xsavec,xgetbv1,xsaves,dtherm,ida,arat,pln,pts,hwp,hwp_notify,hwp_act_window,hwp_epp,flush_l1d
Config Status: cfg=new, avail=yes, need=no, active=unknown
Model: 6.158.10 "Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz"
root@jpsl-N8xxEL:~# lspci -knn | grep -i vga -A3
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:3e9b]
Subsystem: CLEVO/KAPOK Computer Device [1558:8555]
Kernel driver in use: i915
Kernel modules: i915
1 ответ
Попробуйте использовать параметр ядра: intel_idle.max_cstate=1
сделайте эти шаги:
sudo nano /etc/default/grub
- заменить линию
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
сGRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
- сохранить его (CTRL+O)
sudo update-grub
sudo reboot
Подтвердите максимально допустимое C-состояние ЦП с помощью:
cat /sys/module/intel_idle/parameters/max_cstate
Более подробная информация на https://bugzilla.kernel.org/show_bug.cgi?id=109051
Краткое описание ++
Чтобы сэкономить энергию, когда процессор простаивает, он может получить команду на переход в режим пониженного энергопотребления. Каждый процессор имеет несколько режимов питания, и они вместе называются C-states
или же C-modes.
,
Идея этих режимов заключается в отключении тактового сигнала и питания от незанятых блоков внутри ЦП. Столько единиц вы останавливаете (сокращая часы), сколько снижаете напряжение или даже полностью выключаете, чтобы сэкономить энергию. С другой стороны, вы должны принять во внимание, что процессору требуется больше времени, чтобы "проснуться" и снова работать на 100%. Эти режимы известны как C-состояния. Обычно они начинаются с C0, который является нормальным режимом работы процессора, т. Е. Процессор включен на 100%. С увеличением числа C режим ожидания ЦП становится глубже, т. Е. Отключается больше цепей и сигналов и требуется больше времени для возврата ЦПУ в режим C0, т. Е. Для активации. Каждый режим также известен под именем, и некоторые из них имеют подрежимы с различными уровнями энергосбережения и, следовательно, времени пробуждения.