https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c1 --- Comment #1 from Raymond Wooninck 2012-07-29 10:26:08 UTC --- I did some more testing today and I found out something quite interesting. I wanted to test the latest 3.5.0 kernels again from Kernel:HEAD and installed the desktop and vanilla ones (all 64bit). Before generating the initrd I removed the option nocrt=1 from /etc/modprobe.d/99-local.conf First I tested the kernel-desktop 3.5.0 version and put all 4 cores under 100% load. After 2 - 3 seconds the notebook issued the shutdown command. Validating the output of /proc/cpu/ibm/thermal, it indicated that the temperature reached was 101 degrees. I then booted the kernel-vanilla 3.5.0 version and put all 4 cores again under the same load (by doing exactly the same as before). The notebook kept on running and the fans were spinning blowing out hot air. Checking the output of /proc/cpu/ibm/thermal, it indicated that the temperature reached was around 62 degrees. The task completed successfully and the temperature got never above 65 degrees. What I noticed however is that all 4 cores (2.4Ghz) where running at 2.390Ghz. Checking the modules loaded it appeared that the acpi_cpufreq module was not loaded. This is a known bug which was resolved for openSUSE (see bnc#756085). I loaded manually the acpi_cpufreq module and executed the action again. This time I got the same behavior as with the desktop version. After a couple of seconds of load, the notebook issued a shutdown due to a critical temperature reached. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c Rafael Wysocki changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |767692 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c3 --- Comment #3 from Raymond Wooninck 2012-07-31 20:54:36 UTC --- Hi Rafael, Correct. I am not sure what happens but I see that each second the temperature of the CPU's rises with around 10 degrees. The nocrt=1 helps indeed to have the normal behavior. For me it is just strange to see that this only happens when the acpi_cpufreq module (together with the mperf module) is loaded. Without acpi_cpufreq (as happens when you run the vanilla kernel) the behavior is correct and the temperature does not go beyond 62/65 degrees under extreme load. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c4 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |tittiatcoke@gmail.com --- Comment #4 from Thomas Renninger 2012-07-31 22:55:13 UTC --- Can you try out whether this also happens when the acpi-cpufreq driver is loaded at runtime, please. Best you also use: cpupower monitor from the cpupower package. This would then be following test scenario(s): - boot system with acpi-cpufreq not loaded and try to get the machine down by: cpupower monitor >/tmp/c_p_state_measures.txt Hm, cpupower monitor needs some enhancements to better show results constantly. Anway, now load the acpi-cpufreq driver and if you know the machine probably will shutdown you could do something like: & while (( 1 )) ;do cpupower monitor -i 1 >>/tmp/c_p_state_measures_big.txt;done Is there something bogus if you look at C-/P- state usage (best post results)? Also try to boot, load acpi-cpufreq and unload it again. Do you still run into the problem? In other words: Is it enough to trigger the problem once acpi-cpufreq got loaded or does it actually has to be/stay loaded?

This is a known bug which was resolved for openSUSE (see bnc#756085) Oh dear, I need to double check whether this is not resolved for 12.2 yet.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c6 --- Comment #6 from Raymond Wooninck 2012-08-01 09:29:48 UTC --- Created an attachment (id=500677) --> (http://bugzilla.novell.com/attachment.cgi?id=500677) The output of cpupower monitor with the acpi_cpufreq loaded -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c8 Raymond Wooninck changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|tittiatcoke@gmail.com | --- Comment #8 from Raymond Wooninck 2012-08-01 09:34:40 UTC --- Hi Thomas, I have attached the three text files showing the output of the cpupower monitor command, while executing exactly the load for the cpu's. In all cases I am using the kernel-vanilla-3.5.0 from Kernel:HEAD. If I load the acpi_cpufreq module and then forcefully unload it again, the behavior of the CPU's return to normal. So it seems in order to get the bogus readings, the acpi_cpufreq module needs to stay loaded. I am far away from being knowledgeable on kernel matters, but it is strange to see that I get for the Nehalem and Idle states zeros when the cpu's are loaded and the acpi_cpufreq module is active. I do not see that behavior when the acpi_cpufreq module isn't loaded. Let me know if you need something more. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |tittiatcoke@gmail.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c11 --- Comment #11 from Raymond Wooninck 2012-08-01 11:00:23 UTC --- Created an attachment (id=500688) --> (http://bugzilla.novell.com/attachment.cgi?id=500688) Output of acpidump -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #500689|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

From acpidump -> you seem to have a passive cooling and a critical trip point. Please double check which value the passive one has (I guess it is too near at

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c14 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |tittiatcoke@gmail.com --- Comment #14 from Thomas Renninger 2012-08-01 12:39:27 UTC --- Attachment in comment #12 does not show much. Do you have an alias on grep? For me this command: /sys/devices/virtual/thermal> grep ".*" `find *` >/tmp/thermal_settings reads and stores the values from each file in /sys/devices/virtual/thermal. Rui may know another method how to look up thermal info easily? the critical one). Next test would be to heat the CPU above the passive, but not the critical trip point and monitor cpufreq behavior (is max frequency reduced immediately or at all?). You should be able to find out critical and passive trip points by examining this directory carefully: for x in /sys/devices/virtual/thermal/thermal_zone*/trip_point_*;do echo $x cat $ done -> or similar. It's really a nightmare to find out thermal settings... Then monitor temperature there and cpufreq: watch -n1 cat /sys/devices/virtual/thermal/thermal_zone*/temp /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq BTW: What graphics card and driver do you use? It might be as simple as using the binary nvidia/ATI driver with enhanced graphics power saving features to not run into this (on Windows and Linux). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c16 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |tittiatcoke@gmail.com --- Comment #16 from Thomas Renninger 2012-08-01 15:30:40 UTC --- Ok, thanks for the info. The question still is: Does Linux throttle immediately on a thermal event (if one is happening). You can increase acpi debug level by: echo 0xf >/sys/module/acpi/parameters/debug_level echo 0xffffffff >/sys/module/acpi/parameters/debug_layer If you exceed the passive trip point, is there a "notification" message or similar in syslog? Hope this enables notification logging... If yes, does cpufreq (best monitor with watch -n1 cat /sys../scaling_cur_freq as shown above) get lowered immediately? Or does it take another poll (could take about 10s). Then an old bug slipped in again. If things are immediately throttled, I'd suggest to close this one documented as a workaround is to modify the BIOS setting. May be a HW defect which is only triggered on Linux due to higher power consumption (e.g. of graphics card) or similar. If not -> this is the bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c18 --- Comment #18 from Raymond Wooninck 2012-08-01 19:13:36 UTC --- I have attached the part of the /var/log/messages file that shows the debugging output. As it can be seen, a notification is given now that it has passed the first passive trip point, but the critical temperature is reached only moments after so there is no time to react. I also had the watch command running and there I could only see that from one second to the next it jump from about 92 degrees to over 100 degrees. So my guess is that the current passive trip point setting of 95.5 degrees is much too high and doesn't give space to the kernel to react on the rising temperature and change the cpu throttling. The BIOS setting lowers this trip point to around 85 degrees and then it works fine. So the question here is if there is any way that I could change this setting of 95.5 degrees for the passive trip point to something lower. Or is there any utility that could do this for me ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c20 --- Comment #20 from Raymond Wooninck 2012-08-01 19:51:26 UTC --- It seems that now my system will constantly show this behavior, regardless of the kernel version I am using. My test program is Corel AftershotPro and I am exporting a number of RAW files to JPEG files. I have been using this program since January 2012 and didn't had issues before. Given that now even the kernel-desktop-3.1.0 from openSUSE 12.1 shows the same behavior, I am starting to wonder if this is a kernel issue or something else. Is the kernel itself responsible for polling the thermal info and reacting on this or is it utilizing upower for this ? I also put the hoover to work again and tried to clean the laptop from dust again. I have to admit that this made the laptop running for a few seconds more, but in the end I got the same issue again. It could also be a combination and that the fan control is not correct. That it should instruct the fan to run on maximum and not on Auto. But I am not sure which program is controlling the fan. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c22 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |tittiatcoke@gmail.com --- Comment #22 from Thomas Renninger 2012-08-01 21:23:48 UTC --- Yes, I have seen this behavior already with older thinkpads. You do even find the static, fixed value in the ACPI tables (I didn't look up the tables for this one, but I have done so for another model). It's probably hard to interpret the code why/when the static value is returned as temperature. But it is clearly a mechanism to get the platform emergency shut down and it really seem to have to do with overheating. -> I am not sure nocrt=1 is such a good workaround and would be careful with it.

I also put the hoover to work again and tried to clean the laptop from dust again. I have to admit that this made the laptop running for a few seconds more, but in the end I got the same issue again. You probably have to open the chassis. It's possible that the dust is stuck behind the small fins of the fan protection. I did it once for a ThinkPad where a cable contact to the fan was loose. You should google and read up some articles before you start. It was quite some fiddling, if you are lucky they changed the design of how the devices are set up and it's a bit easier with your model (pull up the keyboard?).

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c24 --- Comment #24 from Rui Zhang 2012-08-02 01:38:19 UTC --- (In reply to comment #23)

say "watch -n1 grep . /sys/class/thermal/*/* >> log" and burn the processor.

sorry, this command does not work. you just need to catch the thermal status every 1 second before shutting down, and attach the output here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c26 --- Comment #26 from Raymond Wooninck 2012-08-02 08:26:27 UTC --- (In reply to comment #23)

you can use thermal.psv=80 to override the passive trip point to 80C, but as the firmware may not generate thermal events for this new trip point, you need to use thermal.tzp= to set a polling frequency, (Note that this pulls all the time, no matter the temperature is high or not).

Good to know, but it seems that something similar is done when I change the thermal policy in the BIOS to react the same way as on battery. Guess this would be a more safer way.

re: The output of cpupower monitor without the acpi_cpufreq loaded why the processor is running at 1200 when it is busy? who changes the cpu frequency?

What I noticed is that the CPU is running at high speed just before it reaches a thermal trip point. As soon as that one is reached then the CPU seems to be throttled. As soon as this happens, the CPU frequency stays on that low speed until a reboot.

BTW, can you please attach the output of "grep . /sys/class/thermal/*/*" without acpi_cpufreq loaded? say "watch -n1 grep . /sys/class/thermal/*/* >> log" and burn the processor. I'd like to see how thermal works before shutting down.

There are a lot of files in that path. Any particular one that you are interested in or you just want to see the temperature reported by the thermal_zone ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c28 --- Comment #28 from Raymond Wooninck 2012-08-02 09:03:17 UTC --- Problems seems to be resolved. We opened the laptop, took a hoover and I guess that everything that wasn't screwed down disappeared in the hoover :-) Since then I see the standard behavior. Temperature rising, Kernel kicks in the fan, CPU starts throttling. Max temp reached is around 97 degrees and then things cool down again. Once temperature is below 90 degrees, then the CPU speed is increased again to the max and temperature goes up, etc, etc. This is however with the acpi_cpufreq kernel driver loaded. I will now reboot and try the same without the acpi_cpufreq module loaded. What I have seen so far is that without the cpufreq module, the CPU's are set down to the lower speed by the thermal driver, but the speed is never increased anymore. However this will be in the next comment. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c30 --- Comment #30 from Raymond Wooninck 2012-08-02 09:42:33 UTC --- Created an attachment (id=500843) --> (http://bugzilla.novell.com/attachment.cgi?id=500843) Thermal and Status output -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

We opened the laptop, took a hoover ... Since then I see the standard behavior ... So what we saw (machine shutdown, frequency throttled,...) is a perfectly running kernel picking up on BIOS notifications and reacting accordingly to

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c32 Thomas Renninger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #32 from Thomas Renninger 2012-08-02 11:51:27 UTC --- them, etc.. The confusing part was this:

Strangely enough the same task with an 3.3 kernel can easily survive and also under Windows I do not have any problems.

Anyway, I close this one invalid. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=773563 https://bugzilla.novell.com/show_bug.cgi?id=773563#c34 --- Comment #34 from Rui Zhang 2012-08-03 00:42:14 UTC --- (In reply to comment #30)

Created an attachment (id=500843) --> (http://bugzilla.novell.com/attachment.cgi?id=500843) [details] Thermal and Status output

this shows that thermal works correctly, it put the processors to a deeper cooling state when the temperature is 92C, and set it back to cooling state 0 when the temperature drops. But IMO, w/o acpi-cpufreq driver loaded, the processors enters T-state only to do the throttling, I'm still not clear who decreases the cpu frequency. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.