Bug #1290110 “Fan stops after resume from suspend leading to ove...” : Bugs : linux package : Ubuntu

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2014-03-08:

#25

My fans are acting strangely since 3.13 upgrade.

Behaviour on 3.12:

Fans running pretty much all the time on 30%, temperatures 30-40 C.

Behaviour on 3.13:

Fans are idle until temperatures rise to 84 C (this is hot!), then ramp up to 75% (high noise) for a few seconds until temperatures drop to 72 C. Then they idle again.

This seems pretty dangerous, because the threshold of 84 degrees is just too high. I'd be fine with 60.

Laptop: macbook air 2013
OS: Archlinux

Revision history for this message

In Linux Kernel Bug Tracker #71711, linux (linux-linux-kernel-bugs) wrote on 2014-03-08:

#26

Seen with other systems as well.

Additional information: https://bugs.archlinux.org/task/39005

Revision history for this message

In Linux Kernel Bug Tracker #71711, linux (linux-linux-kernel-bugs) wrote on 2014-03-09:

#27

Download full text (4.3 KiB)

e-mail exchange on the subject.

On 2014-03-08 16:59, Guenter Roeck wrote:
> On 03/08/2014 03:08 AM, Jean Delvare wrote:
>> On Fri, 7 Mar 2014 14:52:30 -0800, Guenter Roeck wrote:
>>> On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:
>>>> Hi, and thanks for the quick response!
>>>> No special fancy "fan control policy". 'fancontrol' isn't up or
>>>> running.
>>>> Vanilla kernels 3.11.* and 3.12.* had been working on here
>>>> without
>>>> any extra work.
>>>> --
>>>> # sensors
>>>> acpitz-virtual-0
>>>> Adapter: Virtual device
>>>> temp1: +71.0°C (crit = +256.0°C)
>>>> temp2: +69.0°C (crit = +110.0°C)
>>>> temp3: +52.0°C (crit = +105.0°C)
>>>> temp4: +25.0°C (crit = +110.0°C)
>>>> temp5: +58.0°C (crit = +110.0°C)
>>>>
>>>> coretemp-isa-0000
>>>> Adapter: ISA adapter
>>>> Core 0: +62.0°C (high = +105.0°C, crit = +105.0°C)
>>>> Core 1: +60.0°C (high = +105.0°C, crit = +105.0°C)
>>>> --
>>>> My notebook (HP/Compaq 6730b) does not have a seperate fan
>>>> sensor.
>>>> This is with 3.12.13 with my normal workload.
>>>>
>>>> Please, trust my above mentionned values of 94 °C vs. 74°C as I
>>>> don't like to boot 3.13.6 anymore, to avoid harm to the
>>>> notebook's
>>>> casing.
>>>
>>> Understood. Unfortunately, we'll need to get information
>>> from the new kernel to be able to track down the problem.
>>
>> Indeed. Not only the run-time temperatures, but also the high
>> and crit
>> limits.
>>
>>>> But I'd do to test any improvement-patch.
>>>
>>> So far I have no idea what is going on. I don't see anything
>>> in the
>>> drivers providing above data that would explain the behavior,
>>> but I might be missing something.
>>
>> Looks like a regression in the acpi subsystem or in power
>> management,
>> not hwmon. Hwmon is merely reporting the temperatures, it's not
>> responsible for the actual temperatures.
>>
>
> I would agree. I don't think we have enough information to be sure,
> though. There might be some unintended interaction or interference.
>
> gpu is a good hint ... for example, look at commit b9ed919f1c8
> (drm/nouveau/drm/pm: remove everything except the hwmon interfaces
> to THERM). nouveau does export pwm and fan control information,
> so any change in that code may have unintended side effects.
> Similar, I don't know how ec39f64bba (drm/radeon/dpm: Convert to
> use devm_hwmon_register_with_groups) could have the observed impact,
> as it is purely passive, but I prefer to be rather safe than sorry.
>
> This problem has now been submitted into bugzilla as
> https://bugzilla.kernel.org/show_bug.cgi?id=71711.
>
> Guenter
>

Sorry, for beeing late, had to search for/accumulate much info for you...
I hope, you like me to put it into one answer to you all CCing you.

My GFX is a GM45 Intel (mobile), shared memory, running the opensource Mesa drivers/extensions.
kernel-module: i915

According to the output of 'cpupower': I have
CPUidle driver: acpi_idle
CPUidle governor: menu

CPUfreq:
driver: acpi-cpufreq
available cpufreq governors: ondemand, performance
-
And "ondemand" is running.
--

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +41.0°C (crit = ...

e-mail exchange on the subject.

On 2014-03-08 16:59, Guenter Roeck wrote:
> On 03/08/2014 03:08 AM, Jean Delvare wrote:
>> On Fri, 7 Mar 2014 14:52:30 -0800, Guenter Roeck wrote:
>>> On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:
>>>> Hi, and thanks for the quick response!
>>>> No special fancy "fan control policy". 'fancontrol' isn't up or
>>>> running.
>>>> Vanilla kernels 3.11.* and 3.12.* had been working on here
>>>> without
>>>> any extra work.
>>>> -- 
>>>> # sensors
>>>> acpitz-virtual-0
>>>> Adapter: Virtual device
>>>> temp1:        +71.0°C  (crit = +256.0°C)
>>>> temp2:        +69.0°C  (crit = +110.0°C)
>>>> temp3:        +52.0°C  (crit = +105.0°C)
>>>> temp4:        +25.0°C  (crit = +110.0°C)
>>>> temp5:        +58.0°C  (crit = +110.0°C)
>>>>
>>>> coretemp-isa-0000
>>>> Adapter: ISA adapter
>>>> Core 0:       +62.0°C  (high = +105.0°C, crit = +105.0°C)
>>>> Core 1:       +60.0°C  (high = +105.0°C, crit = +105.0°C)
>>>> -- 
>>>> My notebook (HP/Compaq 6730b) does not have a seperate fan
>>>> sensor.
>>>> This is with 3.12.13 with my normal workload.
>>>>
>>>> Please, trust my above mentionned values of 94 °C vs. 74°C as I
>>>> don't like to boot 3.13.6 anymore, to avoid harm to the
>>>> notebook's
>>>> casing.
>>>
>>> Understood. Unfortunately, we'll need to get information
>>> from the new kernel to be able to track down the problem.
>>
>> Indeed. Not only the run-time temperatures, but also the high
>> and crit
>> limits.
>>
>>>> But I'd do to test any improvement-patch.
>>>
>>> So far I have no idea what is going on. I don't see anything
>>> in the
>>> drivers providing above data that would explain the behavior,
>>> but I might be missing something.
>>
>> Looks like a regression in the acpi subsystem or in power
>> management,
>> not hwmon. Hwmon is merely reporting the temperatures, it's not
>> responsible for the actual temperatures.
>>
>
> I would agree. I don't think we have enough information to be sure,
> though. There might be some unintended interaction or interference.
>
> gpu is a good hint ... for example, look at commit b9ed919f1c8
> (drm/nouveau/drm/pm: remove everything except the hwmon interfaces
> to THERM). nouveau does export pwm and fan control information,
> so any change in that code may have unintended side effects.
> Similar, I don't know how ec39f64bba (drm/radeon/dpm: Convert to
> use devm_hwmon_register_with_groups) could have the observed impact,
> as it is purely passive, but I prefer to be rather safe than sorry.
>
> This problem has now been submitted into bugzilla as
> https://bugzilla.kernel.org/show_bug.cgi?id=71711.
>
> Guenter
>

Sorry, for beeing late, had to search for/accumulate much info for you...
I hope, you like me to put it into one answer to you all CCing you.

My GFX is a GM45 Intel (mobile), shared memory, running the opensource Mesa drivers/extensions.
kernel-module: i915

According to the output of 'cpupower': I have
CPUidle driver: acpi_idle
CPUidle governor: menu

CPUfreq:
  driver: acpi-cpufreq
  available cpufreq governors: ondemand, performance
-
And "ondemand" is running.
--

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +41.0°C  (crit = +256.0°C)
temp2:        +92.0°C  (crit = +110.0°C)
temp3:        +71.0°C  (crit = +105.0°C)
temp4:        +26.5°C  (crit = +110.0°C)
temp5:        +25.0°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +86.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +84.0°C  (high = +105.0°C, crit = +105.0°C)

FROM a critical "smelly" situation today, kernel-compilation, fan @100%.
--

Additional findings:

Identification from bootup ACPI initialisation vs. sensors:
temp1 = DTSZ
temp2 = CPUZ --> triggering Cooling in 3.12.13 if > 74°C
temp3 = SKNZ
temp4 = BATZ "Battery Zone" always calm ~ +6°C of ambient T
temp5 = FDTZ --- in 3.12.13 a representation of the cooling-fan (25 - 45 - 58 - max?)
Core 0 & Core 1 are the internal CPU T sensors.

With the 3.13.x (.5+) kernels the first gatherered cooling settings from bootup do stay forever. Means, rebooting a hot system will get a FDTZ @45°C+ and won't make any problems, as it does cool enough (even for kernel compiling on here). If it gets 25°C @bootup the system goes into emergency cooling somewhen. Same is with a suspend/resume.

Kernel 3.12.13 adjusts the cooling on it's own, but appropriately.

Thank you all for your engagement, best regards,
Manuel Krause.

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-03-09:

#1

/sys/class/thermal after normal boot, fan works Edit (4.3 KiB, text/plain)
AlsaInfo.txt Edit (31.7 KiB, text/plain; charset="utf-8")
BootDmesg.txt Edit (74.6 KiB, text/plain; charset="utf-8")
CRDA.txt Edit (257 bytes, text/plain; charset="utf-8")
Dependencies.txt Edit (3.0 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (249 bytes, text/plain; charset="utf-8")
Lspci.txt Edit (14.9 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (637 bytes, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (316 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (2.0 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (3.2 KiB, text/plain; charset="utf-8")
PulseList.txt Edit (21.6 KiB, text/plain; charset="utf-8")
RfKill.txt Edit (237 bytes, text/plain; charset="utf-8")
UdevDb.txt Edit (155.0 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (347.4 KiB, text/plain; charset="utf-8")
WifiSyslog.txt Edit (899.9 KiB, text/plain; charset="utf-8")

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-03-09:

#2

/sys/class/thermal after resume, fan doesn't work Edit (4.3 KiB, text/plain)

summary:

Fan stops after resume from suspend leading to overheating; requires
- reboot to fix
+ reboot to fix [HP Probook 4710s]

Revision history for this message

Brad Figg (brad-figg) wrote on 2014-03-09: Status changed to Confirmed

#3

This change was made by a bot.

Changed in linux (Ubuntu):
status:	New → Confirmed

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-03-11:

#28

Download full text (6.2 KiB)

# Based on the shown email in Comment 2 Rafael J Wysocki asked me on 2014-03-09 # 18:58:
> This almost certainly is an ACPI regression, but I'm not sure whether
> thermal management or CPU power management is broken on your system.
>
> Can you compare the contents of /sys/class/thermal/ from working and
> not working kernels, please?
>
> Rafael
>
# which I answered the following way (I hope it'll be complete on here):

Hi again,
unfortunately you didn't specify how deeply I should dig into /sys/class/thermal. So you get the lines from # BOF # to # EOF # below. I hope they're readable without more comments.

The most remarkable changes, in my eyes, had happened within "thermal_zone1".

Best regards,
Manuel Krause

# BOF #
Following ones are all from /sys/class/thermal/ which are links to -> ../../devices/virtual/thermal/

I've listed the directories in sections of cooling_devices and thermal_zones separately for each bad/good kernel. For Emailing purposes only. You can merge them into a spreadsheet for your evaluation on your own. I've left out reporting some subdirs and subdir's values that _really_ didn't seem to need attention.

Also, I've had collected the #sensors output for each readout, having reproduced nearly the same workload, represented by the "Fan speed" (thermal_zone4==FDTZ).

And I've done my very best to not produce typos or c&p errors.

3.13.5 -- 20140309 -- 20:52 -- bad
=============================
dir |-
/type /cur_state /max_state
cooling_device0 Processor 0 10
cooling_device1 Processor 0 10
cooling_device2 Fan 0 1
cooling_device3 Fan 1 1
cooling_device4 Fan 0 1
cooling_device5 Fan 0 1
cooling_device6 Fan 0 1
cooling_device7 LCD 0 24

3.12.13 -- 20140310 -- 00:26 -- good
==============================
dir |-
/type /cur_state /max_state
cooling_device0 Processor 0 10
cooling_device1 Processor 0 10
cooling_device2 Fan 0 1
cooling_device3 Fan 1 1
cooling_device4 Fan 1 1
cooling_device5 Fan 1 1
cooling_device6 Fan 1 1
cooling_device7 LCD 0 24

3.13.5 -- 20140309 -- 20:52 -- bad
=============================
dir |-
              /passive /temp |- /cdev?_ /trip_ /trip_
                                      trip_ point_ point_
                                      point ?_temp ?_type
thermal_zone0 0 68000 ?=0 n.a. 256000 critical
thermal_zone1 n.a. 70000 |-
                                ?=0 6 110000 critical
                                ?=1 5 107000 passive
                                ?=2 4 90000 active
                                ?=3 3 75000 active
                                ?=4 2 55000 active
                                ?=5 1 45000 active
                                ?=6 1 30000 active
thermal_zone2 n.a. 54000 |-
  ...

# Based on the shown email in Comment 2 Rafael J Wysocki asked me on 2014-03-09 # 18:58:
> This almost certainly is an ACPI regression, but I'm not sure whether
> thermal management or CPU power management is broken on your system.
>
> Can you compare the contents of /sys/class/thermal/ from working and
> not working kernels, please?
>
> Rafael
>
# which I answered the following way (I hope it'll be complete on here):

Hi again,
unfortunately you didn't specify how deeply I should dig into /sys/class/thermal. So you get the lines from # BOF # to # EOF # below. I hope they're readable without more comments.

The most remarkable changes, in my eyes, had happened within "thermal_zone1".

Best regards,
Manuel Krause

# BOF #
Following ones are all from /sys/class/thermal/ which are links to -> ../../devices/virtual/thermal/

I've listed the directories in sections of cooling_devices and thermal_zones separately for each bad/good kernel. For Emailing purposes only. You can merge them into a spreadsheet for your evaluation on your own. I've left out reporting some subdirs and subdir's values that _really_ didn't seem to need attention.

Also, I've had collected the #sensors output for each readout, having reproduced nearly the same workload, represented by the "Fan speed" (thermal_zone4==FDTZ).

And I've done my very best to not produce typos or c&p errors.

3.13.5 -- 20140309 -- 20:52 -- bad
=============================
dir             |-
                 /type       /cur_state  /max_state
cooling_device0  Processor    0          10
cooling_device1  Processor    0          10
cooling_device2  Fan          0           1
cooling_device3  Fan          1           1
cooling_device4  Fan          0           1
cooling_device5  Fan          0           1
cooling_device6  Fan          0           1
cooling_device7  LCD          0          24

3.12.13 -- 20140310 -- 00:26 -- good
==============================
dir             |-
                 /type       /cur_state  /max_state
cooling_device0  Processor    0          10
cooling_device1  Processor    0          10
cooling_device2  Fan          0           1
cooling_device3  Fan          1           1
cooling_device4  Fan          1           1
cooling_device5  Fan          1           1
cooling_device6  Fan          1           1
cooling_device7  LCD          0          24

3.13.5 -- 20140309 -- 20:52 -- bad
=============================
dir          |-
              /passive /temp  |-     /cdev?_  /trip_   /trip_
                                      trip_    point_   point_
                                      point    ?_temp   ?_type
thermal_zone0  0        68000   ?=0    n.a.   256000   critical
thermal_zone1   n.a.    70000 |-
                                ?=0   6       110000   critical
                                ?=1   5       107000   passive
                                ?=2   4        90000   active
                                ?=3   3        75000   active
                                ?=4   2        55000   active
                                ?=5   1        45000   active
                                ?=6   1        30000   active
thermal_zone2   n.a.    54000 |-
                                ?=0   1       105000   critical
                                ?=1   1        95000   passive
thermal_zone3   n.a.    25800 |-
                                ?=0   1       110000   critical
                                ?=1   1        60000   passive
thermal_zone4  0        58000   ?=0    n.a.   110000   critical

3.12.13 -- 20140310 -- 00:26 -- good
==============================
dir          |-
              /passive /temp  |-     /cdev?_  /trip_   /trip_
                                      trip_    point_   point_
                                      point    ?_temp   ?_type
thermal_zone0  0        50000   ?=0    n.a.   256000   critical
thermal_zone1   n.a.    70000 |-
                                ?=0   1       110000   critical
                                ?=1   1       107000   passive
                                ?=2   2        90000   active
                                ?=3   3        67000   active
                                ?=4   4        55000   active
                                ?=5   5        45000   active
                                ?=6   6        30000   active
thermal_zone2   n.a.    53000 |-
                                ?=0   1       105000   critical
                                ?=1   1        95000   passive
thermal_zone3   n.a.    25600 |-
                                ?=0   1       110000   critical
                                ?=1   1        60000   passive
thermal_zone4  0        58000   ?=0    n.a.   110000   critical

---
Legend here:
       /type  is always  acpitz
       /mode             enabled
       /policy           step_wise

- from kernel ACPI initialisation: thermal_zone0==DTSZ,
         thermal_zone1==CPUZ, thermal_zone2==SKNZ,
         thermal_zone3==BATZ, thermal_zone4==FDTZ
      - n.a. means      file or value is not available
___
Legend in general:
             /power/control          is always  auto
             /power/runtime_status              unsupported
             /uevent                            ''==empty

----------------------------------------------------------------

3.13.5 -- 20140309 -- 20:52 -- bad
=============================
# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +68.0°C  (crit = +256.0°C)
temp2:        +70.0°C  (crit = +110.0°C)
temp3:        +54.0°C  (crit = +105.0°C)
temp4:        +25.8°C  (crit = +110.0°C)
temp5:        +58.0°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +66.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +63.0°C  (high = +105.0°C, crit = +105.0°C)

3.12.13 -- 20140310 -- 00:26 -- good
==============================
# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +50.0°C  (crit = +256.0°C)
temp2:        +70.0°C  (crit = +110.0°C)
temp3:        +53.0°C  (crit = +105.0°C)
temp4:        +25.6°C  (crit = +110.0°C)
temp5:        +58.0°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +65.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +61.0°C  (high = +105.0°C, crit = +105.0°C)

# EOF #

Revision history for this message

Joseph Salisbury (jsalisbury) wrote on 2014-03-11: Re: Fan stops after resume from suspend leading to overheating; requires reboot to fix [HP Probook 4710s]

#4

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.14 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc6-trusty/

Changed in linux (Ubuntu):
importance:	Undecided → Medium
status:	Confirmed → Incomplete

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-03-11:

#29

Download full text (4.6 KiB)

# also posted to linux-kernel && linux-pm
# my findings from tonight:

Hi, and thank you for your attention ^^

at the bottom of this email you'd get the actual values for the new 3.12.14 kernel for two different levels of usage and ambient temperature.
You'd read, in kernel 3.12.14 the /cdev?_trip_point enumeration has changed to the way of 3.13.? and also one /trip_point_?_temp did. But 3.12.14 is working as well as 3.12.13. (So my first eyecatcher didn't lead to useful things.)
I'm not capaple of finding or understanding the related code, but, please, let me present an idea of what MAY be going on:

In 3.12.13+, on my system, the effective cooling fan speed seems to be an accumulation, maybe bitwise, of cooling_device[2-6]/cur_state, that each get activated (=1) by a certain other temperature value or level; each of the cooling_device[2-6]/cur_state stays @1 as long as their ref. temp. does not undershoot. For my system this ref. temp. would most likely be triggered by temp2 == thermal_zone1/temp [CPUZ].

In 3.13.? there seems to get only one of cooling_device[2-6]/cur_state be set to 1, the others left and/or rewritten with 0. And the fan speed algorithm then accumulates only one 1 without seeing the [_LEVEL_] number of cooling_device[2-6]... or re-requesting the related trigger temperature.

I hope this leads you developers nearer to a conclusion on how to fix it,
best regards, Manuel Krause

_____________________________
3.12.14 -- 20140311 -- 19:07 -- changed, not broken -- normal use
=============================
/sys/class/thermal/* which
are links to -> ../../devices/virtual/thermal/*

dir |-
                 /type /cur_state /max_state Maybe
                                                      trigger
                                                      /PWM
...
cooling_device2 Fan 0 1 not yet
                                                      observed
cooling_device3 Fan 0 1 FDTZ==58°C
cooling_device4 Fan 1 1 FDTZ==45°C
cooling_device5 Fan 1 1 FDTZ==34°C
cooling_device6 Fan 1 1 FDTZ==25°C
...

dir |-
              /passive /temp |- /cdev?_ /trip_ /trip_
                                      trip_ point_ point_
                                      point ?_temp ?_type
...
thermal_zone1 n.a. 73000 |- (CPUZ)
                                ?=0 6 110000 critical
                                ?=1 5 107000 passive
                                ?=2 4 90000 active
                                ?=3 3 75000 active
                                ?=4 2 55000 active
                                ?=5 1 45000 active
                                ?=6 1 30000 active
...
thermal_zone4 n.a. 45000 ?=0 n.a. 110000 critical (FDTZ)
...

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +46.0°C (crit = +256.0°C)
temp2: +73.0°C (crit = +110.0°C)
temp3: +57.0°C (crit = +105.0°C)
temp4: +26.3°C (crit = +110.0°C)
temp5: ...

# also posted to linux-kernel && linux-pm
# my findings from tonight:

Hi, and thank you for your attention ^^

at the bottom of this email you'd get the actual values for the new 3.12.14 kernel for two different levels of usage and ambient temperature.
You'd read, in kernel 3.12.14 the /cdev?_trip_point enumeration has changed to the way of 3.13.? and also one /trip_point_?_temp did. But 3.12.14 is working as well as 3.12.13. (So my first eyecatcher didn't lead to useful things.)
I'm not capaple of finding or understanding the related code, but, please, let me present an idea of what MAY be going on:

In 3.12.13+, on my system, the effective cooling fan speed seems to be an accumulation, maybe bitwise, of cooling_device[2-6]/cur_state, that each get activated (=1) by a certain other temperature value or level; each of the cooling_device[2-6]/cur_state stays @1 as long as their ref. temp. does not undershoot. For my system this ref. temp.  would most likely be triggered by temp2 == thermal_zone1/temp [CPUZ].

In 3.13.? there seems to get only one of cooling_device[2-6]/cur_state be set to 1, the others left and/or rewritten with 0. And the fan speed algorithm then accumulates only one 1 without seeing the [_LEVEL_] number of cooling_device[2-6]... or re-requesting the related trigger temperature.

I hope this leads you developers nearer to a conclusion on how to fix it,
best regards, Manuel Krause

_____________________________
3.12.14 -- 20140311 -- 19:07 -- changed, not broken -- normal use
=============================
/sys/class/thermal/*  which
are links to -> ../../devices/virtual/thermal/*

dir             |-
                 /type       /cur_state  /max_state  Maybe
                                                      trigger
                                                      /PWM
...
cooling_device2  Fan          0           1          not yet
                                                      observed
cooling_device3  Fan          0           1          FDTZ==58°C
cooling_device4  Fan          1           1          FDTZ==45°C
cooling_device5  Fan          1           1          FDTZ==34°C
cooling_device6  Fan          1           1          FDTZ==25°C
...

dir          |-
              /passive /temp  |-     /cdev?_  /trip_   /trip_
                                      trip_    point_   point_
                                      point    ?_temp   ?_type
...
thermal_zone1   n.a.    73000 |- (CPUZ)
                                ?=0   6       110000   critical
                                ?=1   5       107000   passive
                                ?=2   4        90000   active
                                ?=3   3        75000   active
                                ?=4   2        55000   active
                                ?=5   1        45000   active
                                ?=6   1        30000   active
...
thermal_zone4   n.a.    45000   ?=0    n.a.   110000   critical (FDTZ)
...

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +46.0°C  (crit = +256.0°C)
temp2:        +73.0°C  (crit = +110.0°C)
temp3:        +57.0°C  (crit = +105.0°C)
temp4:        +26.3°C  (crit = +110.0°C)
temp5:        +45.0°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +68.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +66.0°C  (high = +105.0°C, crit = +105.0°C)

_____________________________
3.12.14 -- 20140311 -- 21:09 -- changed, not broken -- idle state
=============================

dir             |-
                 /type       /cur_state  /max_state  Maybe
                                                      trigger
                                                      /PWM
...
cooling_device2  Fan          0           1          not yet
                                                      observed
cooling_device3  Fan          0           1          FDTZ==58°C
cooling_device4  Fan          0           1          FDTZ==45°C
cooling_device5  Fan          0           1          FDTZ==34°C
cooling_device6  Fan          1           1          FDTZ==25°C
...

dir          |-
              /passive /temp
thermal_zone1   n.a.    46000 ... (CPUZ)
...
thermal_zone4   n.a.    25000 ... (FDTZ)
...

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +50.0°C  (crit = +256.0°C)
temp2:        +46.0°C  (crit = +110.0°C)
temp3:        +44.0°C  (crit = +105.0°C)
temp4:        +25.7°C  (crit = +110.0°C)
temp5:        +25.0°C  (crit = +110.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +41.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:       +41.0°C  (high = +105.0°C, crit = +105.0°C)
_____________________________

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-03-12:

#5

Hi,

I've tested the latest mainline kernel (v3.16-rc6-trusty) and the bug is still present. Also it seems that the fan speed does not change relative to temperature any more after OS startup.

tags:	added: kernel-bug-exists-upstream
Changed in linux (Ubuntu):
status:	Incomplete → Confirmed

Revision history for this message

Joseph Salisbury (jsalisbury) wrote on 2014-03-18:

#6

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
status:	Confirmed → Triaged

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-03-20:

#30

[SNIP]

Long time no reply from you... Have I overseen a unwritten convention? Or were my charts that unusable for your analysis/work?

Two days ago, I tried the 3.14.0-rc7-vanilla. And the problem persists. "Strange / dangerous fan policy..."

Since kernel 3.13.6 I've managed to 'fix' the potential overheating problem by manually issuing a:
"echo 1 > /sys/class/thermal/cooling_device3/cur_state" *)
_before_ obviously critical temperatures occur. Remind: This particular setting may only work for my system! ...and keeps working for 3.14-rc.

In the following I'd like to present you a modified output of my /sys/class/thermal, that I've written a script for (for my system), that shows the results in the way of linux/Documentation/thermal/sysfs-api.txt, point 3:
{I've uploded the files to pastebin, to not swamp you and the lists with so many lines of logs.}

For the last good kernel -- 3.12.14 -- in-use:
http://pastebin.com/HL1PNcda
For my first bad kernel revision 3.13 -- at critical temp:
http://pastebin.com/98hgf1a9
For the last bad kernel -- 3.14.0-rc7 -- at critical temp:
http://pastebin.com/MuTwTnjD
For the last bad kernel -- 3.14.0-rc7 -- after issuing the
*) command:
http://pastebin.com/2peda54z

Please, have a look at them! And maybe, give me hints on how I can help you to further debug this issue, as my manual method works but it's annoying.

And, PLEASE CC: ME, as I'm not on the lists. Or lead this Email-thread to someone in charge.

Thank you for your work && best regards,
Manuel Krause

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-03-24:

#7

Thank you. I will report the bug upstream.

I have done a bit of investigation on which cooling devices correspond to different fan speeds. IMO the cooling device to trip point mappings are wrong (do not change fan speed linearly with accordance to temperature/trip points).
And I've also found that thermal zone 5 temperature corresponds exactly to the processor fan speed. This should definitely be reported as fan speed, not temperature.

Should I also detail my findings here, or post them to the kernel mailing list?

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-03-31:

#31

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

I've tried the tmon tool, now, too. Nice eyecandy and for monitoring!

I've tried to revert all "thermal" related patches from 3.12.14->3.13.7 from 3.13.7. But they don't seem to matter. (Even if I apply the vice-versa patch to 3.12.15.)

So "thermal" is out?

For the failing kernels: Not any reached trip point (active) triggers ONE fan action!

Next would be ACPI, to be investigated,

THX for this audience,
Manuel Krause

Revision history for this message

In Linux Kernel Bug Tracker #71711, the.ant (the.ant-linux-kernel-bugs) wrote on 2014-04-02:

#32

I'm not sure if this is related to this bug but since Kernel 3.13 my fan speed is far to high and noisy as soon as the system is booting up ... I'm using Fedora 20. With Kernel 3.12.X everything was fine instead and fan speed was on a acceptable level ...

[ant@fedorant ~]$ sensors
nouveau-pci-0100
Adapter: PCI adapter
fan1: 6693 RPM
temp1: +69.0°C (high = +95.0°C, hyst = +3.0°C)
(crit = +105.0°C, hyst = +5.0°C)
(emerg = +135.0°C, hyst = +5.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +52.0°C (high = +83.0°C, crit = +99.0°C)
Core 1: +50.0°C (high = +83.0°C, crit = +99.0°C)
Core 2: +52.0°C (high = +83.0°C, crit = +99.0°C)
Core 3: +50.0°C (high = +83.0°C, crit = +99.0°C)

it8720-isa-0a10
Adapter: ISA adapter
in0: +0.86 V (min = +0.00 V, max = +4.08 V) ALARM
in1: +3.04 V (min = +0.00 V, max = +4.08 V) ALARM
in2: +3.33 V (min = +0.00 V, max = +4.08 V) ALARM
+5V: +3.04 V (min = +0.00 V, max = +4.08 V) ALARM
in4: +2.94 V (min = +0.00 V, max = +4.08 V) ALARM
in5: +2.16 V (min = +0.00 V, max = +4.08 V) ALARM
in6: +2.16 V (min = +0.00 V, max = +4.08 V) ALARM
5VSB: +2.96 V (min = +0.00 V, max = +4.08 V) ALARM
Vbat: +2.99 V
fan1: 838 RPM (min = 0 RPM)
fan2: 949 RPM (min = 0 RPM)
temp1: +127.0°C (low = -1.0°C, high = +127.0°C) ALARM sensor = thermal diode
temp2: +22.0°C (low = -1.0°C, high = +127.0°C) ALARM sensor = thermistor
temp3: -47.0°C (low = -1.0°C, high = +127.0°C) sensor = Intel PECI
cpu0_vid: +0.000 V
intrusion0: ALARM

Any ideas?

Revision history for this message

In Linux Kernel Bug Tracker #71711, linux (linux-linux-kernel-bugs) wrote on 2014-04-02:

#33

On 04/02/2014 01:39 AM, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=71711
>
> --- Comment #7 from Roman Spirgi <email address hidden> ---
> I'm not sure if this is related to this bug but since Kernel 3.13 my fan
> speed
> is far to high and noisy as soon as the system is booting up ... I'm using
> Fedora 20. With Kernel 3.12.X everything was fine instead and fan speed was
> on
> a acceptable level ...
>
> [ant@fedorant ~]$ sensors
> nouveau-pci-0100
> Adapter: PCI adapter
> fan1: 6693 RPM
> temp1: +69.0°C (high = +95.0°C, hyst = +3.0°C)
> (crit = +105.0°C, hyst = +5.0°C)
> (emerg = +135.0°C, hyst = +5.0°C)
>
Looks like Nouveau fan control does not work. No idea what may be causing this ...
well, possibly. There are two suspicious commits between 3.12 and 3.13.
Maybe the "remove everything" commit has undesirable side effects.

eec9901 drm/nouveau/hwmon: fix compilation without CONFIG_HWMON
b9ed919 drm/nouveau/drm/pm: remove everything except the hwmon interfaces to THERM

I would suggest to open a separate bug against the Nouveau component.

[ Side note: The displayed values for hyst are wrong. Those should be absolute
temperatures, not temperature differences. But that is yet another bug. ]

> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0: +52.0°C (high = +83.0°C, crit = +99.0°C)
> Core 1: +50.0°C (high = +83.0°C, crit = +99.0°C)
> Core 2: +52.0°C (high = +83.0°C, crit = +99.0°C)
> Core 3: +50.0°C (high = +83.0°C, crit = +99.0°C)
>
> it8720-isa-0a10
> Adapter: ISA adapter
> in0: +0.86 V (min = +0.00 V, max = +4.08 V) ALARM
> in1: +3.04 V (min = +0.00 V, max = +4.08 V) ALARM
> in2: +3.33 V (min = +0.00 V, max = +4.08 V) ALARM
> +5V: +3.04 V (min = +0.00 V, max = +4.08 V) ALARM
> in4: +2.94 V (min = +0.00 V, max = +4.08 V) ALARM
> in5: +2.16 V (min = +0.00 V, max = +4.08 V) ALARM
> in6: +2.16 V (min = +0.00 V, max = +4.08 V) ALARM
> 5VSB: +2.96 V (min = +0.00 V, max = +4.08 V) ALARM
> Vbat: +2.99 V
> fan1: 838 RPM (min = 0 RPM)
> fan2: 949 RPM (min = 0 RPM)
> temp1: +127.0°C (low = -1.0°C, high = +127.0°C) ALARM sensor =
> thermal diode
> temp2: +22.0°C (low = -1.0°C, high = +127.0°C) ALARM sensor =
> thermistor
> temp3: -47.0°C (low = -1.0°C, high = +127.0°C) sensor = Intel PECI
> cpu0_vid: +0.000 V
> intrusion0: ALARM
>

Something in your system configuration is wrong. Usually this comes from the BIOS,
so you you might want to check if there is a BIOS upgrade available. It looks like
the system believes that your CPU is freezing and therefore runs the CPU fan at
minimum speed. That may be ok with the current load, but might be a problem
if the CPUs get busy and run hot. That is not related to the nouveau problem,
though.

Guenter

On 04/02/2014 01:39 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=71711
>
> --- Comment #7 from Roman Spirgi <the.ant@gmx.net> ---
> I'm not sure if this is related to this bug but since Kernel 3.13 my fan
> speed
> is far to high and noisy as soon as the system is booting up ... I'm using
> Fedora 20. With Kernel 3.12.X everything was fine instead and fan speed was
> on
> a acceptable level ...
>
> [ant@fedorant ~]$ sensors
> nouveau-pci-0100
> Adapter: PCI adapter
> fan1:        6693 RPM
> temp1:        +69.0°C  (high = +95.0°C, hyst =  +3.0°C)
>                         (crit = +105.0°C, hyst =  +5.0°C)
>                         (emerg = +135.0°C, hyst =  +5.0°C)
>
Looks like Nouveau fan control does not work. No idea what may be causing this ...
well, possibly. There are two suspicious commits between 3.12 and 3.13.
Maybe the "remove everything" commit has undesirable side effects.

eec9901 drm/nouveau/hwmon: fix compilation without CONFIG_HWMON
b9ed919 drm/nouveau/drm/pm: remove everything except the hwmon interfaces to THERM

I would suggest to open a separate bug against the Nouveau component.

[ Side note: The displayed values for hyst are wrong. Those should be absolute
   temperatures, not temperature differences. But that is yet another bug. ]

> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:       +52.0°C  (high = +83.0°C, crit = +99.0°C)
> Core 1:       +50.0°C  (high = +83.0°C, crit = +99.0°C)
> Core 2:       +52.0°C  (high = +83.0°C, crit = +99.0°C)
> Core 3:       +50.0°C  (high = +83.0°C, crit = +99.0°C)
>
> it8720-isa-0a10
> Adapter: ISA adapter
> in0:          +0.86 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> in1:          +3.04 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> in2:          +3.33 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> +5V:          +3.04 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> in4:          +2.94 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> in5:          +2.16 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> in6:          +2.16 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> 5VSB:         +2.96 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
> Vbat:         +2.99 V
> fan1:         838 RPM  (min =    0 RPM)
> fan2:         949 RPM  (min =    0 RPM)
> temp1:       +127.0°C  (low  =  -1.0°C, high = +127.0°C)  ALARM  sensor =
> thermal diode
> temp2:        +22.0°C  (low  =  -1.0°C, high = +127.0°C)  ALARM  sensor =
> thermistor
> temp3:        -47.0°C  (low  =  -1.0°C, high = +127.0°C)  sensor = Intel PECI
> cpu0_vid:    +0.000 V
> intrusion0:  ALARM
>

Something in your system configuration is wrong. Usually this comes from the BIOS,
so you you might want to check if there is a BIOS upgrade available. It looks like
the system believes that your CPU is freezing and therefore runs the CPU fan at
minimum speed. That may be ok with the current load, but might be a problem
if the CPUs get busy and run hot. That is not related to the nouveau problem,
though.

Guenter

Revision history for this message

In Linux Kernel Bug Tracker #71711, daniele.rogora (daniele.rogora-linux-kernel-bugs) wrote on 2014-04-02:

#34

I can confirm the original bug reported. I reproduced it with a HP 625 (AMD athlon processor with AMD HD 4200 graphics) laptop.

I tested ubuntu 3.12, 3.13 and 3.14 kernels, and the problem appeared in 3.13.

Best regards,
Daniele

Revision history for this message

In Linux Kernel Bug Tracker #71711, jdelvare (jdelvare-linux-kernel-bugs) wrote on 2014-04-03:

#35

(In reply to Guenter Roeck from comment #8)
> Something in your system configuration is wrong. Usually this comes from the
> BIOS, so you you might want to check if there is a BIOS upgrade available. It
> looks like the system believes that your CPU is freezing and therefore runs
> the CPU fan at minimum speed.

As I recall the IT87xx chips need an offset programmed by the
BIOS in order to return "sane" temperature values from PECI sources.
Without the offset, the driver returns the thermal margin as a negative
value (-47°C here would mean the CPU runs 47 pseudo-°C below its
critical temperature.) This matches the values returned by coretemp (99
- 47 = 52). This would justify the low fan speeds.

The original poster could try setting temp3_offset to 99 (in the right chip section of sensors.conf, followed by "sensors -s" as root) and see if it makes the system behave differently.

Revision history for this message

In Linux Kernel Bug Tracker #71711, the.ant (the.ant-linux-kernel-bugs) wrote on 2014-04-03:

#36

Jean, indeed:
...
temp3: +46.0°C (low = -1.0°C, high = +127.0°C) sensor = Intel PECI
...
But it's definitely noisier now ;)

Guenter, thank you, I did open "https://bugs.freedesktop.org/show_bug.cgi?id=77003" for the NVIDIA fan speed issue.

Thank you guys,
Roman

Revision history for this message

In Linux Kernel Bug Tracker #71711, jdelvare (jdelvare-linux-kernel-bugs) wrote on 2014-04-03:

#37

It really all depends on what the automatic fan control setup expects. Unfortunately I don't think the it87 driver exposes its trip points to user-space so you'd have to poke at the registers directly.

Jernej Jakob (jjakob) on 2014-04-03

tags:

added: kernel-bug-reported-upstream

Revision history for this message

In Linux Kernel Bug Tracker #71711, jernej.jakob (jernej.jakob-linux-kernel-bugs) wrote on 2014-04-04:

#38

Hello everyone,

I can confirm this bug as well on an HP Probook 4710s. So there are now at least 5 confirmed reports.

Please see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1290110 (my bug report)
http://lkml.iu.edu//hypermail/linux/kernel/1404.0/02012.html (my archived post to the linux-kernel mailing list)

It would be worth to also take a look at the DSDT, as there are other minor quirks on my system that could point there... (brightness always on max after reboot/suspend, coarse brightness setting range)
I've already disassembled mine but am stumped at what to do next (this is my first look at anything ACPI related), how to debug...

But as previous kernels worked okay with this same DSDT, maybe they didn't control the fan speed through ACPI but left it to the BIOS?

For info on disassembling the DSDT see https://wiki.archlinux.org/index.php/DSDT

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-04-06:

#39

I've now bisected two times. From two different kernel origins, just to be sure, as I'm new to this stupid-and-lengthy method, and, to be sure, I haven't given a false positive inbetween due to boredom.

In the end it says each time:
# git bisect bad | tee -a /var/log/bisect.log
cc8ef52707341e67a12067d6ead991d56ea017ca is the first bad commit
commit cc8ef52707341e67a12067d6ead991d56ea017ca
Author: Zhang Rui <email address hidden>
Date: Wed Sep 25 20:39:45 2013 +0800

ACPI / AC: convert ACPI ac driver to platform bus

Signed-off-by: Zhang Rui <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>

:040000 040000 5a0d397cfcbf53c03390f2805b83754cb7837d84 4a2af1454f65d67f1d1a507c08e3b9ef3ffe57e7 M drivers

Please help me, on how I can help debug this more, and please also read the newest from
https://bugzilla.kernel.org/show_bug.cgi?id=71711

Manuel Krause

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2014-04-07:

#40

Download full text (3.9 KiB)

Hi, Manuel,

nice report.

(In reply to Manuel Krause from comment #3)
>
> 3.13.5 -- 20140309 -- 20:52 -- bad
> =============================
> dir |-
> /type /cur_state /max_state
> cooling_device0 Processor 0 10
> cooling_device1 Processor 0 10
> cooling_device2 Fan 0 1
> cooling_device3 Fan 1 1
> cooling_device4 Fan 0 1
> cooling_device5 Fan 0 1
> cooling_device6 Fan 0 1
> cooling_device7 LCD 0 24
>
> 3.12.13 -- 20140310 -- 00:26 -- good
> ==============================
> dir |-
> /type /cur_state /max_state
> cooling_device0 Processor 0 10
> cooling_device1 Processor 0 10
> cooling_device2 Fan 0 1
> cooling_device3 Fan 1 1
> cooling_device4 Fan 1 1
> cooling_device5 Fan 1 1
> cooling_device6 Fan 1 1
> cooling_device7 LCD 0 24
>
>
> 3.13.5 -- 20140309 -- 20:52 -- bad
> =============================
> dir |-
> /passive /temp |- /cdev?_ /trip_ /trip_
> trip_ point_ point_
> point ?_temp ?_type
> thermal_zone0 0 68000 ?=0 n.a. 256000 critical
> thermal_zone1 n.a. 70000 |-
> ?=0 6 110000 critical
> ?=1 5 107000 passive
> ?=2 4 90000 active
> ?=3 3 75000 active
> ?=4 2 55000 active
> ?=5 1 45000 active
> ?=6 1 30000 active
> thermal_zone2 n.a. 54000 |-
> ?=0 1 105000 critical
> ?=1 1 95000 passive
> thermal_zone3 n.a. 25800 |-
> ?=0 1 110000 critical
> ?=1 1 60000 passive
> thermal_zone4 0 58000 ?=0 n.a. 110000 critical
>
>
> 3.12.13 -- 20140310 -- 00:26 -- good
> ==============================
> dir |-
> /passive /temp |- /cdev?_ /trip_ /trip_
> trip_ point_ point_
> point ?_temp ?_type
> thermal_zone0 0 50000 ?=0 n.a. 256000 critical
> thermal_zone1 n.a. 70000 |-
> ?=0 1 110000 critical
> ?=1 1 107000 passive
> ?=2 2 90000 active
> ?=3 3 67000 active
> ?=4 4 55000 active
> ?=5 5 45000 active
> ?=6 6 30000 active
> thermal_zon...

Hi, Manuel,

nice report.

(In reply to Manuel Krause from comment #3)
> 
>  3.13.5 -- 20140309 -- 20:52 -- bad
> =============================
> dir             |-
>                  /type       /cur_state  /max_state
> cooling_device0  Processor    0          10
> cooling_device1  Processor    0          10
> cooling_device2  Fan          0           1
> cooling_device3  Fan          1           1
> cooling_device4  Fan          0           1
> cooling_device5  Fan          0           1
> cooling_device6  Fan          0           1
> cooling_device7  LCD          0          24
> 
>  3.12.13 -- 20140310 -- 00:26 -- good
> ==============================
> dir             |-
>                  /type       /cur_state  /max_state
> cooling_device0  Processor    0          10
> cooling_device1  Processor    0          10
> cooling_device2  Fan          0           1
> cooling_device3  Fan          1           1
> cooling_device4  Fan          1           1
> cooling_device5  Fan          1           1
> cooling_device6  Fan          1           1
> cooling_device7  LCD          0          24
> 
> 
>  3.13.5 -- 20140309 -- 20:52 -- bad
> =============================
> dir          |-
>               /passive /temp  |-     /cdev?_  /trip_   /trip_
>                                       trip_    point_   point_
>                                       point    ?_temp   ?_type
> thermal_zone0  0        68000   ?=0    n.a.   256000   critical
> thermal_zone1   n.a.    70000 |-
>                                 ?=0   6       110000   critical
>                                 ?=1   5       107000   passive
>                                 ?=2   4        90000   active
>                                 ?=3   3        75000   active
>                                 ?=4   2        55000   active
>                                 ?=5   1        45000   active
>                                 ?=6   1        30000   active
> thermal_zone2   n.a.    54000 |-
>                                 ?=0   1       105000   critical
>                                 ?=1   1        95000   passive
> thermal_zone3   n.a.    25800 |-
>                                 ?=0   1       110000   critical
>                                 ?=1   1        60000   passive
> thermal_zone4  0        58000   ?=0    n.a.   110000   critical
> 
> 
>  3.12.13 -- 20140310 -- 00:26 -- good
> ==============================
> dir          |-
>               /passive /temp  |-     /cdev?_  /trip_   /trip_
>                                       trip_    point_   point_
>                                       point    ?_temp   ?_type
> thermal_zone0  0        50000   ?=0    n.a.   256000   critical
> thermal_zone1   n.a.    70000 |-
>                                 ?=0   1       110000   critical
>                                 ?=1   1       107000   passive
>                                 ?=2   2        90000   active
>                                 ?=3   3        67000   active
>                                 ?=4   4        55000   active
>                                 ?=5   5        45000   active
>                                 ?=6   6        30000   active
> thermal_zone2   n.a.    53000 |-
>                                 ?=0   1       105000   critical
>                                 ?=1   1        95000   passive
> thermal_zone3   n.a.    25600 |-
>                                 ?=0   1       110000   critical
>                                 ?=1   1        60000   passive
> thermal_zone4  0        58000   ?=0    n.a.   110000   critical
> 
this is not enough, can you please attach the output of 
" grep . /sys/class/thermal/thermal_zone*/cdev*/device/path"

I need to figure out why /sys/class/thermal/thermal_zone1/cdev0_trip_point equals 1 in 3.12, while it equals 6 in 3.13.

plus, can you please attach the output of "grep . /sys/class/thermal/cooling_device*/device/path" in both 3.12 and 3.13 as well.

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-04-14:

#8

Changed URL to HTTPS

Jernej Jakob (jjakob) on 2014-05-27

tags:

added: kernel-fixed-upstream kernel-fixed-upstream-3.15-rc6
removed: kernel-bug-exists-upstream kernel-bug-reported-upstream

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-05-27:

#9

The bug is fixed in 3.15-rc6. The patch is at https://patchwork.kernel.org/patch/4124871/ and a patch adapted for 3.14.4 is here: https://bugzilla.kernel.org/attachment.cgi?id=136881

A backport to 3.13 is needed for it to get into Trusty AFAIK...

Revision history for this message

Oliver Joos (oliver-joos) wrote on 2014-06-12:

#10

My old HP Compaq nx8220 is affected, too.

I use Kernel 3.13.0-27-generic. Since this is an LTS (Long Term Support) release I hope that a fix will be backported to 3.13.
After reading the upstream report I think the current patches are not the final solution.

Oliver Joos (oliver-joos) on 2014-06-13

summary:

Fan stops after resume from suspend leading to overheating; requires
- reboot to fix [HP Probook 4710s]
+ reboot to fix [HP Probook 4710s and many others]

Revision history for this message

In Linux Kernel Bug Tracker #71711, jza (jza-linux-kernel-bugs) wrote on 2014-06-13:

#84

DMI: Hewlett-Packard HP 2230s /3037, BIOS 68PHU Ver. F.20 12/10/2011

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2014-06-14:

#85

Manuel, please file a new bug.

Dhinak G (dhinak2004) on 2014-06-15

affects:	linux → ubuntu
Changed in ubuntu:
status:	Unknown → Confirmed
status:	Confirmed → Fix Released

Revision history for this message

Dhinak G (dhinak2004) wrote on 2014-06-15:

#11

I checked on the Linux Bug Tracker (or something related) and it says a patch is out.

Run "sudo apt-get update && sudo apt-get upgrade" and if that doesn't work,

install indicator-cpufreq: "sudo apt-get install indicator-cpufreq", log out, and login.

Look at your menu bar. A pic of a CPU will be there, and click. Select Powersave from the menu.

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-06-17:

#86

(In reply to Zhang Rui from comment #60)
> Manuel, please file a new bug.

A BIOS update from F.17 to F.20 did not achieve any efforts.

Btw., some distro specific bug reports falsely (not from my hands) point to here.

I've now filed a new bug upon my Comment 52 ++
https://bugzilla.kernel.org/show_bug.cgi?id=78201

Thank you all for your guidance,
Manuel

Revision history for this message

Oliver Joos (oliver-joos) wrote on 2014-06-19:

#12

Hi Dhinak. Which kernel does work for you?

I tested 3.13.0-24, then 3.13.0-27 and since this week there is 3.13.0-29 to upgrade to. For my two HP nx8220 all 3 kernels do not control the cpu fan correctly! Both laptops ran Ubuntu since 7 years without major problems.
My 2 laptops are: HP Compaq nx8220 (PY518EA#UUZ)/0934, BIOS 68DTV Ver. F.16 07/11/2007

I do not agree that this bug has a "Fix Released". The upstream bug is "resolved - patch available", but there is a discussion that this patch only solves it for some hardware - not all! And for latest Ubuntu 14.04 (LTS!) it is not solved until the patch has has been backported to kernel 3.13.x - this has not been done yet either.

Therefore I think we should rewind this report to "Confirmed" to prevent affected people from opening new reports about the same issue. Please write if you disagree.

BTW: the workaround to force Powersave does work, but makes our laptops unusable slow.

Dhinak G (dhinak2004) on 2014-06-19

Changed in linux (Ubuntu):
status:	Triaged → Confirmed

Revision history for this message

Dhinak G (dhinak2004) wrote on 2014-06-19:

#13

The problem is becaue its the daily build. Try a reinstall with stable.

Revision history for this message

Dhinak G (dhinak2004) wrote on 2014-06-19:

#14

For me, I have it working on every kernel.

Revision history for this message

Oliver Joos (oliver-joos) wrote on 2014-06-19:

#15

I did not install a daily build of Ubuntu or the kernel. But fan does not work since 14.04.

@Dhinak: could you write which kernel 3.13.0-?? works for you, and what hardware/BIOS you have, e.g. with Terminal command:
sudo dmidecode | head

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-06-19:

#16

For me this bug is definitely fixed in 3.15-rc6, and AFAIK from this release onwards, so daily build of mainline should also work. Of course the patch is not yet backported, which it urgently must be. For now just install latest mainline from instructions on Ubuntu wiki.
If there is still a fault when you try 3.15-rc6 this must be an unrelated bug.

Revision history for this message

Jernej Jakob (jjakob) wrote on 2014-06-19:

#17

I mean the kernel, of course. There is no need to reinstall Ubuntu 14.04 daily (in fact it would be pointless as the bug is still there). I've had it since alpha and it works fine with kernel 3.15-rc6 installed.

Dhinak G (dhinak2004) on 2014-06-19

Changed in linux (Ubuntu):
assignee:	nobody → Dhinak G (dhinak2004)
affects:	ubuntu → baltix
affects:	baltix → ubuntu
no longer affects:	linux (Debian)

Revision history for this message

Joonas Saarinen (jza) wrote on 2014-07-04:

#18

Apparently this was reverted in v3.13.11.4.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.4-trusty/CHANGES

The main 3.13.0-?? kernel (linux-image package of Ubuntu 14.04) is still affected though.

Revision history for this message

In Linux Kernel Bug Tracker #71711, oliver.joos (oliver.joos-linux-kernel-bugs) wrote on 2014-07-04:

#87

Our 3 laptops Compaq nx8220 run Mint 17 and I just upgraded to 3.13.0-30. They are still affected. After resume they heat up to 100°C until cpu throttling occurs. A quite serious issue.

Jörg-Karl Bösner did a reverse-bisect and may have found the evil commit: https://launchpad.net/bugs/1312860

Please backport the fix also to 3.13.x, since this kernel is part of many "Long Term Support" distros.

Revision history for this message

In Linux Kernel Bug Tracker #71711, jza (jza-linux-kernel-bugs) wrote on 2014-07-04:

#88

That 3.13.0-30 is an Ubuntu kernel and is always based on upstream 3.13.0 with Canonical's own selection of patches applied on top of it. From there the same kernel seems to trickle to Mint. So Ubuntu would have to apply the patch "ACPI / AC: convert ACPI ac driver to platform bus" to the 3.13.0-?? patch queue.

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-07-04:

#89

I don't know if it's still valid, but the patch had been picked up by Kamal Mostafa who has told to maintain 3.13.y.z.
Patch: http://patchwork.ozlabs.org/patch/360895/

Maybe you'd also like to read
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
and https://lkml.org/lkml/2014/4/23/516

Best regards,
Manuel Krause

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2014-07-04:

#90

(In reply to Oliver Joos from comment #62)
> Our 3 laptops Compaq nx8220 run Mint 17 and I just upgraded to 3.13.0-30.
> They are still affected. After resume they heat up to 100°C until cpu
> throttling occurs. A quite serious issue.
>
> Jörg-Karl Bösner did a reverse-bisect and may have found the evil commit:
> https://launchpad.net/bugs/1312860
>
> Please backport the fix also to 3.13.x, since this kernel is part of many
> "Long Term Support" distros.

This BUG, here, only covers false fan speed after booting.

For the issue of high temperatures without fan action after resume from disk/RAM, please attach to https://bugzilla.kernel.org/show_bug.cgi?id=78201.

Thank you in advance,
Manuel Krause

Revision history for this message

In Linux Kernel Bug Tracker #71711, jza (jza-linux-kernel-bugs) wrote on 2014-07-05:

#91

> So Ubuntu would have to apply the patch "ACPI / AC: convert ACPI ac driver to
> platform bus" to the 3.13.0-?? patch queue.

Just to refine my message a bit...they obviously should apply the *revert* patch. :)

Here's also a direct link to the aforementioned "extended stable" Ubuntu kernel, where it already is reverted:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.11.4-trusty/

But as Manuel says, in Oliver's case it might actually be a different bug if it reveals itself after suspend.

Revision history for this message

In Linux Kernel Bug Tracker #71711, jza (jza-linux-kernel-bugs) wrote on 2014-07-05:

#92

Looking at this changelog, the revert patch seems to be already part of upcoming 3.13.0-31 Ubuntu kernel.

https://launchpad.net/ubuntu/trusty/+source/linux/+changelog

Revision history for this message

Oliver Joos (oliver-joos) wrote on 2014-07-13:

#19

For me it is solved with kernel 3.13.0-32 from https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa
Careful users should wait a few days to get the fixed kernel as a normal update!

From what I have read the problem was a kernel patch called "ACPI / AC: convert ACPI ac driver to platform bus" which has now been reverted in kernel 3.13.0-31 and higher.

Revision history for this message

Taleb Abdelhak (my-rk) wrote on 2014-07-13:

#20

Running kernel 3.13.0-32, bug is STILL PRESENT
laptop : HP 620

Revision history for this message

Oliver Joos (oliver-joos) wrote on 2014-07-13:

#21

@Taleb: I feel with you! But Jerney (reporter of this bug) also wrote in comment #16 that it is solved for him. Therefore I would open a new report exactly about your issue, with all details of your system and symptoms.

Jernej Jakob (jjakob) on 2014-08-12

Changed in linux (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

Juan Carlos (arareka-ha) wrote on 2014-10-02:

#22

Hi, installed Ubuntu 14.10 on my HP Probook 4525s and when resume from suspend fan work slowly. Normally laptop work at 53/55 C.
But after resume from suspend temperature go to 60/70 C.

Revision history for this message

In Linux Kernel Bug Tracker #71711, jose_wojnacki (josewojnacki-linux-kernel-bugs) wrote on 2015-01-18:

#93

I'm running Archlinux (up to date) and I'm having the same issue. With the latest kernel 3.18.2 the problem is still there for me. Every time I unplug the ac power the laptop fan stops until temp reaches 84°C and then ramps down to 74°C with full speed fan.
With kernel 3.11.4 I have no problem at all.
Do you guys still have this issue?

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2015-01-19:

#94

There are currently many HP/Compaq notebook owners having problems with kernel 3.18.x. We are waiting for Zhang Rui to wake up from his winter sleep & him to catch up. See: https://bbs.archlinux.org/viewtopic.php?id=192255&p=2 (Read from the first page to get full info, and, some people on there don't handle the full fan speed value correctly.)

Most probably you would need to file a new BUG, but I'd attach to it soon with my logs..

Best regards,
Manuel

Revision history for this message

In Linux Kernel Bug Tracker #71711, manuelkrause (manuelkrause-linux-kernel-bugs) wrote on 2015-01-19:

#95

You can also have a look at https://bugzilla.kernel.org/show_bug.cgi?id=78201, if that's something regarding your fan problem.

Best regards, Manuel

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-01-19:

#96

for my hardware , the problem seems to be resolved by installing the latest beta of osx 10.10.2 , it has a firmware update that solves the issue under linux & windows .
hope this helps .

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-01-30:

#97

nope , the problem is still there :

temperature is fine around 35 to 40 c ,

but the fans kiks rpm from 2000 to 5900 & then back to 4100 ,

cpu utilization is 10 - 13 % .

kernel : 3.18.4
os : Archlinux
Hardware : Macbook Air 2013

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-02-16:

#98

PLEASE RESPOND ,

the problem is solved by updating to a new firmware with osx 10.10.2 ,

in linux 3.19 , the patch you have made make the laptop very noisy & fans

spinning at a very high rpm .

in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,

so can you please kindly revert or remove the patch , as it's not necessary any

more after osx 10.10.2 update .

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-02-17:

#99

(In reply to step-ali from comment #73)
> PLEASE RESPOND ,
>
> the problem is solved by updating to a new firmware with osx 10.10.2 ,
>
> in linux 3.19 , the patch you have made make the laptop very noisy & fans
>
> spinning at a very high rpm .
>
which patch are you referring to?

> in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
>
>
> so can you please kindly revert or remove the patch , as it's not necessary
> any
>
> more after osx 10.10.2 update .

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-02-20:

#100

(In reply to Zhang Rui from comment #74)
> (In reply to step-ali from comment #73)
> > PLEASE RESPOND ,
> >
> > the problem is solved by updating to a new firmware with osx 10.10.2 ,
> >
> > in linux 3.19 , the patch you have made make the laptop very noisy & fans
> >
> > spinning at a very high rpm .
> >
> which patch are you referring to?
>
> > in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
> >
> >
> > so can you please kindly revert or remove the patch , as it's not necessary
> > any
> >
> > more after osx 10.10.2 update .

the patch that made the fans spin harder ,

all i know is on 3.19 there is no heat but the fans spin at high rpm on 10-15

cpu utilization

on 3.14.33 there is heat up to 89 c & the fans doesn't spin up on the same cpu

utilization .

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-03:

#101

(In reply to step-ali from comment #75)
> (In reply to Zhang Rui from comment #74)
> > (In reply to step-ali from comment #73)
> > > PLEASE RESPOND ,
> > >
> > > the problem is solved by updating to a new firmware with osx 10.10.2 ,
> > >
> > > in linux 3.19 , the patch you have made make the laptop very noisy & fans
> > >
> > > spinning at a very high rpm .
> > >
> > which patch are you referring to?
> >
> > > in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
> > >
> > >
> > > so can you please kindly revert or remove the patch , as it's not
> necessary
> > > any
> > >
> > > more after osx 10.10.2 update .
>
> the patch that made the fans spin harder ,
>
step-ali,
actually, I don't think which patch introduces this problem.
But there is indeed some bug report complaining that the fan speed never changes after boot, since 3.18.
so can you please refer to bug #93301 and check if it is the same commit (6ab3430129e258ea31dd214adf1c760dfafde67a) that introduces this problem for you?

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-03:

#102

(In reply to Zhang Rui from comment #76)
> (In reply to step-ali from comment #75)
> > (In reply to Zhang Rui from comment #74)
> > > (In reply to step-ali from comment #73)
> > > > PLEASE RESPOND ,
> > > >
> > > > the problem is solved by updating to a new firmware with osx 10.10.2 ,
> > > >
> > > > in linux 3.19 , the patch you have made make the laptop very noisy &
> fans
> > > >
> > > > spinning at a very high rpm .
> > > >
> > > which patch are you referring to?
> > >
> > > > in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
> > > >
> > > >
> > > > so can you please kindly revert or remove the patch , as it's not
> necessary
> > > > any
> > > >
> > > > more after osx 10.10.2 update .
> >
> > the patch that made the fans spin harder ,
> >
> step-ali,
> actually, I don't think which patch introduces this problem.
> But there is indeed some bug report complaining that the fan speed never
> changes after boot, since 3.18.
> so can you please refer to bug #93301 and check if it is the same commit
> (6ab3430129e258ea31dd214adf1c760dfafde67a) that introduces this problem for
> you?

I don't think so ,

before 3.18 we had a high cpu utilization (25 to 30%) that was fixed by recent

apple osx 10.10.2 update , ( the problem was solved temporarily by disabling

some gpe ) but there wasn't any fan or heat problem .

After the osx 10.10.2 update ( was during linux 3.18 ) the fan spins up ( very

high rpm )on very little cpu utilization ( watching a video in chrome ) & then

spins down when idling .

on 3.14.33 it's the reverse , the fan doesn't spin up but the temperature rises

to 90 degree celsius ( also while watching videos on chrome ) , which is

harmful to the laptop .

the solution would be something in the middle ,

BUT PLEASE HURRY , MY MACHINE IS FRYING .

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-14:

#103

Please
1. rebuild your kernel with the patches at https://bugzilla.kernel.org/show_bug.cgi?id=78201#c150 applied.
2. run echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control after boot
3. attach the dmesg output after the problem is reproduced.

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-15:

#104

(In reply to Zhang Rui from comment #78)
> Please
> 1. rebuild your kernel with the patches at
> https://bugzilla.kernel.org/show_bug.cgi?id=78201#c150 applied.
> 2. run echo 'module thermal_sys +fp' >
> /sys/kernel/debug/dynamic_debug/control after boot
> 3. attach the dmesg output after the problem is reproduced.

sorry , I don't know how to merge a patch & compile .

after weeks of testing it looks like another firmware issue that needs to be

updated from apple , like the gpe66 issue , because the issue is also occurring

in windows too ( high temperature ) .

when i first bought the laptop it ran fine with linux , i guess i wish i never

updated osx , i never use it anyway .

i will submit a bug report to apple & see what happen .

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-16:

#105

as there is a firmware update, so can you please try 3.14 kernel again with your new firmware(In reply to step-ali from comment #77)
> (In reply to Zhang Rui from comment #76)
> > (In reply to step-ali from comment #75)
> > > (In reply to Zhang Rui from comment #74)
> > > > (In reply to step-ali from comment #73)
> > > > > PLEASE RESPOND ,
> > > > >
> > > > > the problem is solved by updating to a new firmware with osx 10.10.2
> ,
> > > > >
> > > > > in linux 3.19 , the patch you have made make the laptop very noisy &
> fans
> > > > >
> > > > > spinning at a very high rpm .
> > > > >
> > > > which patch are you referring to?
> > > >
> > > > > in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
> > > > >
> > > > >
> > > > > so can you please kindly revert or remove the patch , as it's not
> necessary
> > > > > any
> > > > >
> > > > > more after osx 10.10.2 update .
> > >
> > > the patch that made the fans spin harder ,
> > >
> > step-ali,
> > actually, I don't think which patch introduces this problem.
> > But there is indeed some bug report complaining that the fan speed never
> > changes after boot, since 3.18.
> > so can you please refer to bug #93301 and check if it is the same commit
> > (6ab3430129e258ea31dd214adf1c760dfafde67a) that introduces this problem for
> > you?
>
> I don't think so ,
>
> before 3.18 we had a high cpu utilization (25 to 30%) that was fixed by
> recent
>
> apple osx 10.10.2 update , ( the problem was solved temporarily by disabling
>
> some gpe ) but there wasn't any fan or heat problem .
>
>
> After the osx 10.10.2 update ( was during linux 3.18 ) the fan spins up (
> very
>
> high rpm )on very little cpu utilization ( watching a video in chrome ) &
> then
>
> spins down when idling .
>
>
> on 3.14.33 it's the reverse , the fan doesn't spin up but the temperature
> rises
>
> to 90 degree celsius ( also while watching videos on chrome ) , which is
>
> harmful to the laptop.
>
is this symptom got with updated firmware?

as there is a firmware update, so can you please try 3.14 kernel again with your new firmware(In reply to step-ali from comment #77)
> (In reply to Zhang Rui from comment #76)
> > (In reply to step-ali from comment #75)
> > > (In reply to Zhang Rui from comment #74)
> > > > (In reply to step-ali from comment #73)
> > > > > PLEASE RESPOND ,
> > > > > 
> > > > > the problem is solved by updating to a new firmware with osx 10.10.2
> ,
> > > > > 
> > > > > in linux 3.19 , the patch you have made make the laptop very noisy &
> fans
> > > > > 
> > > > > spinning at a very high rpm .
> > > > > 
> > > > which patch are you referring to?
> > > > 
> > > > > in linux 3.14.33 , everything is fine ( thermal , fan rpm ) ,
> > > > > 
> > > > > 
> > > > > so can you please kindly revert or remove the patch , as it's not
> necessary
> > > > > any 
> > > > > 
> > > > > more after osx 10.10.2 update .
> > > 
> > > the patch that made the fans spin harder ,
> > > 
> > step-ali,
> > actually, I don't think which patch introduces this problem.
> > But there is indeed some bug report complaining that the fan speed never
> > changes after boot, since 3.18.
> > so can you please refer to bug #93301 and check if it is the same commit
> > (6ab3430129e258ea31dd214adf1c760dfafde67a) that introduces this problem for
> > you?
> 
> I don't think so ,
> 
> before 3.18 we had a high cpu utilization (25 to 30%) that was fixed by
> recent 
> 
> apple osx 10.10.2 update , ( the problem was solved temporarily by disabling 
> 
> some gpe ) but there wasn't any fan or heat problem .
> 
> 
> After the osx 10.10.2 update ( was during linux 3.18 ) the fan spins up (
> very 
> 
> high rpm )on very little cpu utilization ( watching a video in chrome ) &
> then 
> 
> spins down when idling .
> 
> 
> on 3.14.33 it's the reverse , the fan doesn't spin up but the temperature
> rises 
> 
> to 90 degree celsius ( also while watching videos on chrome ) , which is 
> 
> harmful to the laptop.
> 
is this symptom got with updated firmware?

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-16:

#106

it's after kernel 3.18 & osx firmware update

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-24:

#107

> >
> > on 3.14.33 it's the reverse , the fan doesn't spin up but the temperature
> > rises
> >
> > to 90 degree celsius ( also while watching videos on chrome ) , which is
> >
> > harmful to the laptop.
> >
> is this symptom got with updated firmware?

I mean did you get this symptom with 3.14 kernel, after firmware updated?

Please do the following test on 4.0-rc kernel
1. apply the patches at
https://patchwork.kernel.org/patch/6077231/
https://patchwork.kernel.org/patch/6077241/
https://patchwork.kernel.org/patch/6077251/
2. please apply the two patches attached later
3. after build, please boot with kernel parameter module.dyndbg="module thermal_sys +fp" dyndbg="file thermal_core.c +fp; file step_wise.c +fp"
4. attach the acpidump output of your mac book
5. attach the output of "grep . /sys/class/thermal/*/*/path" after boot
6. attach the dmesg output after the bug reproduced
7. attach the output of "grep . /sys/class/thermal/thermal*/*" after the bug reproduced

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-24:

#108

Created attachment 171921
patch 4

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-24:

#109

Created attachment 171931
patch-5

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-29:

#110

ping...

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-29:

#111

(In reply to Zhang Rui from comment #82)
> > >
> > > on 3.14.33 it's the reverse , the fan doesn't spin up but the temperature
> > > rises
> > >
> > > to 90 degree celsius ( also while watching videos on chrome ) , which is
> > >
> > > harmful to the laptop.
> > >
> > is this symptom got with updated firmware?
>
> I mean did you get this symptom with 3.14 kernel, after firmware updated?
>
> Please do the following test on 4.0-rc kernel
> 1. apply the patches at
> https://patchwork.kernel.org/patch/6077231/
> https://patchwork.kernel.org/patch/6077241/
> https://patchwork.kernel.org/patch/6077251/
> 2. please apply the two patches attached later
> 3. after build, please boot with kernel parameter module.dyndbg="module
> thermal_sys +fp" dyndbg="file thermal_core.c +fp; file step_wise.c +fp"
> 4. attach the acpidump output of your mac book
> 5. attach the output of "grep . /sys/class/thermal/*/*/path" after boot
> 6. attach the dmesg output after the bug reproduced
> 7. attach the output of "grep . /sys/class/thermal/thermal*/*" after the bug
> reproduced

yes , the symptom is htere after firmware update on 3.14 lts & 3.19

Revision history for this message

In Linux Kernel Bug Tracker #71711, e.glorg (e.glorg-linux-kernel-bugs) wrote on 2015-03-29:

#112

Upgraded to kernel 3.16 from Debian Jessie repos. Having performed no firmware upgrade, just upgraded OS. Strange, but problem has gone.
Here's uname output:
$ uname -srvom
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux
$ cat /etc/issue
Debian GNU/Linux 8
Installation of 3.16 on Debian 7.x still gives that old problem.

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-29:

#113

(In reply to E.Glorg from comment #87)
> Upgraded to kernel 3.16 from Debian Jessie repos. Having performed no
> firmware upgrade, just upgraded OS. Strange, but problem has gone.
> Here's uname output:
> $ uname -srvom
> Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64
> GNU/Linux
> $ cat /etc/issue
> Debian GNU/Linux 8
> Installation of 3.16 on Debian 7.x still gives that old problem.

yep , upgrade to any kernel above 3.17 & you will have the problem again

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-03-29:

#114

ha ,

i discovered something strange ,

under wayland everything is running normally 69 degree celsius ( where it was

around 85-90 under Xorg ) fan rpm is 1300 ( 5000 under xorg ) all using the same

kernel 3.14.37 lts running under Archlinux .

could it be a xorg-server issue ??!

if so then how come the problem disappear with kernel under 3.17 ??!

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-03-30:

#115

(In reply to step-ali from comment #86)
> (In reply to Zhang Rui from comment #82)
> > > >
> > > > on 3.14.33 it's the reverse , the fan doesn't spin up but the
> temperature
> > > > rises
> > > >
> > > > to 90 degree celsius ( also while watching videos on chrome ) , which
> is
> > > >
> > > > harmful to the laptop.
> > > >
> > > is this symptom got with updated firmware?
> >
> > I mean did you get this symptom with 3.14 kernel, after firmware updated?
> >
> > Please do the following test on 4.0-rc kernel
> > 1. apply the patches at
> > https://patchwork.kernel.org/patch/6077231/
> > https://patchwork.kernel.org/patch/6077241/
> > https://patchwork.kernel.org/patch/6077251/
> > 2. please apply the two patches attached later
> > 3. after build, please boot with kernel parameter module.dyndbg="module
> > thermal_sys +fp" dyndbg="file thermal_core.c +fp; file step_wise.c +fp"
> > 4. attach the acpidump output of your mac book
> > 5. attach the output of "grep . /sys/class/thermal/*/*/path" after boot
> > 6. attach the dmesg output after the bug reproduced
> > 7. attach the output of "grep . /sys/class/thermal/thermal*/*" after the
> bug
> > reproduced
>
> yes , the symptom is htere after firmware update on 3.14 lts & 3.19

please do the test and attach the debug information requested above.

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-04-13:

#116

ping...

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-04-19:

#117

sorry , don't know how to apply patches to the kernel ,

but the problem is still there with kernel 4.0 .

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-05-04:

#118

do you know how to build a customized kernel?
please download the patches and run "patch -p1 < foo.patch" to apply each of them in ascending order, and then build the kernel.

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-05-25:

#119

ping...

Revision history for this message

In Linux Kernel Bug Tracker #71711, rui.zhang (rui.zhang-linux-kernel-bugs) wrote on 2015-06-03:

#120

bug closed as we can more make any progress w/o bug reporter' response and help.
Please feel free to reopen it if you can build customized kernel to help debug the issue.

Revision history for this message

In Linux Kernel Bug Tracker #71711, sunmooon15 (sunmooon15-linux-kernel-bugs) wrote on 2015-06-03:

#121

(In reply to Zhang Rui from comment #95)
> bug closed as we can more make any progress w/o bug reporter' response and
> help.
> Please feel free to reopen it if you can build customized kernel to help
> debug the issue.

sorry , just don't have the time to build a customized kernel ,

will test with 4.1 .

Revision history for this message

derWalter (walter-derwalter) wrote on 2017-08-23:

#23

Happens regularly but not every time on ubuntu 16.04 on a thinkpad x201.

Revision history for this message

Julien Olivier (julo) wrote on 2019-04-27:

#24

The bug is still very present in Ubuntu 19.04.

Brad Figg (brad-figg) on 2019-07-24

tags:

added: cscc

Revision history for this message

In Linux Kernel Bug Tracker #71711, peterek355 (peterek355-linux-kernel-bugs) wrote on 2021-10-09:

#122

Mr Zhang Rui,

I notice that this bug is still affected HP notebooks in all new kernels. I want to reopen this bug report.

I am not experienced user but I tried all popular distributions like Fedora 34 with 5.11 kernel, Ubuntu 20.04 with 5.4 kernel, SUSE Linux Enterprise Desktop 15 SP3 with 5.3 kernel.

My fans are constantly in IDLE speed. It is doesn't matter if my CPU usage is 100% or 0%, this have this same low speed. Sometimes my notebook shut down because it is overheating. Sometimes my fans are running 100% speed for few seconds when my hardware is very hot and then this return to behaviour with IDLE speed.

So I have question. Why these patches from this bug was not applied to upstream final kernel?

Can I fix my issue without compiling new kernel with modifications? I thinked about thermald daemon but I don't know it is compatilbe with AMD processors? If yes, how I can configure it to fix issues? I also finded some program in github to HP 625 but still I am not coder (I learning) so I don't know if it program is working and if it is safe.

I hope that you can help.

Yours faithfully,
PeterQ

Bug Watch Updater (bug-watch-updater) on 2021-10-09

Changed in ubuntu:
importance:	Unknown → High
status:	Fix Released → Expired

Revision history for this message

In Linux Kernel Bug Tracker #71711, o3ouo4yip (o3ouo4yip-linux-kernel-bugs) wrote on 2023-02-07:

#123

Hello. I am still experiencing this bug on 6.1. Could you reopen this bug, so we will be able to solve it?

Ubuntu
linux package

Fan stops after resume from suspend leading to overheating; requires reboot to fix [HP Probook 4710s and many others]

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	Ubuntu	Expired	High	linux-kernel-bugs #71711
	linux (Ubuntu)	Fix Released	Medium	Dhinak G

Ubuntulinux package

Fan stops after resume from suspend leading to overheating; requires reboot to fix [HP Probook 4710s and many others]

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
linux package