tremendous CPU/GPU temperature increase since kernel 5.3 up to (at least) 5.5

The following is and excerpt from https://lore.kernel.org/lkml/c7b7e81b14380709c3d63033b0e67ee12b737b55.camel@scientia.net/ ... a bigger test series where I compare kernel 5.2 vs. 5.4 (each with intel_pstate=disable and without), each on Cinnamon and GNOME Classic... under different scenarios (idle system and several videos played back).

So I did some more systematic testing between the following:

kernel 5.2.17
kernel 5.4.6

each with

no intel_pstate parameter (which results in active/HWP)
intel_pstate=disable [0]

For each combination I've recorded:

average CPU usage for X.org and either cinnamon or gnome-shell (running in classic mode) as shown by top
average temperature of the Package id 0 as shown by sensor

during the following scenarios:

idle system (i.e. respective desktop environment running with some minimal set of applets (like clock, window list, or so), cron disabled, no(!) further CPU intensive processes (e.g. firefox) were running.

as well as:

playing a video in h264 (High) (avc1 / 0x31637661), yuv420p, 720x396
playing a video in h264 (High), yuv420p(tv, bt709, progressive), 1920x1080

with mpv, each in:

normal resolution (on a HiDPI display)
fullscreen
fullscreen using -vo=xv

In the two modes where -vo=xv wasn't given, mpv selected: VO: [gpu] … vaapi[nv12]

so these were with VAAPI acceleration.

Other versions/etc. were:

CPU: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
GPU: Intel(R) HD Graphics 620 (Kaby Lake GT2)
Display: 3840x2160
Debian sid (and no custom)
mpv 0.30.0 Copyright © 2000-2019 mpv/MPlayer/mplayer2 projects built on UNKNOWN ffmpeg library versions: libavutil 56.31.100 libavcodec 58.54.100 libavformat 58.29.100 libswscale 5.5.100 libavfilter 7.57.100 libswresample 3.5.100 ffmpeg version: 4.2.1-2+b1
Xorg 7.7
cinnamon 4.2.4, (always in hardware rendering mode)
gnome 3.34.2, (always in the GNOME Classic session mode)
notebook is a Fujitsu Lifebook U757
/etc/sysfs.conf has: devices/system/cpu/intel_pstate/no_turbo = 1

For the testing, the notebook was placed on a metal surface (which probably explains why the temperatures are a bit lower than what I've reported in previous mails).

After each measurement (which often caused high CPU temperatures) I let the CPU/system cool down for ~5 minutes until it reached the initially measured "idle temperature" again. Also for each measurement, I let the system in that state (e.g. being idle or playing a video) for several minutes.

I've made the "average" values manually, for the temperatures those should be quite accurate, for the CPU utilisation they should be regarded more as a guide, since there were often spikes in on or the other direction.

Of course, I took always the same 2 videos, and started them at the beginning for each measurement.

Legend: C = Cinnamon G = Gnome Shell, classic mode

idl = idle (i.e. just desktop environment running, not interaction or other intensive processes for several minutes) loV = low-res video (h264 (High) (avc1 / 0x31637661), yuv420p, 720x396) hiV = high-res video (h264 (High) yuv420p(tv, bt709, progressive), 1920x1080

no "fs" = no fullscreen fs = fullscreen

no "xv" = mpv used [gpu] … vaapi[nv12] xv = mpv used xv

CPU temperature / [Cinnamon|Gnome Shell CPU%] / X CPU%

		5.2+a-hwp	5.2+disable	5.4+a-hwp	5.4+dis
able	
C idl		48/ 5,0/ 1,0	48/ 3,0/ 1,0	59/ 4,0/ 1,0	56/
2,7/ 0,8
C loV		53/15,0/ 6,0	54/ 9,3/ 4,3	62/14,0/ 6,3	59/
9,0/ 4,3
C loV-fs	75/26,0/ 7,0	75/17,5/15,0	92/25,0/ 7,0	89/17,3
/ 5,0
C loV-fs-xv	72/28,0/ 8,6	71/15,3/ 5,5	92/27,0/ 8,7	91/15,5
/ 5,5
C hiV		63/25,0/12,0	61/15,0/ 8,3	63/24,0/12,2	66/14,5
/ 8,5
C hiV-fs       100/45,0/10,0	95/33,0/ 7,6   100/41,0/11,0	97/34,0
/ 8,0
C hiV-fs-xv    100/27,0/27,0	95/33,0/ 7,5	97/24,0/18,0	97/22,0
/17,0

G idl		46/ 1,5/ 1,5	44/ 1,3/ 0,9	50/ 1,3/ 0,8	49/
1,2/ 1,1
G loV		49/12,5/ 6,8	48/ 7,3/ 4,3	51/11,0/ 6,6	52/
7,4/ 4,2
G loV-fs	56/13,2/ 7,0	55/ 8,5/ 4,5	60/13,3/ 6,7	60/
8,3/ 4,3
G loV-fs-xv	54/12,2/ 8,6	54/ 6,6/ 5,3	58/12,0/ 8,1	57/
6,5/ 4,7
G hiV		53/24,0/12,5	54/13,7/ 7,5	55/23,5/12,5	55/14,7
/ 7,5
G hiV-fs	93/28,0/13,4	93/15,0/ 7,3	96/27,0/11,1	95/16,0
/ 8,0
G hiV-fs-xv	94/ 9,5/20,0	91/18,5/ 8,8	97/17,0/ 8,7	93/21,0
/ 9,0

Conclusions:

In most cases, not using intel_pstate, results in the same or noticeably lower temperature and CPU utilisation for both, Cinnamon and Gnome. The few ones where this isn't the case,... well for the CPU utilisation I've already said that the values may not be that rock solid... for temperature no idea...
Using xv instead of vaapi gives similar or better temperatures for both, Cinnamon and GNOME
Both, Cinnamon and GNOME run at considerably higher temperature when using 5.4 rather than 5.2,... for Cinnamon this is much more noticeable (it still is for GNOME)... E.g. 10°C more in absolute idle... and 15°C more when playing back the low res video in full screen. Maybe that's a reason why there haven't been much reports about this, when e.g. GNOME is not that much affected.
For the HiRes video, one doesn't seem that much difference between 5.2 and 5.4, but probably because the CPU gets throttled down after reaching 100°C the first time (which I could see especially under 5.4 in the kernel log).
Also with both 5.2/5.4 and with both Cinnamon/Gnome playing the high res video on the HiDPI screen seems to be killing it (always >90°C). Is this expected?
One can argue that Cinnamon might do a bit more in the background, thus resulting in the generally somewhat higher temp/CPU-utilisation even when idle... but since it's far more affected whenplaying back videos than gnome (even under 5.2)... I'd guess there's also some problem on the Cinnamon side.
But since it gets reproducibly worse from 5.2 to 5.4 (or 5.3), there's also something changed in the kernel which strongly affects it (and GNOME as well, just not that much)

...that is, at least on my hardware ;-)

Unfortunately all this is not limited to playing back videos...

on cinnamon, when I just
- constantly move the mouse (like in circles) on an empty desktop, or
- a window
- or scroll up/down in e.g. Thunderbirds mail list temperatures reach 69° C or more
having Firefox open, say around 10 windows, none of them playing any video or animated GIF, none of them running any scripts (thanks to noscript)... temperatures go to ~85°C on Cinnamon (not the case on GNOME, at least not that extreme).

So my suspicion would be something is wrong at the graphics stack and/or how it's used especially by Cinnamon.

Also (and I've tested the following only in Cinnamon), as previously noticed, sometimes, but not always:

CPU temperature stays very high for several minutes, even though I've already stopped e.g. video playback or mouse moving
maybe, but there's only little indication for this: putting the system into suspend2ram and waking it up, seemed to have cured the symptoms for "a while".... but this is very vague.

Any help or pointers on how to debug this further would be highly appreciated... obviously running a notebook at ~80° or not being able to upgrade the kernel is kind of a showstopper.

Attached are several logs which may be useful.

Thanks, Chris.

[0] suggestion to try this from https://github.com/linuxmint/cinnamon/issues/9085#issuecomment-570654676

marked this issue as a duplicate of #614 (closed)

closed

Hey @ickle .

Thanks for pointing me to the other bug. Are you sure it's the same thing? Especially I do not see the 100% utilisation mentioned in the other bug.

Also it doesn't really explain:

why Cinnamon is affected so much more than GNOME Shell.
why xv performs better than vaapi
why it performs still so bad in 5.2 (is the GPU just not powerful enough?)

Would you have any idea what one could do in order to find the bug that's possibly present in cinnamon an let it already run much hotter in 5.2?

Thanks, Chris.

You haven't reported measuring rc6, but that may be the difference of around 2W (depending on GPU) for an idle load. If you use the rapl mentioned in the other bug, i.e. something like perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-gpu/" -e "i915/rc6-residency/" sleep 60, you should be able to determine if this is the cause. It is what changed in v5.3 that has identical symptoms, so probably the same.

Cinnamon/GNOME Shell are vastly different rendering models, it's swings and roundabouts as to which one performs better under various measurements -- neither is perfect. Might be worth a bug to see if we misbehave under one or the other.

xv vs vaapi, no idea -- file a separate bug, and we'll dig into it :)

As for bad performance overall, be prepared to chase upstream (e.g. mesa-20, drm-tip) and we'll investigate what is impacting your system. Please do file it as a separate bug though, it's likely a different issue to xv/vaapi.

You haven't reported measuring rc6

Hehe cause I didn't even know what it was (well an still don't).

I took some measurements nevertheless (all on GNOME classic, all with intel_pstate being in active/HWP mode) with your above command:

On 5.2.17 with an idle system (temp was around 47°C):

40,76,Joules,power/energy-pkg/,59999745177,100,00,,
1,64,Joules,power/energy-gpu/,59999776880,100,00,,
58542521600,ns,i915/rc6-residency/,59999799885,100,00,,

On 5.2.17 while playing the high-res video from above in fullscreen using gpu+vaapi mode of mpv:

910,29,Joules,power/energy-pkg/,60000597941,100,00,,
674,18,Joules,power/energy-gpu/,60000610581,100,00,,
4992675840,ns,i915/rc6-residency/,60000626199,100,00,,

On 5.4.8 with an idle system (temp was around 53°C):

117,13,Joules,power/energy-pkg/,59999607726,100,00,,
31,76,Joules,power/energy-gpu/,59999639008,100,00,,
0,ns,i915/rc6-residency/,59999661796,100,00,,

On 5.4.8 while playing the high-res video from above in fullscreen using gpu+vaapi mode of mpv:

957,31,Joules,power/energy-pkg/,59999099552,100,00,,
720,61,Joules,power/energy-gpu/,59999082208,100,00,,
0,ns,i915/rc6-residency/,59999083407,100,00,,

So if I understand correctly, it should look like the other bug and my CPU never enters RC6 and thus pulls more Joules and runs higher..., right?

And I assume this would also explain my observation that in some cases it was "cured" for a while, when suspending/resuming the system?

What it does not explain is, why Cinnamon is so much more affected by this, unless of course it's in the other issue, which generally seem to cause Cinnamon run on much higher temperatures.

I'll file tickets for the other issues.

Yes. It does appear to be the case. The GPU never idled, and never entered its powersaving mode (RC6). That in turn prevents the whole GPU from entering runtime suspend, and prevents the CPU from entering deep package C-states. So one little bug in the GPU has quite dramatic impact on the overall powersaving landscape.

However, when sufficiently idle (such as being forced to idle on suspend), it would enter powersaving.

mentioned in issue #955 (closed)

mentioned in issue #956

@ickle I've opened #955 (closed) and #956 ... should I also file one for the observation that the system runs hotter with intel_pstate than it does without (or where would such bug belong to?)?

Oh and as for #614 (closed)... is there any final fix on the horizon which still closes the security hole and which will be sent to the stable trees?

Thanks, Chris.

I prepared patches for v5.4, v5.3..., v4.19.... /o\

Where are these, so I could suggest Debian kernel maintainers to cherry pick them.

They are linked in #614 (closed), or in the hands of the people responsible.

Is there any expectation on when these patches will end up in -stable? It seems to be no included in the most recent -stable releases and I couldn't find them on linux-stable mailing list either.

mentioned in issue #614 (closed)

Could someone with the appropriate rights un-mark this as duplicate from #614 (closed) (otherwise I'd have to file a separate issue which just clutters up the issue tracker).

Apparently it's not a duplicate,.... just retried the whole thing with 5.5.13 (which should contain the alleged fix for #614 (closed)), and basically everything is still fully broken.

While the GPU seems to enter RC6 states now:

# perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-gpu/" -e "i915/rc6-residency/" sleep 60
161,99,Joules,power/energy-pkg/,60001047882,100,00,,
31,42,Joules,power/energy-gpu/,60001049257,100,00,,
55883685200,ns,i915/rc6-residency/,60001059714,100,00,,

... temperatures are still generally higher (just take the values from my test series above and replace kernel 5.4 with 5.5)... and when playing videos they go just nuts (~100°C)... just moving around windows, makes the temps go to beyond 70°C.

So must be some other serious regression from >5.2.

Cheers, Chris.

Several people reported in #614 (closed) that the fix isn't really 100% and that even though RC6 is being reached most of the time, it's not as good as it used to be. So to completely rule out that these issues are duplicate, it'd be better to revert the security fix that broke it ("drm/i915/gen8+: Add RC6 CTX corruption WA") and test that.

One way to disable that fix is this:

diff --git drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_drv.h
index 1a46a32da051..aaca9274493c 100644
--- drivers/gpu/drm/i915/i915_drv.h
+++ drivers/gpu/drm/i915/i915_drv.h
@@ -2120,7 +2120,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_BROKEN_CS_TLB(dev_priv)    (IS_I830(dev_priv) || IS_I845G(dev_priv))
 
 #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv)  \
-       (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9))
+       (false && (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9)))
 
 /* WaRsDisableCoarsePowerGating:skl,cnl */
 #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \

(this should apply to 5.3 and 5.4, I haven't seen the newer ones yes)

Does it also apply to 5.5? Also it wouldn't be a proper solution, since it would open up again a security hole?

Last but not least, have you completely read my tests, especially:

that >5.2 is also much hotter for non-GPU-related stuff (and using intel_pstate is typically much hotter than not using it)
playing back video even sucked at 5.2 without the fix (though this may of course be another issue)

I can try to compile a kernel without the above fix, but that will probably take quite a while.

I have no idea whether it applies or not, and I think I said that quite clearly. It's up to you to check and possibly adapt it. I never said it's any kind of solution. I'm just saying that to completely rule out that your issue is the same as #614 (closed), you should test with a revert of the cause of #614 (closed) instead of its fix, which some people say is not perfect.

I have not completely read all your comments, I just skimmed through them, sorry. 5.2 being much hotter for non-GPU-related stuff can still be explained by #614 (closed), because #614 (closed) makes the CPU package hotter regardless of what you're doing (actually the less you're doing the more of a difference it makes, as it's mainly affecting idle power).

Also, you might be interested in this comment of mine: #614 (comment 372847) It makes it possible to just rebuild a patched version of the i915 module, which is considerably faster than building an entire kernel, and spares you the trouble of configuring it and installing it.

Finally, let it be noted that I'm just an ordinary user, like you, frustrated by the bugs I encounter and doing my best to assist the developers to fix them. So I'm just dumping here what I know to help you diagnose the issue, but I really can't do more than that: give you a few hints that may or may not help you come closer to a solution.

reopened

Idle (~63°C a):

# perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-gpu/" -e "i915/rc6-residency/" sleep 60
114,46,Joules,power/energy-pkg/,59999706962,100,00,,
5,03,Joules,power/energy-gpu/,59999716594,100,00,,
59067457547,ns,i915/rc6-residency/,59999723535,100,00,,

playing HD video fullscreen (100°C):

# perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-gpu/" -e "i915/rc6-residency/" sleep 60
1022,46,Joules,power/energy-pkg/,59999897262,100,00,,
679,88,Joules,power/energy-gpu/,59999895772,100,00,,
17550080,ns,i915/rc6-residency/,59999903626,100,00,,

Comparing these with the 5.2 measurements from above (#953 (comment 381198)) there seems to be still a much higher energy usage. Idle temperature on 5.5 is ~15°C higher than on 5.2.

Also, while it does go a bit into RC6 while playing back fullscreen video, it's much less than it did with 5.2.

When switching between workspaces I get temperatures between 70 and 80°C .. with video playback it goes generally to 100°C.

Any ideas how to find the cause for this regression?

I've also gotten this just now:

Apr 03 17:25:02 heisenberg kernel: ------------[ cut here ]------------
Apr 03 17:25:02 heisenberg kernel: WARN_ON(!queue_delayed_work(system_unbound_wq, &power_domains->async_put_work, msecs_to_jiffies(100)))
Apr 03 17:25:02 heisenberg kernel: WARNING: CPU: 0 PID: 10081 at drivers/gpu/drm/i915/display/intel_display_power.c:2038 queue_async_put_domains_work+0x6a/0x70 [i915]
Apr 03 17:25:02 heisenberg kernel: Modules linked in: uas(E) ctr(E) ccm(E) fuse(E) cpufreq_userspace(E) cpufreq_powersave(E) cpufreq_conservative(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_hdmi(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_soc_skl(E) coretemp(E) snd_soc_hdac_hda(E) snd_hda_ext_core(E) snd_soc_sst_ipc(E) kvm_intel(E) snd_soc_sst_dsp(E) snd_soc_acpi_intel_match(E) btusb(E) snd_soc_acpi(E) btrtl(E) snd_hda_codec_realtek(E) kvm(E) btbcm(E) snd_soc_core(E) snd_hda_codec_generic(E) btintel(E) irqbypass(E) ledtrig_audio(E) snd_compress(E) iwlmvm(E) iTCO_wdt(E) bluetooth(E) crct10dif_pclmul(E) snd_hda_intel(E) hid_generic(E) snd_intel_dspcfg(E) i2c_designware_platform(E) iTCO_vendor_support(E) mac80211(E) mei_wdt(E) crc32_pclmul(E) i2c_designware_core(E) watchdog(E) libarc4(E) snd_usb_audio(E) uvcvideo(E) snd_hda_codec(E) cdc_mbim(E) snd_usbmidi_lib(E) intel_wmi_thunderbolt(E) videobuf2_vmalloc(E) ghash_clmulni_intel(E) snd_rawmidi(E) snd_hda_core(E) videobuf2_memops(E) drbg(E)
Apr 03 17:25:02 heisenberg kernel:  snd_seq_device(E) sdhci_pci(E) videobuf2_v4l2(E) snd_hwdep(E) intel_cstate(E) iwlwifi(E) cdc_wdm(E) cqhci(E) intel_uncore(E) cdc_ncm(E) snd_pcm(E) videobuf2_common(E) intel_rapl_perf(E) sdhci(E) snd_timer(E) pcspkr(E) usbhid(E) videodev(E) ansi_cprng(E) mei_me(E) usbnet(E) intel_lpss_pci(E) joydev(E) i2c_i801(E) cfg80211(E) snd(E) ecdh_generic(E) mmc_core(E) ecc(E) sg(E) intel_lpss(E) mii(E) mc(E) hid(E) soundcore(E) idma64(E) mei(E) rfkill(E) crc16(E) mfd_core(E) wmi(E) button(E) battery(E) tpm_crb(E) tpm_tis(E) tpm_tis_core(E) tpm(E) fujitsu_laptop(E) rng_core(E) sparse_keymap(E) acpi_pad(E) ac(E) xt_tcpudp(E) ip6t_REJECT(E) nf_reject_ipv6(E) nft_counter(E) xt_comment(E) ipt_REJECT(E) binfmt_misc(E) nf_reject_ipv4(E) xt_multiport(E) xt_policy(E) xt_state(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nft_compat(E) nf_tables(E) nfnetlink(E) loop(E) parport_pc(E) ppdev(E) lp(E) parport(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) dm_crypt(E)
Apr 03 17:25:02 heisenberg kernel:  dm_mod(E) raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) async_tx(E) raid1(E) raid0(E) multipath(E) linear(E) md_mod(E) btrfs(E) blake2b_generic(E) libcrc32c(E) crc32c_generic(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) usb_storage(E) sd_mod(E) crc32c_intel(E) aesni_intel(E) glue_helper(E) xhci_pci(E) crypto_simd(E) cryptd(E) evdev(E) xhci_hcd(E) i915(E) ahci(E) psmouse(E) libahci(E) serio_raw(E) i2c_algo_bit(E) libata(E) e1000e(E) drm_kms_helper(E) ptp(E) pps_core(E) scsi_mod(E) usbcore(E) drm(E) usb_common(E) video(E)
Apr 03 17:25:02 heisenberg kernel: CPU: 0 PID: 10081 Comm: kworker/0:3 Tainted: G            E     5.5.0-1-amd64 #1 Debian 5.5.13-2
Apr 03 17:25:02 heisenberg kernel: Hardware name: FUJITSU LIFEBOOK U757/FJNB2A5, BIOS Version 1.21 03/19/2018
Apr 03 17:25:02 heisenberg kernel: Workqueue: events __intel_wakeref_put_work [i915]
Apr 03 17:25:02 heisenberg kernel: RIP: 0010:queue_async_put_domains_work+0x6a/0x70 [i915]
Apr 03 17:25:02 heisenberg kernel: Code: 48 c7 c6 58 63 54 c0 48 c7 c7 9f 0d 56 c0 e8 1f 05 20 e3 0f 0b eb bf 48 c7 c6 88 63 54 c0 48 c7 c7 9f 0d 56 c0 e8 08 05 20 e3 <0f> 0b 5b 5d c3 90 0f 1f 44 00 00 8b 46 08 85 c0 7e 05 e9 0f e7 ff
Apr 03 17:25:02 heisenberg kernel: RSP: 0018:ffffa7570373fe08 EFLAGS: 00010286
Apr 03 17:25:02 heisenberg kernel: RAX: 0000000000000000 RBX: ffff98be72e37080 RCX: 0000000000000000
Apr 03 17:25:02 heisenberg kernel: RDX: 0000000000000066 RSI: ffffffffa4c3d3e6 RDI: 0000000000000246
Apr 03 17:25:02 heisenberg kernel: RBP: 00000000ffffffff R08: 0000077540758a7a R09: 0000000000000066
Apr 03 17:25:02 heisenberg kernel: R10: ffffffffa4c3d760 R11: 00000000a4c3d37f R12: 000000000000003b
Apr 03 17:25:02 heisenberg kernel: R13: 00000000ffffffff R14: ffff98be72e37718 R15: ffff98be72e37090
Apr 03 17:25:02 heisenberg kernel: FS:  0000000000000000(0000) GS:ffff98be7dc00000(0000) knlGS:0000000000000000
Apr 03 17:25:02 heisenberg kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 03 17:25:02 heisenberg kernel: CR2: 00007f4119c60000 CR3: 000000019425c003 CR4: 00000000003606f0
Apr 03 17:25:02 heisenberg kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 03 17:25:02 heisenberg kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Apr 03 17:25:02 heisenberg kernel: Call Trace:
Apr 03 17:25:02 heisenberg kernel:  __intel_display_power_put_async+0x9f/0xd0 [i915]
Apr 03 17:25:02 heisenberg kernel:  __gt_park+0x74/0xa0 [i915]
Apr 03 17:25:02 heisenberg kernel:  ____intel_wakeref_put_last+0x1b/0x50 [i915]
Apr 03 17:25:02 heisenberg kernel:  process_one_work+0x1b4/0x370
Apr 03 17:25:02 heisenberg kernel:  worker_thread+0x50/0x3c0
Apr 03 17:25:02 heisenberg kernel:  kthread+0xf9/0x130
Apr 03 17:25:02 heisenberg kernel:  ? process_one_work+0x370/0x370
Apr 03 17:25:02 heisenberg kernel:  ? kthread_park+0x90/0x90
Apr 03 17:25:02 heisenberg kernel:  ret_from_fork+0x35/0x40
Apr 03 17:25:02 heisenberg kernel: ---[ end trace 702a0bb38de085f5 ]---
Apr 03 17:32:50 heisenberg kernel: ------------[ cut here ]------------
Apr 03 17:32:50 heisenberg kernel: WARN_ON(!queue_delayed_work(system_unbound_wq, &power_domains->async_put_work, msecs_to_jiffies(100)))
Apr 03 17:32:50 heisenberg kernel: WARNING: CPU: 0 PID: 10081 at drivers/gpu/drm/i915/display/intel_display_power.c:2038 queue_async_put_domains_work+0x6a/0x70 [i915]
Apr 03 17:32:50 heisenberg kernel: Modules linked in: uas(E) ctr(E) ccm(E) fuse(E) cpufreq_userspace(E) cpufreq_powersave(E) cpufreq_conservative(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_hdmi(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_soc_skl(E) coretemp(E) snd_soc_hdac_hda(E) snd_hda_ext_core(E) snd_soc_sst_ipc(E) kvm_intel(E) snd_soc_sst_dsp(E) snd_soc_acpi_intel_match(E) btusb(E) snd_soc_acpi(E) btrtl(E) snd_hda_codec_realtek(E) kvm(E) btbcm(E) snd_soc_core(E) snd_hda_codec_generic(E) btintel(E) irqbypass(E) ledtrig_audio(E) snd_compress(E) iwlmvm(E) iTCO_wdt(E) bluetooth(E) crct10dif_pclmul(E) snd_hda_intel(E) hid_generic(E) snd_intel_dspcfg(E) i2c_designware_platform(E) iTCO_vendor_support(E) mac80211(E) mei_wdt(E) crc32_pclmul(E) i2c_designware_core(E) watchdog(E) libarc4(E) snd_usb_audio(E) uvcvideo(E) snd_hda_codec(E) cdc_mbim(E) snd_usbmidi_lib(E) intel_wmi_thunderbolt(E) videobuf2_vmalloc(E) ghash_clmulni_intel(E) snd_rawmidi(E) snd_hda_core(E) videobuf2_memops(E) drbg(E)
Apr 03 17:32:50 heisenberg kernel:  snd_seq_device(E) sdhci_pci(E) videobuf2_v4l2(E) snd_hwdep(E) intel_cstate(E) iwlwifi(E) cdc_wdm(E) cqhci(E) intel_uncore(E) cdc_ncm(E) snd_pcm(E) videobuf2_common(E) intel_rapl_perf(E) sdhci(E) snd_timer(E) pcspkr(E) usbhid(E) videodev(E) ansi_cprng(E) mei_me(E) usbnet(E) intel_lpss_pci(E) joydev(E) i2c_i801(E) cfg80211(E) snd(E) ecdh_generic(E) mmc_core(E) ecc(E) sg(E) intel_lpss(E) mii(E) mc(E) hid(E) soundcore(E) idma64(E) mei(E) rfkill(E) crc16(E) mfd_core(E) wmi(E) button(E) battery(E) tpm_crb(E) tpm_tis(E) tpm_tis_core(E) tpm(E) fujitsu_laptop(E) rng_core(E) sparse_keymap(E) acpi_pad(E) ac(E) xt_tcpudp(E) ip6t_REJECT(E) nf_reject_ipv6(E) nft_counter(E) xt_comment(E) ipt_REJECT(E) binfmt_misc(E) nf_reject_ipv4(E) xt_multiport(E) xt_policy(E) xt_state(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nft_compat(E) nf_tables(E) nfnetlink(E) loop(E) parport_pc(E) ppdev(E) lp(E) parport(E) sunrpc(E) ip_tables(E) x_tables(E) autofs4(E) dm_crypt(E)
Apr 03 17:32:50 heisenberg kernel:  dm_mod(E) raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) async_tx(E) raid1(E) raid0(E) multipath(E) linear(E) md_mod(E) btrfs(E) blake2b_generic(E) libcrc32c(E) crc32c_generic(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) usb_storage(E) sd_mod(E) crc32c_intel(E) aesni_intel(E) glue_helper(E) xhci_pci(E) crypto_simd(E) cryptd(E) evdev(E) xhci_hcd(E) i915(E) ahci(E) psmouse(E) libahci(E) serio_raw(E) i2c_algo_bit(E) libata(E) e1000e(E) drm_kms_helper(E) ptp(E) pps_core(E) scsi_mod(E) usbcore(E) drm(E) usb_common(E) video(E)
Apr 03 17:32:50 heisenberg kernel: CPU: 0 PID: 10081 Comm: kworker/0:3 Tainted: G        W   E     5.5.0-1-amd64 #1 Debian 5.5.13-2
Apr 03 17:32:50 heisenberg kernel: Hardware name: FUJITSU LIFEBOOK U757/FJNB2A5, BIOS Version 1.21 03/19/2018
Apr 03 17:32:50 heisenberg kernel: Workqueue: events __intel_wakeref_put_work [i915]
Apr 03 17:32:50 heisenberg kernel: RIP: 0010:queue_async_put_domains_work+0x6a/0x70 [i915]
Apr 03 17:32:50 heisenberg kernel: Code: 48 c7 c6 58 63 54 c0 48 c7 c7 9f 0d 56 c0 e8 1f 05 20 e3 0f 0b eb bf 48 c7 c6 88 63 54 c0 48 c7 c7 9f 0d 56 c0 e8 08 05 20 e3 <0f> 0b 5b 5d c3 90 0f 1f 44 00 00 8b 46 08 85 c0 7e 05 e9 0f e7 ff
Apr 03 17:32:50 heisenberg kernel: RSP: 0018:ffffa7570373fe08 EFLAGS: 00010286
Apr 03 17:32:50 heisenberg kernel: RAX: 0000000000000000 RBX: ffff98be72e37080 RCX: 0000000000000000
Apr 03 17:32:50 heisenberg kernel: RDX: 0000000000000066 RSI: ffffffffa4c3d3e6 RDI: 0000000000000246
Apr 03 17:32:50 heisenberg kernel: RBP: 00000000ffffffff R08: 000007e20f724055 R09: 0000000000000066
Apr 03 17:32:50 heisenberg kernel: R10: ffffffffa4c3d760 R11: 00000000a4c3d37f R12: 000000000000003b
Apr 03 17:32:50 heisenberg kernel: R13: 00000000ffffffff R14: ffff98be72e37718 R15: ffff98be72e37090
Apr 03 17:32:50 heisenberg kernel: FS:  0000000000000000(0000) GS:ffff98be7dc00000(0000) knlGS:0000000000000000
Apr 03 17:32:50 heisenberg kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 03 17:32:50 heisenberg kernel: CR2: 00007f4119bfb000 CR3: 00000008389cc005 CR4: 00000000003606f0
Apr 03 17:32:50 heisenberg kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 03 17:32:50 heisenberg kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Apr 03 17:32:50 heisenberg kernel: Call Trace:
Apr 03 17:32:50 heisenberg kernel:  __intel_display_power_put_async+0x9f/0xd0 [i915]
Apr 03 17:32:50 heisenberg kernel:  __gt_park+0x74/0xa0 [i915]
Apr 03 17:32:50 heisenberg kernel:  ____intel_wakeref_put_last+0x1b/0x50 [i915]
Apr 03 17:32:50 heisenberg kernel:  process_one_work+0x1b4/0x370
Apr 03 17:32:50 heisenberg kernel:  worker_thread+0x50/0x3c0
Apr 03 17:32:50 heisenberg kernel:  kthread+0xf9/0x130
Apr 03 17:32:50 heisenberg kernel:  ? process_one_work+0x370/0x370
Apr 03 17:32:50 heisenberg kernel:  ? kthread_park+0x90/0x90
Apr 03 17:32:50 heisenberg kernel:  ret_from_fork+0x35/0x40
Apr 03 17:32:50 heisenberg kernel: ---[ end trace 702a0bb38de085f6 ]---

But I have no idea whether it's really anyhow related to my extreme CPU/GPU overheatin problem... possibly not as it's been the first time I've seen it, while the CPU/GPU plays being a little sun for months.

Cheers, Chris.

changed title from tremendous CPU/GPU temperature increase since kernel 5.3 to tremendous CPU/GPU temperature increase since kernel 5.3 up to (at least) 5.5

added Community label

tremendous CPU/GPU temperature increase since kernel 5.3 up to (at least) 5.5

Child items ...

Activity

Admin message

Admin message

tremendous CPU/GPU temperature increase since kernel 5.3 up to (at least) 5.5

Activity