search for: kworker

https://bugs.freedesktop.org/show_bug.cgi?id=77073 Priority: medium Bug ID: 77073 Assignee: nouveau at lists.freedesktop.org Summary: [nouveaun NVE0] Attaching displayport spawns kworker taking up 100% cpu QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All) Reporter: daleha at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: un...

...ff/cache > KiB Swap: 0 total, 0 free, 0 used. 21951812 avail Mem > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 91 root 20 0 0 0 0 R 94.1 0.0 1540:35 kworker/7:1 > I suggest trying out the suggestions listed here: https://lkml.org/lkml/2011/3/31/68 In particular, if you look at the PID of the kworker using nearly 100% of a core, you could run: (using the above output from top) # cat /proc/91/stack And you'll see what funct...

On Mon, Apr 20, 2015 at 09:00:07AM -0400, Martes wrote: > Greetings again everyone. > > Can someone please respond to this? You just posted yesterday... Anyway, you didn't give much context. I can see from a google search why you provided the interrupts output, but judging from what you posted, that's not the problem. Perhaps you have a CPU task that's running at 100%?

...ponse at all is just disappointing. Thanks for any help that can be provided. Respectfully, Martes G Wigglesworth From: "Martes" <mailinglistmember at mgwigglesworth.net> To: "centos" <centos at centos.org> Sent: Sunday, April 19, 2015 4:46:12 PM Subject: kworker 100% of single core on mulit-core processor usage inquiry Greetings everyone. I am experiencing the kworker issue where a kworker is using 100% of a given core. This behavior was only observed after having installed a new water cooler, to replace a cooler that had died. (Sealed closed loop de...

Greetings everyone. I am experiencing the kworker issue where a kworker is using 100% of a given core. This behavior was only observed after having installed a new water cooler, to replace a cooler that had died. (Sealed closed loop device from Corsair) The processor is staying around 40 degrees celsius as reported by the MB UEFI interface. (k...

...ge. Adding the 'last CPU used' field to top indicates that the R process is hopping from core to core quite frequently. Using taskset to set an affinity to one core results in CPU usage more typically in the 40-60% range with no migration/X usage. But the core starts sharing time with a kworker task. renice'ing doesn't seem to change anything. If I had to guess, I would think that the kworker task is from R trying to re-arrange things in memory to make space for my large objects. 2 machines: - 128 and 256 GiB RAM, - dual processor Xeons (16 cores + hyperthreading, 32 tota...

No problemos with x86_64, however on i686 kworker/u16:57: page allocation failure: order:0, mode:0x284000 CPU: 0 PID: 1425 Comm: kworker/u16:57 Not tainted 3.18.0-0.rc5.git0.1.fc22.i686+debug #1 Workqueue: events_unbound async_run_entry_fn Call Trace: [<c0b2b55a>] dump_stack+0x48/0x60 [<c056f3d4>] warn_alloc_failed+0xd4/0x110 [<c...

...ndler before the > interrupt is finally disabled. This can be a problem however, since > nouveau_connector_detect() currently grabs a runtime power reference > when handling connector probing. This will deadlock the runtime suspend > handler like so: > > [ 861.480896] INFO: task kworker/0:2:61 blocked for more than 120 seconds. > [ 861.483290] Tainted: G O 4.18.0-rc6Lyude-Test+ #1 > [ 861.485158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 861.486332] kworker/0:2 D 0 61 2 0x80000000 >...

...to enable it, which triggers an atomic commit which triggers a call to pm_runtime_get_sync() - the output poll thread deadlocks the pm core waiting for the pm core to finish the autosuspend request while the pm core waits for the output poll thread to finish Sample: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events ou...

Latest version of https://patchwork.freedesktop.org/series/46815/ , with one small change re: ilia Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

...ng from anywhere that calls > drm_fb_helper_hotplug_event(). Since most drivers use > drm_fb_helper_output_poll_changed() as their output_poll_changed > handler, this can happen in every single context that can fire off a > hotplug event. An example: > > [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. > [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 > [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 > [ 246.677580]...

...28 used, 22387396 buff/cache KiB Swap: 0 total, 0 free, 0 used. 21951812 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 91 root 20 0 0 0 0 R 94.1 0.0 1540:35 kworker/7:1 This is the only worker that is currently taking up 100% of whatever core it is on. (Right now it is assigned core number 8) My kernel is version 3.10.0-229.1.2.el7.x86_64. I don't really have very much context to provide other than it wasn't a problem prior to rest...

...ndering problems happening since upgrading from kernel 3.10.0-862.14.4.el7.x86_64 to 3.10.0-957.1.3.el7.x86_64. The users have seen this behavior after logging into Gnome, but with out any additional applications running (Chrome/Firefox/LibreOffice, etc.). I can see in top that there are multiple kworker processes consuming a large amount of CPU time and unusually high load averages - like 5-7 range on the 5 minute average, normal load average would be between 1-2 for these users. At one point, while troubleshooting with a user, I was logged in remotely while the user was working on the desktop wh...

...tor's hotplug interrupt handler before the interrupt is finally disabled. This can be a problem however, since nouveau_connector_detect() currently grabs a runtime power reference when handling connector probing. This will deadlock the runtime suspend handler like so: [ 861.480896] INFO: task kworker/0:2:61 blocked for more than 120 seconds. [ 861.483290] Tainted: G O 4.18.0-rc6Lyude-Test+ #1 [ 861.485158] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 861.486332] kworker/0:2 D 0 61 2 0x80000000 [ 861.487044] Work...

...eliably fail with -EBUSY for me: # mount /dev/sdb2 /mnt/scratch; umount /mnt/scratch; mkfs.btrfs -f /dev/sdb2 ... unable to open /dev/sdb2: Device or resource busy because mkfs.btrfs tries to open the device O_EXCL, and somebody still has it. Using systemtap to track bdev gets & puts shows a kworker thread doing a blkdev put after mkfs attempts a get; this is left over from the unmount. Adding an rcu_barrier() to btrfs_close_devices() causes unmount to wait until all blkdev_put()s are done, and the device is truly free once unmount completes. Signed-off-by: Eric Sandeen <sandeen@redhat.co...

...to enable it, which triggers an atomic commit which triggers a call to pm_runtime_get_sync() - the output poll thread deadlocks the pm core waiting for the pm core to finish the autosuspend request while the pm core waits for the output poll thread to finish Sample: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events ou...

Next version of https://patchwork.freedesktop.org/series/46815/ Same as previous version, but some small changes made to commit messages and acks/rbs have been added Lyude Paul (5): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend() drm/nouveau: Fix deadlock with fb_helper with async RPM requests

https://bugs.freedesktop.org/show_bug.cgi?id=76732 Priority: medium Bug ID: 76732 Assignee: nouveau at lists.freedesktop.org Summary: Kworker using 100% CPU QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: patrick.clara at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified...

Latest version of https://patchwork.freedesktop.org/series/46815/ with some significant improvements: - I finally figured out a clean way to do this entirely with runtime PM helpers, no avoiding grabbing refs required! - Since this new method removes the need for a lot of the other changes I made (although we probably still want those changes, but not for fixing these deadlocks)

...eir rpm_get/put dance way down into the low-level callbacks. That then allows you to fix all the trouble with probing, i2x, dp_aux and stuff abitrarily nesting (since rpm itself is refcounted). But I'm not really sure why nouveau is different here. -Daniel > > [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. > [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 > [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 > [ 246.677580]...