Kworker est à 100% – Je pense que j'ai tout essayé!

Merci de vérifier celui-ci.

jonathan@melange:~$ top top - 05:21:08 up 44 min, 2 users, load average: 1.21, 1.68, 1.98 Tasks: 351 total, 2 running, 349 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.3 us, 14.0 sy, 2.1 ni, 70.4 id, 8.9 wa, 0.0 hi, 0.3 si, 0.0 st GiB Mem : 15.579 total, 0.173 free, 4.141 used, 11.264 buff/cache GiB Swap: 15.910 total, 15.868 free, 0.042 used. 11.014 avail Mem PID PPID UID USER RUSER TTY TIME+ %CPU %MEM S COMMAND 67 2 0 root root ? 22:22.40 100.0 0.0 R kworker/0:1 

La configuration – Ubuntu 16.10. 4.8.0-41-générique. Ordinateur portable intel moderne avec des pilotes Nvidia et pas tout à fait parfait wifi. Faites le moi savoir et je peux vous fournir toutes les informations dont vous avez besoin. Je les ai acceptés et je ne vois aucune raison de croire qu'ils sont impliqués dans cette question.

J'ai déjà posé cette question sur askubuntu et quelques fois sur Freenode`ubuntu au cours de la semaine dernière, mais personne ne répondra même à ma question 🙁

J'ai pris quelques rapports de perf avec

 sudo perf record -a -g sleep 10 sudo perf report 

Avec quelques résultats

 Samples: 92K of event 'cycles:ppp', Event count (approx.): 58330337004406 Children Self Command Shared Object Symbol ◆ + 94.27% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry ▒ + 94.27% 0.00% swapper [kernel.kallsyms] [k] start_secondary ▒ + 77.29% 0.00% swapper [kernel.kallsyms] [k] schedule_preempt_disabled ▒ - 77.29% 77.29% swapper [kernel.kallsyms] [k] __schedule ▒ 77.29% start_secondary ▒ cpu_startup_entry ▒ - schedule_preempt_disabled ▒ - 77.29% schedule ▒ __schedule ▒ + 77.29% 0.00% swapper [kernel.kallsyms] [k] schedule ▒ + 16.99% 0.00% swapper [kernel.kallsyms] [k] call_cpuidle ▒ + 16.99% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter ▒ + 16.99% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter_state ▒ - 16.99% 16.99% swapper [kernel.kallsyms] [k] intel_idle ▒ 16.98% start_secondary ▒ cpu_startup_entry ▒ call_cpuidle ▒ - cpuidle_enter ▒ - 16.98% cpuidle_enter_state ▒ intel_idle ▒ + 5.65% 0.00% pool [unknown] [.] 0000000000000000 ▒ + 5.65% 5.65% pool libc-2.24.so [.] re_comstack_internal ▒ + 5.65% 0.00% pool [unknown] [.] 0x00007f049804d628 ▒ + 5.65% 0.00% pool [unknown] [.] 0x00007f049804d6a8 ▒ + 5.65% 0.00% pool [unknown] [.] 0x00007f049804d3d8 ▒ + 5.65% 0.00% pool [unknown] [.] 0x00007f049804d768 ▒ Cannot load tips.txt file, please install perf! 

J'ai vérifié dmesg, surchauffer les messages (c'est pourquoi je suis ici) et d'autres messages sur MSFT0101: 00 qui je crois est quelque chose todo avec le kernel ne reconnaissant pas mon module bios TPM activé. Je pense que cela devrait être insignifiant dans cette affaire.

Il y a une autre question sur les threads kworker suggérant ce qui suit selon ce thread

 $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt (wait a few secs) ^C 

mais ça ne marche pas!

 jonathan@melange:~$ sudo mount -t debugfs nodev /sys/kernel/debug mount: nodev is already mounted or /sys/kernel/debug busy jonathan@melange:~$ sudo echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event bash: /sys/kernel/debug/tracing/set_event: Permission denied jonathan@melange:~$ sudo cat /proc/67/stack [<ffffffffffffffff>] 0xffffffffffffffff 

Des idées?!

Mettre à jour

Avant de soumettre cette question, j'avais utilisé Kworker, qu'est-ce que c'est et pourquoi est-ce que ça consum tellement de CPU? comme reference. J'avais donc essayé de désactiver / désinstaller des process de longue durée tels que dropbox, insync (google drive), crashplan, keybase, fond de variété, indicateur multiload, psensor, guake. (J'ai l'printing d'avoir une configuration assez lisse la plupart du time …) mais rien ne semblait aider.

Il y avait eu d'autres questions qui se cachent autour de suggérer des dysfonctionnements du wifi, des pilotes nvidia ou des pilotes USB. Mais rien dans mes journaux ne suggérait cela non plus. Un peu reconnaissant comme presque toujours la solution dans ceux-ci était tout simplement find les nouveaux pilotes nvidia, mettre à jour le kernel, ou "traiter avec elle". Mon ordinateur portable est déjà à jour, je n'ai aucune raison d'entreprise de restr sur 16.04 et j'ai déjà le nvidia ppa activé, comme avec les pilotes Intel, donc ce n'était pas beaucoup d'aide.

Peut-être le kworker était en fait le résultat de la surchauffe de l'ordinateur portable -> cpu throttling + cpu fan management. Pas la cause. Comme suggéré par Stop cpu de surchauffe Donc, je viens d'utiliser de l'air comprimé pour nettoyer les ventilateurs (ne pense pas que ce serait un problème sur un ordinateur portable seulement 9 mois mais il y avait effectivement un peu de poussière) et d'enquêter sur le thermal-conf.xml qui suggère que le ventilateur entre à 55 ° C (bien que je travaille encore sur ce que je peux faire ici)

Penser que cela peut être la solution. Reviendra bientôt.

Mise à jour 2

Donc faire la mise à jour bios Acer totalement gâché tout ce qui concerne ma configuration de secureboot et corrompu les files efi donc il m'a fallu quelques jours pour savoir comment régénérer les keys efi ubuntu et les keys efi windows.

J'ai essayé de nettoyer la poussière, et cela a certainement aidé pendant les deux jours jusqu'à ce que je commence avec les problèmes de bios.

Mais le kworker est de return (et oui c'est pareil pour autant que je sache). J'ai aussi plus d'informations maintenant. Je peux voir que le CPU ne se limite pas, mais plutôt restr au maximum. Le ventilateur fonctionne, mais l'appareil est seulement assis autour de la marque de 60 degrés, donc je n'appellerais pas ce sérieux surchauffe.

Les commands de l'autre thread nécessitent d'élever l'user root, pas seulement d'utiliser sudo. donc sudo su et puis get la trace de la stack donne le suivant.

 [<ffffffff98a9dcea>] worker_thread+0xca/0x500 [<ffffffff98aa40d8>] kthread+0xd8/0xf0 [<ffffffff992a071f>] ret_from_fork+0x1f/0x40 [<ffffffffffffffff>] 0xffffffffffffffff 

Ne me semble pas particulièrement utile.

Je crois que l'erreur "Permission denied" est facilement résoluble en manipulant /sys/kernel/debug/tracing/set_event tant que root.

Une autre idée est de déterminer si votre problème est présent dès le départ ou si quelque chose le triggers. Dans le premier cas, l'approche naïve serait de démarrer avec la plupart des pilotes désactivés, puis de les réactiver un par un pour find le coupable.

Dans le cas où quelque chose triggers le problème, nous devrons savoir ce que c'est. J'ai vu des cas où l'utilisation excessive du processeur a été déclenchée par un pic dans IO disque, et tuning /proc/sys/vm/ parameters liés à la caching a beaucoup aidé.

Cette question semble abandonnée car elle n'a plus été mise à jour, mais j'essaierai de toute façon: j'en ai vu des cas où des interruptions excessives se sont produites, ralentissant la machine. Cela pourrait être vérifié avec grep . -r /sys/firmware/acpi/interrupts/ grep . -r /sys/firmware/acpi/interrupts/ .

Connexes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793 https://bugzilla.kernel.org/show_bug.cgi?id=53071 https://forum.ubuntuusers.de/ sujet / kworker-cpu-load / (allemand)