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


++ с https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7/

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