# [SOLVED] kworkers eating my cpu (again)

## Fran

Sometimes I get a constant 30% use of my puny CPU (ULV SU4100) by one or two kworker threads. It isn't very annoying in the console, but on X it causes everything to stutter like crazy (including the mouse cursor). The computer gets unusable until it passses (sometimes in seconds, sometimes only after a reboot) or it simply freezes to a halt, forcing me to pull the battery.

In the past I already had this problem in this same laptop. I solved it by disabling drm kms polling. But recently (probably with 3.8, I'm not sure) it has appeared again, even with drm polling disabled.

(edit) I'm not alone: 

https://bbs.archlinux.org/viewtopic.php?pid=1248190

http://verahill.blogspot.com.es/2013/03/368-slow-mouse-and-keyboard-triggered.html

Also with 3.8, also unrelated to drm kms polling. Does anyone know how to find out which kernel component causes the kworkers to get crazy? I could do a git bisect, but it's a big pain in the ass in a slow processor like the SU4100. I don't see anything weird in /sys/firmware/acpi/interrupts.Last edited by Fran on Tue Apr 09, 2013 9:30 am; edited 1 time in total

----------

## aCOSwt

Can you spot on your system any particular interrupt "going mad" ? any particular thread displaying an unusual stime ?

----------

## Fran

 *aCOSwt wrote:*   

> Can you spot on your system any particular interrupt "going mad" ? any particular thread displaying an unusual stime ?

 

Nope and nope.

(edit)  Wait, yeah. i915 starts interrupting like crazy:

```
           CPU0       CPU1       

  0:      35433      35563   IO-APIC-edge      timer

  1:        980        917   IO-APIC-edge      i8042

  8:         24         20   IO-APIC-edge      rtc0

  9:         68         72   IO-APIC-fasteoi   acpi

 12:      13887      13928   IO-APIC-edge      i8042

 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb2, uhci_hcd:usb5

 19:          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb4

 23:         14         15   IO-APIC-fasteoi   uhci_hcd:usb3, ehci_hcd:usb6

 42:     113836     113519   PCI-MSI-edge      i915

 43:      15801      15858   PCI-MSI-edge      ahci

 44:       5804       5244   PCI-MSI-edge      iwlwifi

 45:        108        113   PCI-MSI-edge      snd_hda_intel

NMI:          0          0   Non-maskable interrupts

LOC:     177735     180565   Local timer interrupts

SPU:          0          0   Spurious interrupts

PMI:          0          0   Performance monitoring interrupts

IWI:          0          0   IRQ work interrupts

RTR:          0          0   APIC ICR read retries

RES:      34498      22338   Rescheduling interrupts

CAL:        104         61   Function call interrupts

TLB:       1189       1143   TLB shootdowns

TRM:      12908      12908   Thermal event interrupts

THR:          0          0   Threshold APIC interrupts

MCE:          0          0   Machine check exceptions

MCP:          2          2   Machine check polls

ERR:          0

MIS:          0
```

Doesn't seem much higher than the rest, but that's because it had already stopped when I printed it. It was growing at a rate of 1000 interrupts/second instead of the usual 30 per second.

So, again it's caused by the damned i915 driver, like the last time it happened in 2.6 kernels. But this time it's not drm kms polling, unless there is a bug in 3.8 that ignores the setting in /sys/module/drm_kms_helper/parameters/poll

----------

## Fran

Kernel 3.9_rc4 makes X usable again (even when i915 starts interrupting X doesn't stutter) but the i915 interrupt problem persists.

----------

## aCOSwt

 *Fran wrote:*   

> 
> 
> ```
>            CPU0       CPU1       
> 
> ...

 

should'nt kworkers Heating my cpu be the real title of your thread ?   :Wink: 

----------

## Fran

 *aCOSwt wrote:*   

>  *Fran wrote:*   
> 
> ```
>            CPU0       CPU1       
> 
> ...

 

I actually have no idea what those events mean. Temperature doesn't go above 45º (coretemp).

Oh well. I suppose I'll be happy with 3.9-rc for now. I hate these random kernel bugs. I hope someone with a better CPU and larger hard disk is willing to bisect.

----------

## gamanakis

I did a bisecting and the following seems to be the culprit.

Please someone test and report.

https://bbs.archlinux.org/viewtopic.php?pid=1254285#p1254285

----------

## Fran

 *gamanakis wrote:*   

> I did a bisecting and the following seems to be the culprit.
> 
> Please someone test and report.
> 
> https://bbs.archlinux.org/viewtopic.php?pid=1254285#p1254285

 

I've seen the post in arch taking to the upstream bugs. Marking this as solved.

https://patchwork.kernel.org/patch/2400621/

https://patchwork.kernel.org/patch/2402211/

----------

