Kworker-Thread hat eine hohe CPU-Auslastung

Ich habe einen Kworker-Thread mit hoher CPU-Auslastung, der dazu führt, dass mein Touchscreen sehr verzögert und nicht mehr reagiert. Beaglebone mit Debian laufen lassen.

 uname -r 4.1.15-ti-rt-r43  pid user pr ni virt res shr s %cpu %mem time+ command 90 root 20 0 0 0 0 R 34.7 0.0 14:16.48 kworker/u2:2 

Ich kann perf nicht installieren / verwenden, da ich einen 4.1.15-Kernel habe und perf nur in 3.16 verfügbar ist. Daher kann ich den Thread nicht durchlaufen

Ich habe mehrere Lösungen aus dem Internet ausprobiert, aber keine davon funktioniert.

1) https://stackoverflow.com/questions/10846747/origin-of-a-kworker-thread

 $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event $ cat /sys/kernel/debug/tracing/trace_pipe  

Ausgabe:

 python3-748 [000] d.h2 714.802127: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 kworker/u2:2-67 [000] d.h2 714.817350: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 kworker/u2:2-67 [000] d.h3 714.832576: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295 python3-745 [000] d.s3 714.834340: workqueue_queue_work: work struct=ddd22e08 function=mcp251x_tx_work_handler [mcp251x] workqueue=dcff0200 req_cpu=2 cpu=429496$ irq/145-can1-737 [000] d..2 714.835555: workqueue_queue_work: work struct=ddd22e18 function=mcp251x_irq_work_handler [mcp251x] workqueue=dcff0200 req_cpu=2 cpu=42949$ kworker/u2:2-67 [000] d.h2 714.847801: workqueue_queue_work: work struct=ddec2368 function=flip_worker workqueue=dcd80600 req_cpu=2 cpu=4294967295   $ cat /proc/90/stack [<ffffffff>] 0xffffffff 

2) Deaktivieren /sys/firmware/ascpi/gpe##

Dieser Ordner ascpi existiert jedoch nicht einmal auf meiner Beaglebone.

3) https://askubuntu.com/questions/33640/kworker-whit-isit-and-why-isit-hogging-so-much-cpu

echo l > /proc/sysrq-trigger um eine Rückverfolgung zu erzeugen, wird am Ende von ausgegeben dmesg

Ausgabe:

[ 3581.845525] sysrq: SysRq : Changing Loglevel [ 3581.850338] sysrq: Loglevel set to 1 

Das Problem ist, dass ich nicht verstehe, warum es dieses Problem gibt oder woher es entsteht - und dann, wie es zu lösen ist.

Ich habe eine GUI und auch CAN (Python-can / socketCAN). CAN-Nachrichten werden über die GUI gesteuert.

Das Verhalten, das ich gefunden habe, war: Wenn GUI startet - kein schwerer Kworker-Thread. Wenn CAN zum ersten Mal gestartet wird, verbraucht kworker thread 15-40% der CPU.

Ich habe einen Schalter, mit dem ich die CAN-Nachrichten nicht mehr senden kann (CAN ein / aus). Wenn ich nun CAN über die grafische Benutzeroberfläche ausschalte, verbraucht kworker thread 60% der CPU.

Ich nehme an, etwas läuft an, wenn die CAN-Schnittstelle zuerst aktiviert wird und dann durchgehend fortgesetzt wird. Wie kann ich das genau feststellen und beheben?

T