Clevo N850ELがUbuntu 18.04.1を頻繁にクラッシュ/フリーズさせる
CPU i7-8750H、32GB RAMを搭載した最新のClevo N850EL（一部の地域ではProstarまたはSager NP4850ともブランド化可能）を購入しました。
Ubuntu 18.04.1は正常にインストールされ、ランダムに（45分+/- 30分後）クラッシュするまで、正常に動作しているように見えます（作業、入力、インストール、およびソフトウェアの削除）。
（NVIDIA MX150とIntel HDグラフィックの両方があります。UbuntuでIntel HDグラフィックを使用していると思います）。
クラッシュは完全にフリーズします（マウスは移動せず、TCP/IP接続はフリーズして切断され、 Ctrl+Alt+Del 応答しないため、電源ボタンを5秒間押して再起動する必要があります）。
/var/log/syslogまたは/var/log/kern.logには、フリーズ後の異常なエントリはありません。
だから、それは私が知っているログ/トレースのない、単に不思議なクラッシュ「フリーズ」です。
（編集：2018-08-25 SysRqを有効にしましたが、ネットワークサービスもフリーズしているため、リモートでsshしてSysRqとキーボードを要求することはできません Alt+SysRq+command 凍結しているようです）。
1日目には、明らかにこのPCに付属しているWindows 10の実行と同じ問題がありました。
しかし、Windows 10 1803にアップグレードすると問題はなくなりました（プロンプトが表示されたすべての累積パッチと複数回の再起動を含む）。 Windows 10 1803で完全に安定しました。
Linuxでの「新しいハードウェア」の問題のようで、Windowsは最近克服しました。
私は何をすべきか ？ Ubuntuでアップストリームカーネルを使用する必要がありますか？ （どちらか？）（問題がカーネルにあるかどうかを確認するためだけに、新しいカーネルで終日実行できるUbuntuのUSBペンバージョンはありますか？ランチパッドに移動して問題を開く必要がありますか？）
編集：カーネルは4.15.0-32-generic
# 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）で起動し、rootとしてコマンドラインからネットワークマネージャーとWiFiをオンにします（---（https://help.ubuntu.com/community/NetworkManager を参照） ）、ネットワーク上で数時間ファイルをコピーしました。
この問題は、コンソールモードでは発生しません。コンソールモードからシステムに大きな負荷をかけることはありませんでしたが、ネットワークから数GBのファイルをコピーし、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独自のドライバーでも同じです。
インテルに戻り、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
インテルのビデオドライバーでも、noveauが無効になっていても問題は同じです。
WiFiアダプターを認識しませんでしたが、GNOMEデスクトップモードでは数時間安定しているように見えました（有線イーサネットを介してディスクにいくつかのGBのファイルをコピーしながら2時間30分実行しました）。 （後でこのDebianテストに戻り、頻繁にクラッシュ/フリーズすることを示しました。）
しかし、新しい希望に満ちた私は、アップストリームカーネルを試すことにしました（ https://wiki.ubuntu.com/Kernel/MainlineBuilds を参照）
まず、カーネル4.17.19-generic AMD64を試しました。稼働時間の最初の5分間でクラッシュ/フリーズします。 （また...問題は同じままです）.
それから、カーネル4.18.5-generic AMD64を試しました。数時間（2時間以上）は正常に動作しているように見えましたが、フリーズして再起動しました。翌日にさらにテストを行うと、問題が残っているようです（再起動すると常にクラッシュします）。 （私はWiFiを無効にし、有線イーサネットのみを使用しようとしましたが、問題は最終的に再び発生します。注：ホットリブート後にDHCPによって有線イーサネットが失われたようです）。
（補足：2：一方、/var/log/kern.logで関連するタイムアウトエラーを引き起こしていたため、noveauドライバーをブラックリストから外しました。「センサー」ユーティリティは、3Dアダプターの511ºC温度を報告します:-)
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ペンとして使用しました、しかし通常どおりクラッシュ/フリーズしました。
（追記：18.10 GNOMEコントロールパネルでは、使用中のグラフィックカードが表示されませんでした。「情報」項目を要求するとクラッシュまたはフリーズしました）。
とにかく制限されたVESAグラフィックモードを使用する方法はありますか？ （私は buntu 16.10でVESAドライバーを強制する 成功しませんでした）。
編集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
カーネルパラメータ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-grubSudo reboot
次を使用して、許可される最大CPU C-Stateを確認します。
cat /sys/module/intel_idle/parameters/max_cstate
https://bugzilla.kernel.org/show_bug.cgi?id=109051 に関する詳細情報
簡単な説明 ++
CPUがアイドル状態のときにエネルギーを節約するために、CPUに低電力モードに入るように命令することができます。各CPUには複数の電源モードがあり、それらはまとめてC-statesまたはC-modes.と呼ばれます。
これらのモードのアイデアは、CPU内のアイドルユニットからクロック信号と電力をカットすることです。電圧を下げるか、完全にシャットダウンしてエネルギーを節約するのと同じ数のユニットを停止します（クロックを切ることによって）。一方、CPUが「ウェイクアップ」し、再び100％動作可能になるには、より多くの時間が必要であることを考慮する必要があります。これらのモードはC-statesとして知られています。それらは通常、通常のCPU動作モードであるC0で開始されます。つまり、CPUは100％オンになります。 C数が増えると、CPUスリープモードが深くなります。つまり、オフになる回路と信号が多くなり、CPUがC0モードに復帰する（つまり、ウェイクアップする）時間が長くなります。各モードは名前でも知られており、いくつかのモードには異なる節電レベル（したがってウェイクアップ時間）を持つサブモードがあります。
