web-dev-qa-db-fra.com

Clevo N850EL plante / gèle fréquemment Ubuntu 18.04.1

Je viens d'acheter un tout nouveau Clevo N850EL (dans certaines régions, les marques Prostar ou Sager NP4850 sont également disponibles), avec un processeur i7-8750H et 32 ​​Go de RAM.

Ubuntu 18.04.1 installe bien et semble fonctionner correctement (avec moi, je saisis, saisis, l’installation et la suppression de logiciels), jusqu’à ce qu’il se bloque après un certain temps aléatoire (après 45min +/- 30min).

(Il comporte à la fois des graphiques NVIDIA MX150 et Intel HD. Je crois que je tourne avec des graphiques Intel HD sous Ubuntu).

Le crash est un gel complet (la souris ne bouge pas, les connexions TCP/IP sont gelées et se cassent, Ctrl+Alt+Del ne répond pas, doit être redémarré en appuyant sur le bouton d'alimentation pendant 5 secondes).

Il n'y a pas d'entrée anormale dans /var/log/syslog ou /var/log/kern.log avant ou après le gel.

Donc, c'est juste un crash mystérieux "gel", sans journal/trace que je sache.

(Edit: 2018-08-25 J'ai activé SysRq, mais les services réseau sont également gelés. Je ne peux donc pas ssh à distance et demander SysRq et le clavier. Alt+SysRq+command semble gelé aussi).

Le premier jour, il a apparemment eu le même problème sous Windows 10 fourni avec ce PC.

Mais le problème a disparu après la mise à niveau vers Windows 10 1803 (avec tous les correctifs cumulés demandés et plusieurs redémarrages). Maintenant, il est complètement stable sous Windows 10 1803.

Cela ressemble à un problème de "nouveau matériel" sous Linux, que Windows a récemment surmonté.

Que devrais-je faire ? Devrais-je essayer d'utiliser un noyau en amont avec Ubuntu? (Lequel?) (Existe-t-il une version à stylet USB d'Ubuntu que je puisse exécuter toute la journée avec un nouveau noyau simplement pour voir si le problème provient du noyau? Devrais-je accéder au tableau de bord et ouvrir un problème?)

(Je ne veux pas vraiment travailler sous Windows ... :

Edit: le noyau est 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)

Édition 2018-08-24: Mise à niveau vers le noyau 44.15.0-33-generic. Le problème reste le même.

Démarré en mode console (option GRUB systemd.unit = rescue.target), activation du gestionnaire de réseau et du WiFi à partir de la ligne de commande en tant que root (voir --- (https://help.ubuntu.com/community/NetworkManager ) et copié certains fichiers sur le réseau pendant quelques heures.

Le problème ne se produit pas en mode console. Je n’ai pas mis beaucoup de charge sur le système en mode console, mais j’ai réussi à copier quelques Go de fichiers du réseau, et avec un temps de disponibilité supérieur à 8 heures, avec quelques services et processus en cours, je pense pouvoir supposer que le même blocage/gel ne se produit pas en mode console.

Installé les pilotes propriétaires nvidia-driver-390 et basculé vers NVIDIA avec les commandes:

Sudo ubuntu-drivers devices
Sudo ubuntu-drivers autoinstall
Sudo prime-select nvidia
Sudo reboot
nvidia-settings # just to check that it seems installed

Le problème reste le même avec les pilotes propriétaires nvidia-driver-390.

Retourne à Intel et liste noire le pilote du noyau 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

Le problème reste le même avec les pilotes vidéo intel, avec noveau désactivé.

Il ne reconnaissait pas l’adaptateur WiFi, mais il semblait stable en mode bureau GNOME pendant quelques heures (je le laissais fonctionner pendant 2h30 tout en copiant quelques Go de fichiers via Ethernet filaire sur disque). (Des tentatives ultérieures pour revenir à ces tests Debian ont montré que celui-ci plantait/se bloquait fréquemment aussi.)

Mais, rempli d'un nouvel espoir, j'ai décidé d'essayer un noyau Upstream (voir https://wiki.ubuntu.com/Kernel/MainlineBuilds )

J'ai d'abord essayé le noyau 4.17.19-generic AMD64. Accident/gel dans les 5 premières minutes de disponibilité. (Et encore ... le problème reste le même) ..

Ensuite, j'ai essayé le noyau 4.18.5 générique AMD64. Il a semblé fonctionner correctement pendant quelques heures (plus de 2 heures), mais a ensuite gelé et redémarré. Plus de tests le lendemain, et le problème semble persister (et se bloque toujours au redémarrage). (J'ai essayé de désactiver le WiFi et de n'utiliser que l'Ethernet câblé, mais le problème se reproduit. Note: je semble perdre l'Ethernet câblé par DHCP après un redémarrage à chaud).

(Note 2: pendant ce temps, j'ai supprimé le pilote noveau de la liste noire, car il provoquait des erreurs de temporisation dans /var/log/kern.log. L'utilitaire "capteurs" signale une température de 511ºC sur l'adaptateur 3D :-)

Edit 2018-08-26 kdump: J'ai essayé de configurer kdump (comme dans https://help.ubuntu.com/lts/serverguide/kernel-crash-dump.html ), mais, lorsque je le teste en mode graphique, je rencontre exactement le même problème que celui décrit dans kdump n'enregistre pas le crash (le système se bloque, pas de message, pas de redémarrage, pas de crash, sous /var/crash/ ).

Si je déclenche une panne du noyau en mode console avec

echo c > /proc/sysrq-trigger

je vois alors les messages d’incident sur la console et ils sont partiellement enregistrés sur /var/log/syslog lors du prochain redémarrage. Toujours pas de crash dumps sous /var/crash.

Donc je suis un peu perdu. Que devrais-je essayer?

2018-08-27: Il n’ya pas d’erreurs de mémoire DRAM que je puisse trouver (memtest86.com exécuté toute la nuit - 6 heures et 16 minutes) et aucune erreur trouvée.

Le démarrage UEFI est désactivé.

J'ai téléchargé la version quotidienne d'Ubuntu 18.10 à l'adresse http://cdimage.ubuntu.com/daily-live/20180827/cosmic-desktop-AMD64.iso et l'ai utilisée pendant quelques minutes comme un stylo USB dynamique. , mais s'est écrasé/gelé comme d'habitude.

(PS: dans le panneau de configuration GNOME 18.10, je ne pouvais pas voir quelle carte graphique était en cours d'utilisation. Elle s'est écrasée/figée lorsque j'ai demandé l'élément "Informations").

Est-il possible d'utiliser un mode graphique VESA limité? (J'ai essayé Force VESA driver dans Ubuntu 16.1 sans succès).

Edit 2018-08-28: Ajout des informations demandées par l'utilisateur 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
driverskernel18.04hardwarefreeze
2
user1544553

Essayez d'utiliser le paramètre du noyau: intel_idle.max_cstate=1

faire ces étapes:

  • Sudo nano /etc/default/grub
  • remplace la ligne GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" par GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
  • enregistrez-le (CTRL + O)
  • Sudo update-grub
  • Sudo reboot

Confirmez l’état C maximum autorisé de la CPU avec:

 cat /sys/module/intel_idle/parameters/max_cstate

Plus d'informations sur https://bugzilla.kernel.org/show_bug.cgi?id=109051

Brève description ++

Afin d'économiser de l'énergie lorsque la CPU est inactive, il est possible de lui demander de passer en mode basse consommation. Chaque unité centrale a plusieurs modes d'alimentation et ils sont appelés collectivement C-states ou C-modes..

L'idée de ces modes est de couper le signal d'horloge et l'alimentation des unités inactives à l'intérieur de la CPU. Autant d'unités que vous arrêtez (en coupant l'horloge) que vous réduisez la tension ou même que vous vous éteignez complètement pour économiser de l'énergie. D'autre part, vous devez prendre en compte qu'il faut plus de temps au processeur pour se "réveiller" et être à nouveau opérationnel à 100%. Ces modes sont connus sous le nom de états C . Ils démarrent généralement en C0, qui correspond au mode de fonctionnement normal de la CPU, c’est-à-dire que la CPU est allumée à 100%. Avec l’augmentation du nombre C, le mode de veille de la CPU est plus profond, c’est-à-dire que davantage de circuits et de signaux sont désactivés et que le CPU a besoin de plus de temps pour revenir en mode C0, c’est-à-dire pour se réveiller. Chaque mode est également connu sous son nom et plusieurs d’entre eux ont des sous-modes avec différents niveaux d’économie d’énergie - et donc de temps de réveil.

c-states

++ de https://Gist.github.com/wmealing/2/dd2b543c4d3cff6cab7/

4
abu_bua