Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Kworker use >80% of CPU
Date: Thu, 03 Apr 2014 15:32:29
Message-Id: 533D7EE3.5080802@gmail.com
In Reply to: Re: [gentoo-user] Kworker use >80% of CPU by Gleb Klochkov
1 On 03/04/2014 17:20, Gleb Klochkov wrote:
2 > Hi everybody, and thank you all!
3 > Excuse me, I did not answer for a long time.
4 > The problem is fixed for now. I delete all old kernels initrd and configs.
5 > The only question now is: why just upgrade to new kernel don`t fix it.
6 > For new kernel it should use default config, shouldn`t it?
7
8
9 Please don't top post. It messes with people's mail apps.
10
11 The kernel is self-contained. You can have 1 or 100 kernels in /boot,
12 the only one that applies is the one you booted with. The other 99 have
13 exactly zero influence over the one that is running. The config settings
14 to kernel is built with are whatever you told it to use. If you don;t
15 run *config at all, then the default settings are used. If it builds and
16 runs, then it built and ran. The default config is nothing special, it's
17 just a config.
18
19 So that's not it, and it's not some magic influence.
20
21 Most likely you had stuff mixed up in /boot and the image you booted
22 from is not the one you thought you booted from. Or the initrd is out of
23 sync.
24
25 Something like that - it will be human error.
26
27 I'll say it again because it is important - there is no magic
28 interaction between kernel images and you can have as many as you want.
29
30
31 There's another possibility: some userspace app on your system was the
32 real problem and you updated it meanwhile, fixing things. You also
33 deleted old kernels and now wrongly think that is what fixed it.
34
35 >
36 >
37 > --------------------
38 > С уважением, Клочков Глеб
39 >
40 >
41 > 2014-03-21 14:31 GMT+04:00 Volker Armin Hemmann
42 > <volkerarmin@××××××××××.com <mailto:volkerarmin@××××××××××.com>>:
43 >
44 > Am 20.03.2014 11:24, schrieb Tom Wijsman:
45 > > On Thu, 20 Mar 2014 11:39:58 +0400
46 > > Gleb Klochkov <glebiuskv@×××××.com <mailto:glebiuskv@×××××.com>>
47 > wrote:
48 > >
49 > >> Tom, thank you for your answer.
50 > >>
51 > >> $ dmesg >> http://bpaste.net/show/187533/
52 > > There this can be seen:
53 > >
54 > > [ 18.074574] [drm] Wrong MCH_SSKPD value: 0x16040307
55 > > [ 18.074575] [drm] This can cause pipe underruns and display
56 > > issues.
57 > > [ 18.074575] [drm] Please upgrade your BIOS to fix this.
58 > > [ 18.148162] [drm] GMBUS [i915 gmbus vga] timed out, falling
59 > back
60 > > to bit banging on pin 2
61 > >
62 > > Above your messages seem interesting; some expected value is wrong, it
63 > > also times out on a bus and then goes to use a pin instead. Not sure
64 > > how much of this is intended, but try to upgrade your BIOS as
65 > suggested.
66 > >
67 > >> $ cat /proc/interrupts >> http://bpaste.net/show/187537/
68 > > So, that would be this:
69 > >
70 > > 8: 63 0 0 0 IO-APIC-edge rtc0
71 > >
72 > > Hmm, nothing about it in the dmesg; also, 63 seems low (on my system,
73 > > however, it's only 1 as I think my system uses something different).
74 > >
75 > > You can try a different timer using this kernel parameter:
76 > >
77 > > clocksource=hpet
78 > >
79 > > Another note-worthy thing:
80 > >
81 > > 9: 699799454 0 0 0 IO-APIC-fasteoi acpi
82 > >
83 > > That there are ~700 million ACPI interrupts seems abnormally high;
84 > > maybe the count is off by one, and 8 refers to 9? On my system, that's
85 > > been running for a while by now, it's only at ~6000 (six thousand).
86 >
87 > uptime
88 > 11:29:37 up 49 days, 15:48, 16 users, load average: 0,38, 0,31, 0,39
89 >
90 > 8: 0 0 0 48 IO-APIC-edge
91 > rtc0
92 > 9: 0 0 0 0 IO-APIC-fasteoi
93 > acpi
94 >
95 >
96 > >
97 > > Changing the ACPI related kernel parameters to try to get it supported
98 > > differently might be one thing to do here; other than that, it
99 > might be
100 > > something going on with the hardware (try disconnecting things?)
101 > so the
102 > > BIOS upgrade is certainly of interest.
103 > >
104 > > Try the BIOS upgrade first, then play around with the parameters; if
105 > > things don't work out, I suggest you look for support on one of the
106 > > Linux kernel mailing lists (perhaps acpi-devel*). Good luck.
107 > >
108 > > * https://lists.sourceforge.net/lists/listinfo/acpi-devel
109 > >
110 > imho he should first use a recent VANILLA kernel. 2.12 or 2.13.
111 >
112 > And build a config without all that unneeded garbage. Also increase the
113 > dmesg buffer. Most interesting stuff is missing.
114 >
115 >
116
117
118 --
119 Alan McKinnon
120 alan.mckinnon@×××××.com