[gentoo-user] Kworker use >80% of CPU

[gentoo-user] Kworker use >80% of CPU

[Gleb Klochkov]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Hi. After computer starts,  in top, I have kworker used 80% of cpu.
It is a problem with ACPI IRQs, because it come to normal after i run

echo "disable" > /sys/firmware/acpi/interrupts/gpe08



> echo "disable" > /sys/firmware/acpi/interrupts/gpe1B
>

I tried to do it on startup by adding script to /etc/local.d/ but it
doesn't help.
Now I have 3.10.24-gentoo kernel, generated by genkernel, but I noticed
this problem few month ago.
Can you help me?

--------------------
С уважением, Клочков Глеб

[-- Attachment #2: Type: text/html, Size: 926 bytes --]

Re: [gentoo-user] Kworker use >80% of CPU

[Tom Wijsman]

On Tue, 21 Jan 2014 13:02:32 +0400
Gleb Klochkov <glebiuskv@gmail.com> wrote:

> Hi. After computer starts,  in top, I have kworker used 80% of cpu.
> It is a problem with ACPI IRQs, because it come to normal after i run
> 
> echo "disable" > /sys/firmware/acpi/interrupts/gpe08

That is called a GPE storm; you should be able to find a message about
it in `dmesg`, usually those resolve automatically so I wonder why that
is not the case here. Can you look for messages about GPE / interrupt
in the `dmesg` output?

You might also able to use one or another kernel parameter from

https://www.kernel.org/doc/Documentation/kernel-parameters.txt

in an attempt to fix up the ACPI IRQs, try those that mention ACPI, IRQ
and/or interrupt(s) in their name or description. Though; as this is a
trial and error approach, a specific message and a better idea of what
GPE 8 is might yield a better solution when searching this online.

As a second question, to figure out what '8' is; take a look at
`cat /proc/interrupts` where the last one or two columns of that line
give it a name. Feel free to share both `dmesg` and that output with us.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Kworker use >80% of CPU

[Gleb Klochkov]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

Tom, thank you for your answer.

$ dmesg >> http://bpaste.net/show/187533/
$ cat /proc/interrupts >> http://bpaste.net/show/187537/



--------------------
С уважением, Клочков Глеб


2014-03-07 22:49 GMT+04:00 Tom Wijsman <TomWij@gentoo.org>:

> On Tue, 21 Jan 2014 13:02:32 +0400
> Gleb Klochkov <glebiuskv@gmail.com> wrote:
>
> > Hi. After computer starts,  in top, I have kworker used 80% of cpu.
> > It is a problem with ACPI IRQs, because it come to normal after i run
> >
> > echo "disable" > /sys/firmware/acpi/interrupts/gpe08
>
> That is called a GPE storm; you should be able to find a message about
> it in `dmesg`, usually those resolve automatically so I wonder why that
> is not the case here. Can you look for messages about GPE / interrupt
> in the `dmesg` output?
>
> You might also able to use one or another kernel parameter from
>
> https://www.kernel.org/doc/Documentation/kernel-parameters.txt
>
> in an attempt to fix up the ACPI IRQs, try those that mention ACPI, IRQ
> and/or interrupt(s) in their name or description. Though; as this is a
> trial and error approach, a specific message and a better idea of what
> GPE 8 is might yield a better solution when searching this online.
>
> As a second question, to figure out what '8' is; take a look at
> `cat /proc/interrupts` where the last one or two columns of that line
> give it a name. Feel free to share both `dmesg` and that output with us.
>
> --
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
>

[-- Attachment #2: Type: text/html, Size: 2561 bytes --]

Re: [gentoo-user] Kworker use >80% of CPU

[Tom Wijsman]

On Thu, 20 Mar 2014 11:39:58 +0400
Gleb Klochkov <glebiuskv@gmail.com> wrote:

> Tom, thank you for your answer.
> 
> $ dmesg >> http://bpaste.net/show/187533/

There this can be seen:

    [   18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307
    [   18.074575] [drm] This can cause pipe underruns and display
    issues.
    [   18.074575] [drm] Please upgrade your BIOS to fix this.
    [   18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling back
    to bit banging on pin 2

Above your messages seem interesting; some expected value is wrong, it
also times out on a bus and then goes to use a pin instead. Not sure
how much of this is intended, but try to upgrade your BIOS as suggested.

> $ cat /proc/interrupts >> http://bpaste.net/show/187537/

So, that would be this:

    8: 63 0 0 0 IO-APIC-edge rtc0

Hmm, nothing about it in the dmesg; also, 63 seems low (on my system,
however, it's only 1 as I think my system uses something different).

You can try a different timer using this kernel parameter:

    clocksource=hpet

Another note-worthy thing:

    9: 699799454 0 0 0 IO-APIC-fasteoi acpi

That there are ~700 million ACPI interrupts seems abnormally high;
maybe the count is off by one, and 8 refers to 9? On my system, that's
been running for a while by now, it's only at ~6000 (six thousand).

Changing the ACPI related kernel parameters to try to get it supported
differently might be one thing to do here; other than that, it might be
something going on with the hardware (try disconnecting things?) so the
BIOS upgrade is certainly of interest.

Try the BIOS upgrade first, then play around with the parameters; if
things don't work out, I suggest you look for support on one of the
Linux kernel mailing lists (perhaps acpi-devel*). Good luck.

 * https://lists.sourceforge.net/lists/listinfo/acpi-devel

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-user] Kworker use >80% of CPU

[Volker Armin Hemmann]

Am 20.03.2014 11:24, schrieb Tom Wijsman:
> On Thu, 20 Mar 2014 11:39:58 +0400
> Gleb Klochkov <glebiuskv@gmail.com> wrote:
>
>> Tom, thank you for your answer.
>>
>> $ dmesg >> http://bpaste.net/show/187533/
> There this can be seen:
>
>     [   18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307
>     [   18.074575] [drm] This can cause pipe underruns and display
>     issues.
>     [   18.074575] [drm] Please upgrade your BIOS to fix this.
>     [   18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling back
>     to bit banging on pin 2
>
> Above your messages seem interesting; some expected value is wrong, it
> also times out on a bus and then goes to use a pin instead. Not sure
> how much of this is intended, but try to upgrade your BIOS as suggested.
>
>> $ cat /proc/interrupts >> http://bpaste.net/show/187537/
> So, that would be this:
>
>     8: 63 0 0 0 IO-APIC-edge rtc0
>
> Hmm, nothing about it in the dmesg; also, 63 seems low (on my system,
> however, it's only 1 as I think my system uses something different).
>
> You can try a different timer using this kernel parameter:
>
>     clocksource=hpet
>
> Another note-worthy thing:
>
>     9: 699799454 0 0 0 IO-APIC-fasteoi acpi
>
> That there are ~700 million ACPI interrupts seems abnormally high;
> maybe the count is off by one, and 8 refers to 9? On my system, that's
> been running for a while by now, it's only at ~6000 (six thousand).

uptime
 11:29:37 up 49 days, 15:48, 16 users,  load average: 0,38, 0,31, 0,39

   8:          0          0          0         48   IO-APIC-edge      rtc0
   9:          0          0          0          0   IO-APIC-fasteoi   acpi


>
> Changing the ACPI related kernel parameters to try to get it supported
> differently might be one thing to do here; other than that, it might be
> something going on with the hardware (try disconnecting things?) so the
> BIOS upgrade is certainly of interest.
>
> Try the BIOS upgrade first, then play around with the parameters; if
> things don't work out, I suggest you look for support on one of the
> Linux kernel mailing lists (perhaps acpi-devel*). Good luck.
>
>  * https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
imho he should first use a recent VANILLA kernel. 2.12 or 2.13.

And build a config without all that unneeded garbage. Also increase the
dmesg buffer. Most interesting stuff is missing.

Re: [gentoo-user] Kworker use >80% of CPU

[Gleb Klochkov]

[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]

Hi everybody, and thank you all!
Excuse me, I did not answer for a long time.
The problem is fixed for now. I delete all old kernels initrd and configs.
The only question now is: why just upgrade to new kernel don`t fix it. For
new kernel it should use default config, shouldn`t it?


--------------------
С уважением, Клочков Глеб


2014-03-21 14:31 GMT+04:00 Volker Armin Hemmann <volkerarmin@googlemail.com>
:

> Am 20.03.2014 11:24, schrieb Tom Wijsman:
> > On Thu, 20 Mar 2014 11:39:58 +0400
> > Gleb Klochkov <glebiuskv@gmail.com> wrote:
> >
> >> Tom, thank you for your answer.
> >>
> >> $ dmesg >> http://bpaste.net/show/187533/
> > There this can be seen:
> >
> >     [   18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307
> >     [   18.074575] [drm] This can cause pipe underruns and display
> >     issues.
> >     [   18.074575] [drm] Please upgrade your BIOS to fix this.
> >     [   18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling back
> >     to bit banging on pin 2
> >
> > Above your messages seem interesting; some expected value is wrong, it
> > also times out on a bus and then goes to use a pin instead. Not sure
> > how much of this is intended, but try to upgrade your BIOS as suggested.
> >
> >> $ cat /proc/interrupts >> http://bpaste.net/show/187537/
> > So, that would be this:
> >
> >     8: 63 0 0 0 IO-APIC-edge rtc0
> >
> > Hmm, nothing about it in the dmesg; also, 63 seems low (on my system,
> > however, it's only 1 as I think my system uses something different).
> >
> > You can try a different timer using this kernel parameter:
> >
> >     clocksource=hpet
> >
> > Another note-worthy thing:
> >
> >     9: 699799454 0 0 0 IO-APIC-fasteoi acpi
> >
> > That there are ~700 million ACPI interrupts seems abnormally high;
> > maybe the count is off by one, and 8 refers to 9? On my system, that's
> > been running for a while by now, it's only at ~6000 (six thousand).
>
> uptime
>  11:29:37 up 49 days, 15:48, 16 users,  load average: 0,38, 0,31, 0,39
>
>    8:          0          0          0         48   IO-APIC-edge      rtc0
>    9:          0          0          0          0   IO-APIC-fasteoi   acpi
>
>
> >
> > Changing the ACPI related kernel parameters to try to get it supported
> > differently might be one thing to do here; other than that, it might be
> > something going on with the hardware (try disconnecting things?) so the
> > BIOS upgrade is certainly of interest.
> >
> > Try the BIOS upgrade first, then play around with the parameters; if
> > things don't work out, I suggest you look for support on one of the
> > Linux kernel mailing lists (perhaps acpi-devel*). Good luck.
> >
> >  * https://lists.sourceforge.net/lists/listinfo/acpi-devel
> >
> imho he should first use a recent VANILLA kernel. 2.12 or 2.13.
>
> And build a config without all that unneeded garbage. Also increase the
> dmesg buffer. Most interesting stuff is missing.
>
>

[-- Attachment #2: Type: text/html, Size: 4527 bytes --]

Re: [gentoo-user] Kworker use >80% of CPU

[Alan McKinnon]

On 03/04/2014 17:20, Gleb Klochkov wrote:
> Hi everybody, and thank you all!
> Excuse me, I did not answer for a long time.
> The problem is fixed for now. I delete all old kernels initrd and configs.
> The only question now is: why just upgrade to new kernel don`t fix it.
> For new kernel it should use default config, shouldn`t it?


Please don't top post. It messes with people's mail apps.

The kernel is self-contained. You can have 1 or 100 kernels in /boot,
the only one that applies is the one you booted with. The other 99 have
exactly zero influence over the one that is running. The config settings
to kernel is built with are whatever you told it to use. If you don;t
run *config at all, then the default settings are used. If it builds and
runs, then it built and ran. The default config is nothing special, it's
just a config.

So that's not it, and it's not some magic influence.

Most likely you had stuff mixed up in /boot and the image you booted
from is not the one you thought you booted from. Or the initrd is out of
sync.

Something like that - it will be human error.

I'll say it again because it is important - there is no magic
interaction between kernel images and you can have as many as you want.


There's another possibility: some userspace app on your system was the
real problem and you updated it meanwhile, fixing things. You also
deleted old kernels and now wrongly think that is what fixed it.

> 
> 
> --------------------
> С уважением, Клочков Глеб
> 
> 
> 2014-03-21 14:31 GMT+04:00 Volker Armin Hemmann
> <volkerarmin@googlemail.com <mailto:volkerarmin@googlemail.com>>:
> 
>     Am 20.03.2014 11:24, schrieb Tom Wijsman:
>     > On Thu, 20 Mar 2014 11:39:58 +0400
>     > Gleb Klochkov <glebiuskv@gmail.com <mailto:glebiuskv@gmail.com>>
>     wrote:
>     >
>     >> Tom, thank you for your answer.
>     >>
>     >> $ dmesg >> http://bpaste.net/show/187533/
>     > There this can be seen:
>     >
>     >     [   18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307
>     >     [   18.074575] [drm] This can cause pipe underruns and display
>     >     issues.
>     >     [   18.074575] [drm] Please upgrade your BIOS to fix this.
>     >     [   18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling
>     back
>     >     to bit banging on pin 2
>     >
>     > Above your messages seem interesting; some expected value is wrong, it
>     > also times out on a bus and then goes to use a pin instead. Not sure
>     > how much of this is intended, but try to upgrade your BIOS as
>     suggested.
>     >
>     >> $ cat /proc/interrupts >> http://bpaste.net/show/187537/
>     > So, that would be this:
>     >
>     >     8: 63 0 0 0 IO-APIC-edge rtc0
>     >
>     > Hmm, nothing about it in the dmesg; also, 63 seems low (on my system,
>     > however, it's only 1 as I think my system uses something different).
>     >
>     > You can try a different timer using this kernel parameter:
>     >
>     >     clocksource=hpet
>     >
>     > Another note-worthy thing:
>     >
>     >     9: 699799454 0 0 0 IO-APIC-fasteoi acpi
>     >
>     > That there are ~700 million ACPI interrupts seems abnormally high;
>     > maybe the count is off by one, and 8 refers to 9? On my system, that's
>     > been running for a while by now, it's only at ~6000 (six thousand).
> 
>     uptime
>      11:29:37 up 49 days, 15:48, 16 users,  load average: 0,38, 0,31, 0,39
> 
>        8:          0          0          0         48   IO-APIC-edge    
>      rtc0
>        9:          0          0          0          0   IO-APIC-fasteoi
>       acpi
> 
> 
>     >
>     > Changing the ACPI related kernel parameters to try to get it supported
>     > differently might be one thing to do here; other than that, it
>     might be
>     > something going on with the hardware (try disconnecting things?)
>     so the
>     > BIOS upgrade is certainly of interest.
>     >
>     > Try the BIOS upgrade first, then play around with the parameters; if
>     > things don't work out, I suggest you look for support on one of the
>     > Linux kernel mailing lists (perhaps acpi-devel*). Good luck.
>     >
>     >  * https://lists.sourceforge.net/lists/listinfo/acpi-devel
>     >
>     imho he should first use a recent VANILLA kernel. 2.12 or 2.13.
> 
>     And build a config without all that unneeded garbage. Also increase the
>     dmesg buffer. Most interesting stuff is missing.
> 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com