Created attachment 615721 [details] sensors command 1.Description of problem: My fedora starts with temperature of 56^C ,at the same time cpu fan continuously blows without stop all day long on my laptop!!!!; Usually the temperature ranks from 56^C to 70 ^C, the average temperature is 62^C,that's too high comparing with Windows 7's 48^C. sometimes the cpu temperature even goes up to 70+^C!!!! even though I use 'sudo pm-powersave true'; So I have a question? can fedora's power management be better for laptop? 2.Additional info: See my uploaded pics and docs.
Created attachment 615722 [details] powertop1
Created attachment 615723 [details] powertop2
Created attachment 615724 [details] powertop3
Created attachment 615725 [details] powertop4
Created attachment 615726 [details] win7's cpu temperature as comparison
Created attachment 615727 [details] laptop summary info.
I can not help applauding for redhat's efficiency; I hope redhat won't treat me like a ball , kicking me from here to there, lol; Don't hesitate to ask me for detailed info; Best regards
after setting intel's SpeedStep enabled in bios ,restart fedora 17, the temperature drop to 47`C-50`C again.
I have the same problem in the 3.6x series kernels. The problem doesn't exist in 3.5.5-2.fc17.i686.PAE on my t420 (4177CTO)
Created attachment 660881 [details] Script for testing i915 overheating on Lenovo T420 laptop This script dumps out module parameters and i915 info in a 1sec loop. If a suspend / resume is detected it dumps out the parameters again
Created attachment 660882 [details] Output from debugi915.sh with i915_enable_rc6=3 Kernel parameter i915.i915_enable_rc6=3 passed
Created attachment 660883 [details] Output from debugi915.sh with i915_enable_rc6=7 Kernel parameter i915.i915_enable_rc6=7 passed
Comments for debugi915.sh, i915testing-7.txt, i915testing-3.txt Script dumps out /sys/kernel/debug/dri/0/i915_drpc_info in a 1 sec loop. Normally (but not always) when the system boots it won't overheat. Generally (but not always) after a suspend / resume cycle it will overheat. I tried to capture as much information around the problem as I could. It seems that the problem is related to RC6, RC6+ and RC6++ - when the overheating problem is present, the "RC6 residency since boot" value is constant, the "RC6+ residency since boot" and "RC6++ residency since boot" values are 0. A suspend / resume cycle will cause the RC6 number to be reset. When the overheating problem is NOT present, the "RC6+ residency since boot" or "RC6++ residency since boot" will increment. RC6+ / RC6++ are dependent on whether or not the i915.i915_enable_rc6 kernel parameter passed is 3 or 7 respectively. Kernel 3.5.5-2.fc17 (i686 and x86_64) do NOT exhibit this problem. I'll grab similar logs from my script for those kernels if needed.
Perhaps its the same problem I was having on my thinkpad T420s. [with intel integrated graphics] For the past many weeks [perhaps with F16? and now] with F18 the laptop ran hot - and the fan was always running fast/noisy. The temp was usually above 90C usually 95C. 'sensors' says: (high = +86.0°C, crit = +100.0°C) And had messages of the following type in /var/log/messages: {{{ Jan 6 18:41:49 asterix kernel: [76104.662209] CPU0: Package power limit notification (total events = 2597) Jan 6 18:41:49 asterix kernel: [76104.662211] CPU1: Package power limit notification (total events = 2597) Jan 6 18:41:49 asterix kernel: [76104.662213] CPU2: Package power limit notification (total events = 2597) Jan 6 18:41:49 asterix kernel: [76104.662214] CPU3: Package power limit notification (total events = 2597) }}} I had assumed - perhaps the cpu/heatsink was loosening up. But then google found: https://bbs.archlinux.org/viewtopic.php?id=150743 https://bbs.archlinux.org/viewtopic.php?pid=1030190 As suggested - i added the following to /etc/modprobe.d/i915.conf and rebooted - and now the laptop is not overheating. 'sensors' shows much saner temperatures asterix:/home/balay>cat /etc/modprobe.d/i915.conf options i915 modeset=1 options i915 i915_enable_rc6=1 options i915 i915_enable_fbc=1 options i915 lvds_downclock=1 asterix:/home/balay> asterix:/home/balay>uname -a Linux asterix 3.7.2-201.fc18.x86_64 #1 SMP Fri Jan 11 22:16:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux asterix:/home/balay>sensors acpitz-virtual-0 Adapter: Virtual device temp1: +43.0°C (crit = +97.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 3984 RPM coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +45.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +45.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +39.0°C (high = +86.0°C, crit = +100.0°C) asterix:/home/balay>
I guess I spoke too soon. The temps went up high [to 95C this morning] - after overnight suspend resume. Reboot also didn't help. Oh well. [trying rawhide kernel now]
kernel-3.8 from "rawhide nodebug kernel repo" appears to have fixed the problem [without requiring the extra options to i915 module] Tried with both these kernels on F18 - in the 24 hours. kernel-3.8.0-0.rc3.git0.3.fc19.x86_64 kernel-3.8.0-0.rc3.git1.2.fc19.x86_64
I noticed this problem again this morning after overnight suspend/resume with rawhide-nodebug kernel. asterix:/home/balay>uptime 08:49:29 up 1 day, 22:01, 12 users, load average: 0.09, 0.12, 0.13 asterix:/home/balay>uname -a Linux asterix 3.8.0-0.rc4.git1.1.fc19.x86_64 #1 SMP Sat Jan 19 20:46:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux asterix:/home/balay>sensors acpitz-virtual-0 Adapter: Virtual device temp1: +91.0°C (crit = +97.0°C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +92.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +89.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +87.0°C (high = +86.0°C, crit = +100.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 3984 RPM asterix:/home/balay> [root@asterix ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq && cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 800000 2500000 So for some reason the cpu frequency scaling was not working - and the machine was overheating. I've suspended [for an hour]/resumed once since this issue turned up - now the machine appears to be fine.
I' trying out kernel-3.7.4-204.fc18.x86_64 - after noticing the changelog entry: "Add i915 bugfix from airlied" The machine behaved fine after rebooting for the whole day. But after suspend/resume it overheated. Retrying suspend/resume - it works fine. Same with subsequent suspend/resumes. [Its a hit & miss] I run the following script to detect if the machine is in bad state [if so try suspend/resume again]. If scaling_cur_freq is low [800000] and cpuinfo_cur_freq high [2500000] consistantly - then I know the machine is in bad state. [so try suspend/resume again] [root@asterix ~]# cat ./freqcheck.cmd #!/bin/bash echo -n "scaling_cur_freq 0: " && cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq echo -n "cpuinfo_cur_freq 0: " && cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq echo -n "scaling_cur_freq 1: " && cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq echo -n "cpuinfo_cur_freq 1: " && cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq grep MHz /proc/cpuinfo <<example good state>>>>> [root@asterix ~]# ./freqcheck.cmd scaling_cur_freq 0: 800000 cpuinfo_cur_freq 0: 800000 scaling_cur_freq 1: 800000 cpuinfo_cur_freq 1: 800000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 <<example bad state>>>>>>> [root@asterix ~]# ./freqcheck.cmd scaling_cur_freq 0: 800000 cpuinfo_cur_freq 0: 2500000 scaling_cur_freq 1: 800000 cpuinfo_cur_freq 1: 2500000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 I'll go back to rawhide kernel. It appears to get into th bad state less frequently
Look's like I observe the same problem with same symptoms on HP EliteBook 2560p and Fedora 18. Tried kernel-3.7.4-204.fc18.x86_64 - same results as described above.
An update - 3.8 kernel from rawhide-nodebug repo have bee good so far. I'm currently at kernel-3.8.0-2.fc19.x86_64 [rawhide is at 3.9-rc0 now - but I haven't tried these 3.9 kernels yet] The laptop mostly works fine. Once in a while it tends to go into overheating mode [and I can confirm with the above script that cpuinfo_cur_freq remains high]. When this happens - a suspend/resume gets it back to good state.
An update: 3.8 kernels have been better [than 3.7]. However they do occasionally go into the bad mode [with high temp] Today I tried 3.9 kernel [didn't check immediately after boot] but after suspend resume - I see overheating with other strange things. Reporting it as a different bugzilla item https://bugzilla.redhat.com/show_bug.cgi?id=923942
I tried latest in f18 kernel 3.8.3-201PAE on hp6730b laptop and problem still exists - high fan speed after resume. I try add i915 module options as described above but not working. home$sensors acpitz-virtual-0 Adapter: Virtual device temp1: +29.0 (crit = +256.0) temp2: +34.0 (crit = +110.0) temp3: +34.0 (crit = +105.0) temp4: +25.0 (crit = +110.0) temp5: +100.0 (crit = +110.0) coretemp-isa-0000 Adapter: ISA adapter Core 0: +28 ... Core 1: +28 .... freqcheck script before suspend: home$./freqcheck scaling_cur_freq 0 : 800000 cpuinfo_cur_freq 0 : 800000 scaling_cur_freq 0 : 800000 cpuinfo_cur_freq 0 : 800000 cpu MHz : 800.000 cpu MHz : 800.000 after resume: home$./freqcheck scaling_cur_freq 0 : 2401000 cpuinfo_cur_freq 0 : 2400000 scaling_cur_freq 0 : 2401000 cpuinfo_cur_freq 0 : 2400000 cpu MHz : 2401.000 cpu MHz : 800.000
Problem still exist in f18 on kernel 3.8.4-202
An update: 3.9 RC kernels [with the change in default driver from acpi-cpufreq to intel_pstate for sandybridge CPUs] still has this problem. And It appears to go into this bad state more often than the 3.8 kernel [I was with earlier] kernel-3.9.0-0.rc4.git0.2.fc20.x86_64
Something interesting with kernel-3.9.0-0.rc5.git0.3.fc20.x86_64 ref: http://www.phoronix.com/scan.php?page=news_item&px=MTI5Mzc <After fresh boot> [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 25 <now suspend/resume> [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 100 <try suspend/resume again> [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 100 [root@asterix ~]# grep MHz /proc/cpuinfo cpu MHz : 3025.000 cpu MHz : 3025.000 cpu MHz : 3175.000 cpu MHz : 3150.000 <Ok try to change it back to 25%> [root@asterix ~]# echo 25 > /sys/devices/system/cpu/intel_pstate/min_perf_pct [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 25 [root@asterix ~]# grep MHz /proc/cpuinfo cpu MHz : 3100.000 cpu MHz : 3100.000 cpu MHz : 3100.000 cpu MHz : 3150.000 [root@asterix ~]# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +91.0°C (crit = +97.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 4020 RPM coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +92.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +90.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +87.0°C (high = +86.0°C, crit = +100.0°C) <suspend/resume again> [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 100 < try changing both max & min to 25% > [root@asterix ~]# echo 25 > /sys/devices/system/cpu/intel_pstate/min_perf_pct [root@asterix ~]# echo 25 > /sys/devices/system/cpu/intel_pstate/max_perf_pct [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 25 [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 25 [root@asterix ~]# grep MHz /proc/cpuinfo cpu MHz : 3125.000 cpu MHz : 3050.000 cpu MHz : 3125.000 cpu MHz : 3025.000 [root@asterix ~]# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +96.0°C (crit = +97.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 4633 RPM coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +96.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +94.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +92.0°C (high = +86.0°C, crit = +100.0°C) < suspend/let-it-cool-down-for-a-couple-of-minutes/resume> [root@asterix ~]# sensors acpitz-virtual-0 Adapter: Virtual device temp1: +61.0°C (crit = +97.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 4010 RPM coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +63.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +63.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +58.0°C (high = +86.0°C, crit = +100.0°C) [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/min_perf_pct 100 [root@asterix ~]# cat /sys/devices/system/cpu/intel_pstate/max_perf_pct 100 [root@asterix ~]# grep MHz /proc/cpuinfo cpu MHz : 1550.000 cpu MHz : 2050.000 cpu MHz : 2000.000 cpu MHz : 1875.000 Now that the cpu frequencies are low - hopefully it won't overheat now :(
A followup to the pstate inconsistancy - I see the following in /var/log/messages <first boot> Apr 2 10:06:18 asterix kernel: [ 0.586152] Intel pstate controlling: cpu 0 Apr 2 10:06:18 asterix kernel: [ 0.586166] Intel pstate controlling: cpu 1 Apr 2 10:06:18 asterix kernel: [ 0.586178] Intel pstate controlling: cpu 2 Apr 2 10:06:18 asterix kernel: [ 0.586188] Intel pstate controlling: cpu 3 <suspend/resume> Apr 2 10:08:44 asterix kernel: [ 165.016862] Intel pstate controlling: cpu 1 Apr 2 10:08:44 asterix kernel: [ 165.030242] Intel pstate controlling: cpu 2 Apr 2 10:08:44 asterix kernel: [ 165.043657] Intel pstate controlling: cpu 3 <suspend/resume> Apr 2 10:09:09 asterix kernel: [ 180.418443] Intel pstate controlling: cpu 1 Apr 2 10:09:09 asterix kernel: [ 180.431852] Intel pstate controlling: cpu 2 Apr 2 10:09:09 asterix kernel: [ 180.445293] Intel pstate controlling: cpu 3 <suspend/resume> Apr 2 10:09:41 asterix kernel: [ 209.222251] Intel pstate controlling: cpu 1 Apr 2 10:09:41 asterix kernel: [ 209.236120] Intel pstate controlling: cpu 2 Apr 2 10:09:41 asterix kernel: [ 209.250304] Intel pstate controlling: cpu 3 So pstate can't get a handle on cpu-0 after suspend/resume [and consequently /sys/devices/system/cpu/intel_pstate/min_perf_pct always get set to 100%? Perhaps a intel_pstate bug [unrelated to overheating issue?]
update: 3.9.0-0.rc5.git3.2.fc20.x86_64 is doing better wrt intel_pstate and /sys/devices/system/cpu/intel_pstate/min_perf_pct min_perf_pct is now generally 25 after suspend/resume. However if I suspend when cpu is busy [with say 'make -j 4' compile] - min_perf_pct is at 100 after resume. Subsequent suspend/resumes keep it at 100. Perhaps once when the freq reduced sufficiently [not the low 800MHz - but perhaps arround 1.5GHz-ish] - suspend/resume pushed min_perf_pct to 25 When min_perf_pct is 100 - I'm also able to do the following - and this brings down the frequency quickly to around 800MHz. echo 25 > /sys/devices/system/cpu/intel_pstate/min_perf_pct Wrt overheating - It might have gone into that state once [noticed 3GHz when no load]. But I was doing a quick suspend/resume to check min_perf_pct - so didn't wait long enough to check if it was in overheating mode. [so the overheating issue might still exist - but isn't getting triggered as frequently as with previous 3.9 kernels];
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I still have this issue with F19 - with the latest kernel-3.9.8-300.fc19.x86_64
Let me change version to 19 to prevent this bugzilla from being autoclosed.
I have similar problem. If i start (or restart) PC i have no problem. But if i resume (from suspend) pc have high temperature. Frequency is high (+- 2,6GHz) /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq Min Perf also high (100, normal from reboot is 27)/sys/devices/system/cpu/intel_pstate/min_perf_pct Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
problem persists with kernel-3.11.0-0.rc1.git1.2.fc20.x86_64 aswell.
I've had temp issues on my T420 since I first got it (immediately loaded with F17) through now (F19 w/ 3.9.9), and have pretty much given up on resolving them. Outside of the typical i915/rc6 options I've never been able to keep it cool, even with /proc/acpi/ibm/fan permanently at 7 (max speed). I plan on going to the T440s as soon as it comes out shortly just because I'm tired of the overheating issue, hopefully I don't see it there as well.
T420 i7-2620M w/ discrete nvidia nvs 3100 (manually set in bios) 3.9.9-302.fc19.x86_64 w/ i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 /proc/acpi/ibm/fan level 7 idle temps: thinkpad-isa-0000 Adapter: ISA adapter fan1: 4460 RPM coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +70.0°C (high = +86.0°C, crit = +100.0°C) Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C) Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
(In reply to jro from comment #33) > I've had temp issues on my T420 since I first got it (immediately loaded > with F17) through now (F19 w/ 3.9.9), and have pretty much given up on > resolving them. I started with F16 on my T420s with kernel-3.1 - and I don't remember seeing this issue initially [perhaps there were other issues]. I keep thinking - I should perhaps try ubuntu 12.04 [with kernel-3.2] - and see if the problem exists there - but that's a big change - so not motivated enough to try. I think this overheating issue practically killed off my current battery :(
kernel-3.11.0-0.rc2.git3.2.fc20.x86_64 looks promising. I've had quiet a few suspend resumes for the past day - and this issue hasn't come up yet. will keep monitoring - and update again.
Perhaps the following is the fix... https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dcd2677ea912573d9ed4bcd629b0023b2d11505
(In reply to Satish Balay from comment #36) > kernel-3.11.0-0.rc2.git3.2.fc20.x86_64 looks promising. Where does the build come from? Koji lists kernel-3.11.0-0.rc2.git3.1.fc20 as the latest greatest at http://koji.fedoraproject.org/koji/packageinfo?packageID=8
(In reply to Jan Pazdziora from comment #38) > Where does the build come from? Koji lists kernel-3.11.0-0.rc2.git3.1.fc20 > as the latest greatest https://fedoraproject.org/wiki/RawhideKernelNodebug Or to get from koji - one would have to search on 'Tasks' tab [owner=jforbes state=all].
Update: so far I haven't seen this issue with 3.11 rc kernels . And I noticed the above fix is in 3.11.5 [but I haven't tried it yet.] I do see occasional overheating. Perhaps thats ok when the machine is fully loaded [compiles] - but last time I noticed it was during streaming video [when it shouldn't normally overheat]. Something else is still broken [hardware or software].. Aug 7 20:28:05 asterix kernel: [120824.581450] mce: [Hardware Error]: Machine check events logged Aug 7 20:28:05 asterix mcelog[446]: Hardware event. This is not a software error. Aug 7 20:28:05 asterix mcelog[446]: MCE 0 Aug 7 20:28:05 asterix mcelog[446]: CPU 1 THERMAL EVENT TSC 25ae0418f65 Aug 7 20:28:05 asterix mcelog[446]: TIME 1375925123 Wed Aug 7 20:25:23 2013 Aug 7 20:28:05 asterix mcelog[446]: Processor 1 heated above trip temperature. Throttling enabled. Aug 7 20:28:05 asterix mcelog[446]: Please check your system cooling. Performance will be impacted Aug 7 20:28:05 asterix mcelog[446]: STATUS 88030003 MCGSTATUS 0 Aug 7 20:28:05 asterix mcelog[446]: MCGCAP c07 APICID 1 SOCKETID 0 Aug 7 20:28:05 asterix mcelog[446]: CPUID Vendor Intel Family 6 Model 42 Aug 7 20:28:05 asterix mcelog[446]: Hardware event. This is not a software error. Aug 7 20:28:05 asterix mcelog[446]: MCE 1 Aug 7 20:28:05 asterix mcelog[446]: CPU 0 THERMAL EVENT TSC 25ae04273d1 Aug 7 20:28:05 asterix mcelog[446]: TIME 1375925123 Wed Aug 7 20:25:23 2013 Aug 7 20:28:05 asterix mcelog[446]: Processor 0 heated above trip temperature. Throttling enabled. Aug 7 20:28:05 asterix mcelog[446]: Please check your system cooling. Performance will be impacted Aug 7 20:28:05 asterix mcelog[446]: STATUS 88030003 MCGSTATUS 0 Aug 7 20:28:05 asterix mcelog[446]: MCGCAP c07 APICID 0 SOCKETID 0 Aug 7 20:28:05 asterix mcelog[446]: CPUID Vendor Intel Family 6 Model 42 Aug 7 20:28:05 asterix mcelog[446]: Hardware event. This is not a software error. Aug 7 20:28:05 asterix mcelog[446]: MCE 2 Aug 7 20:28:05 asterix mcelog[446]: CPU 1 THERMAL EVENT TSC 25ae065e961 Aug 7 20:28:05 asterix mcelog[446]: TIME 1375925123 Wed Aug 7 20:25:23 2013 Aug 7 20:28:05 asterix mcelog[446]: Processor 1 below trip temperature. Throttling disabled Aug 7 20:28:05 asterix mcelog[446]: STATUS 88040002 MCGSTATUS 0 Aug 7 20:28:05 asterix mcelog[446]: MCGCAP c07 APICID 1 SOCKETID 0 Aug 7 20:28:05 asterix mcelog[446]: CPUID Vendor Intel Family 6 Model 42 Aug 7 20:28:05 asterix mcelog[446]: Hardware event. This is not a software error. Aug 7 20:28:05 asterix mcelog[446]: MCE 3 Aug 7 20:28:05 asterix mcelog[446]: CPU 0 THERMAL EVENT TSC 25ae067eaed Aug 7 20:28:05 asterix mcelog[446]: TIME 1375925123 Wed Aug 7 20:25:23 2013 Aug 7 20:28:05 asterix mcelog[446]: Processor 0 below trip temperature. Throttling disabled Aug 7 20:28:05 asterix mcelog[446]: STATUS 88040002 MCGSTATUS 0 Aug 7 20:28:05 asterix mcelog[446]: MCGCAP c07 APICID 0 SOCKETID 0 Aug 7 20:28:05 asterix mcelog[446]: CPUID Vendor Intel Family 6 Model 42 Aug 7 20:30:23 asterix kernel: [120962.305768] CPU2: Package temperature above threshold, cpu clock throttled (total events = 32480) Aug 7 20:30:23 asterix kernel: [120962.305770] CPU3: Package temperature above threshold, cpu clock throttled (total events = 32472) Aug 7 20:30:23 asterix kernel: [120962.305772] CPU0: Package temperature above threshold, cpu clock throttled (total events = 32475) Aug 7 20:30:23 asterix kernel: [120962.305775] CPU1: Package temperature above threshold, cpu clock throttled (total events = 32485) Aug 7 20:30:23 asterix kernel: [120962.306775] CPU1: Package temperature/speed normal Aug 7 20:30:23 asterix kernel: [120962.306776] CPU0: Package temperature/speed normal Aug 7 20:30:23 asterix kernel: [120962.306777] CPU2: Package temperature/speed normal Aug 7 20:30:23 asterix kernel: [120962.306778] CPU3: Package temperature/speed normal A
Still reproducible for me on the following kernels: kernel-3.11.0-0.rc6.git4.1.fc20.x86_64 kernel-3.10.9-200.fc19.x86_64 kernel-3.9.6-301.fc19.x86_64 Occurs every time after resume on HP 620 (Celeron 900 @ 2.20GHz and Intel 4500MHD)
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The aforementioned new Kernel solves the overheating problem for me on my t420.