Clevo N850EL часто отказывает/замораживает Ubuntu 18.04.1

Я просто купил совершенно новый Clevo N850EL (в некоторых регионах, может также выпущенный под брендом Прозвездой или Sager NP4850), с ЦП i7-8750H, 32 ГБ RAM.

Ubuntu 18.04.1 устанавливает хорошо и, кажется, хорошо работает (со мной работа, ввод, установка и удаление программного обеспечения), пока это не отказывает после некоторого случайного времени (после 45 минут + минута/-30).

(Это имеет и NVIDIA MX150 и Intel HD Graphics. Я полагаю, что работаю с Intel HD Graphics в соответствии с Ubuntu).

Катастрофический отказ является полным замораживанием (мышь не перемещается, соединения TCP/IP становятся замороженными и повреждение, Ctrl+Alt+Del не отвечает, должен быть перезагружен путем требования кнопки питания в течение 5 секунд).

Нет никакой аварийной записи в /var/log/syslog или /var/log/kern.log прежде после замораживания.

Так, это - просто таинственный катастрофический отказ "замораживание" без журнала/трассировки, о котором я знаю.

(Редактирование: 25.08.2018 я включил SysRq, но сетевые службы замораживаются также, таким образом, я не могу ssh удаленно и попросите SysRq и клавиатуру, Alt+SysRq+command кажется замороженным также).

В 1-й день это имело, по-видимому, ту же проблему, запускающую Windows 10, который шел с этим ПК.

Но проблема исчезла, после того как я обновил до Windows 10 1803 (со всеми кумулятивными патчами, которые были запрошены, и несколько перезагрузок). Теперь его абсолютно стабильное в соответствии с Windows 10 1803.

Походит на "новые аппаратные средства" проблема в соответствии с Linux, тот Windows недавно имеет overcomed.

Что я должен сделать? Я должен попытаться использовать восходящие ядра с 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)

Редактирование 24.08.2018: Обновленный до 44.15.0-33-универсального ядра. Проблема остается тем же.

Загруженный в консольном режиме (опция GRUB systemd.unit=rescue.target), включил администратора сети и WiFi из командной строки как корень (см. 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 собственные драйверы.

Swicthed назад к 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.

Это не сделало распознал адаптер WiFi, но это казалось стабильным под настольным режимом GNOME в течение нескольких часов (я позволяю ему работать за 2h30 м при копировании некоторого ГБ файлов через проводной Ethernet к диску). (Более поздние попытки вернуться к этому тестированию Debian, показывал что это crashed/freezed часто также.)

Но, заполненный новой надеждой, я решил попробовать восходящее ядро (см. https://wiki.ubuntu.com/Kernel/MainlineBuilds),

Сначала я попробовал ядро 4.17.19-универсальный amd64. Катастрофический отказ/замораживание в первые 5 минут времени работы. (И снова... проблема остается тем же)..

Затем я попробовал ядро 4.18.5-универсальный amd64. Это, казалось, работало хорошо в течение нескольких часов (больше чем 2 часа), но затем заморозило и перезагрузило. Больше тестов в следующий день и проблема, кажется, остаются (и всегда отказывает на перезагрузке). (Я пытался отключить WiFi и использование только Проводного Ethernet, но проблема в конечном счете происходит снова. Заметка на полях: Я, кажется, освобождаю Проводной Ethernet DHCP после "горячей" перезагрузки).

(Заметка на полях 2: Между тем я de-blacklisted noveau драйвер, поскольку это вызывало связанные ошибки из-за тайм-аута в /var/log/kern.log. Утилита "датчиков" сообщает 511ºC температура относительно 3D адаптера :-)

Отредактируйте 26.08.2018 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.

Таким образом, я немного потерян. Что я должен попробовать?

Редактирование 27.08.2018: нет никаких ошибок памяти DRAM, которые я могу найти (memtest86.com runned всю ночь - 6 часов и 16 минут), и не нашел ошибок.

Начальная загрузка UEFI отключена.

Я загрузил Ubuntu 18.10, ежедневно создают по http://cdimage.ubuntu.com/daily-live/20180827/cosmic-desktop-amd64.iso и использовал его в качестве живого пера USB в течение нескольких минут, но отказал/заморозил, как обычно.

(PS: В 18,10 панелях управления GNOME я не видел, какая видеокарта использовалась. Это отказало/заморозило, когда я попросил "информационный" объект).

Там должен так или иначе использовать ограниченный VESA графический режим? (Я попробовал Силу драйвер VESA в Ubuntu 16.10 без успеха).

Редактирование 28.08.2018: Добавление информации, запрошенной пользователем 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
2
задан 29 August 2018 в 15:36

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

c-states


++ от https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7/

4
ответ дан 2 December 2019 в 02:12

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

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