3.13.?: Strange / dangerous fan policy...

Please have a short look at the following BUG report + the comments -- this message here is a kind of FWD-ing it:
https://bugs.archlinux.org/task/39005

I came late to test kernel 3.13 with the .5 one, as it was the time that the related -CK/BFS patch became available.

I'm not using Archlinux, but openSUSE, and my problems are quite the same. Especially these with smelling melting plastics.

My own reports went to Con Kolivas' Blog first:
"I get weird temperatures and abrupt 100% fan actions with vanilla 3.13.5 with this CK and most recent BFQ at my HP Notebook. In gkrellm the highest T had been @74°C, so far (3.12.13), and is now growing to 94°C. Then, the fan goes to 100% for 10~30secs cooling it to approx. 82°C.
That is not good, if I compare 74 to 94 °C.
Have I missed a .CONFIG option for 3.13, especially?"

I'd get the same without (Con's && BFQ's) patches.

Machine:           HP Notebook with Core2Duo CPU (Penryn)
Distro:            openSUSE 13.1, 64bit, continuously updated
Desktop:           KDE 4.12.3

MESA & drm & Xorg: most recent ones from:
http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_13.1/x86_64/

Current kernel: 3.13.6 vanilla from openSUSE repos, with
-ck1 and BFQ patches
Same behaviour: without these patches

Last good kernel: 3.12.13 vanilla + CK2 + BFQ

Quoted 24 lines · Manuel Krause

Please have a short look at the following BUG report + the comments -- this message here is a kind of FWD-ing it:
https://bugs.archlinux.org/task/39005

I came late to test kernel 3.13 with the .5 one, as it was the time that the related -CK/BFS patch became available.

I'm not using Archlinux, but openSUSE, and my problems are quite the same. Especially these with smelling melting plastics.

My own reports went to Con Kolivas' Blog first:
"I get weird temperatures and abrupt 100% fan actions with vanilla 3.13.5 with this CK and most recent BFQ at my HP Notebook. In gkrellm the highest T had been @74°C, so far (3.12.13), and is now growing to 94°C. Then, the fan goes to 100% for 10~30secs cooling it to approx. 82°C.
That is not good, if I compare 74 to 94 °C.
Have I missed a .CONFIG option for 3.13, especially?"

I'd get the same without (Con's && BFQ's) patches.

Machine:           HP Notebook with Core2Duo CPU (Penryn)
Distro:            openSUSE 13.1, 64bit, continuously updated
Desktop:           KDE 4.12.3

Quoted 9 lines

MESA & drm & Xorg: most recent ones from:
http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_13.1/x86_64/

Current kernel: 3.13.6 vanilla from openSUSE repos, with
-ck1 and BFQ patches
Same behaviour: without these patches

Last good kernel: 3.12.13 vanilla + CK2 + BFQ

Can you add more information about your fan control policy ? Do you rely on the hardware for automatic fan speed control, or do you run the fancontrol script ?

What is the output from the 'sensors' command ?

Thanks,
Guenter

Quoted 35 lines · Guenter Roeck

Quoted 24 lines · Manuel Krause

Please have a short look at the following BUG report + the comments -- this message here is a kind of FWD-ing it:
https://bugs.archlinux.org/task/39005

I came late to test kernel 3.13 with the .5 one, as it was the time that the related -CK/BFS patch became available.

I'm not using Archlinux, but openSUSE, and my problems are quite the same. Especially these with smelling melting plastics.

My own reports went to Con Kolivas' Blog first:
"I get weird temperatures and abrupt 100% fan actions with vanilla 3.13.5 with this CK and most recent BFQ at my HP Notebook. In gkrellm the highest T had been @74°C, so far (3.12.13), and is now growing to 94°C. Then, the fan goes to 100% for 10~30secs cooling it to approx. 82°C.
That is not good, if I compare 74 to 94 °C.
Have I missed a .CONFIG option for 3.13, especially?"

I'd get the same without (Con's && BFQ's) patches.

Machine:           HP Notebook with Core2Duo CPU (Penryn)
Distro:            openSUSE 13.1, 64bit, continuously updated
Desktop:           KDE 4.12.3

Quoted 9 lines

MESA & drm & Xorg: most recent ones from:
http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_13.1/x86_64/

Current kernel: 3.13.6 vanilla from openSUSE repos, with
-ck1 and BFQ patches
Same behaviour: without these patches

Last good kernel: 3.12.13 vanilla + CK2 + BFQ

Quoted 9 lines

Can you add more information about your fan control policy ? Do you rely on the hardware for automatic fan speed control, or do you run the fancontrol script ?

What is the output from the 'sensors' command ?

Thanks,
Guenter

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.

But I'd do to test any improvement-patch.

Quoted 23 lines · Manuel Krause

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.

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 24 lines · Guenter Roeck

Quoted 23 lines · Manuel Krause

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 5 lines

Quoted 1 line

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.

A bisection would certainly help, but of course that would require booting to a bad kernel half of the time, which I understand Manual wouldn't enjoy.

The only two components which I think can reach such high temperatures in a laptop are the CPU and the GPU. I suppose that the "94 °C vs. 74°C" refers to acpitz's temp1? If the the temperatures reported by coretemp remain the same, then I can only suppose that temp1 is the GPU temperature. Please tell us which GPU is in this laptop, and which driver you're using.

Quoted 24 lines · Guenter Roeck

Quoted 23 lines · Manuel Krause

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 2 lines

Quoted 1 line

But I'd do to test any improvement-patch.

Quoted 3 lines

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.

Quoted 46 lines · Jean Delvare

Quoted 26 lines · Guenter Roeck

Quoted 25 lines · Manuel Krause

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

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

Quoted 64 lines · Guenter Roeck

Quoted 46 lines · Jean Delvare

Quoted 26 lines · Guenter Roeck

Quoted 25 lines · Manuel Krause

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 64 lines · Guenter Roeck

Quoted 46 lines · Jean Delvare

Quoted 26 lines · Guenter Roeck

Quoted 25 lines · Manuel Krause

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 119 lines · Manuel Krause

Quoted 64 lines · Guenter Roeck

Quoted 46 lines · Jean Delvare

Quoted 26 lines · Guenter Roeck

Quoted 25 lines · Manuel Krause

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

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

Quoted 143 lines · Rafael J. Wysocki

Quoted 134 lines · Manuel Krause

Quoted 71 lines · Guenter Roeck

Quoted 48 lines · Jean Delvare

Quoted 27 lines · Guenter Roeck

Quoted 26 lines · Manuel Krause

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.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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

This almost certainly is an ACPI regression, but I'm not sure whether
thermal management or CPU power management is broken on your system.

Quoted 6 lines

Can you compare the contents of /sys/class/thermal/ from working and
not working kernels, please?

Rafael

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 #

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:

[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

Quoted 45 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:

[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.

Quoted 6 lines

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

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?idq711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Quoted 54 lines · Manuel Krause

Quoted 46 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?idq711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system) can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything wrong.
I guess everyone else is just as clueless as I am (if not, speak up and help ;-).

Guenter

Quoted 73 lines · Guenter Roeck

Quoted 54 lines · Manuel Krause

Quoted 46 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?id=71711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system) can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything wrong.
I guess everyone else is just as clueless as I am (if not, speak up and help ;-).

Quoted 2 lines

Guenter

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

ACPI / AC: convert ACPI ac driver to platform bus

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

: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

Quoted 76 lines · Manuel Krause

Quoted 75 lines · Guenter Roeck

Quoted 55 lines · Manuel Krause

Quoted 47 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause wrote:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?id=71711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system) can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 7 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

Quoted 5 lines

ACPI / AC: convert ACPI ac driver to platform bus

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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

Quoted 97 lines · Guenter Roeck

Quoted 76 lines · Manuel Krause

Quoted 75 lines · Guenter Roeck

Quoted 55 lines · Manuel Krause

Quoted 47 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

Quoted 2 lines · Guenter Roeck

On Fri, Mar 07, 2014 at 11:04:29PM +0100, Manuel Krause
wrote:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?id=71711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system) can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 7 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

Quoted 22 lines

Quoted 5 lines

ACPI / AC: convert ACPI ac driver to platform bus

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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

Sorry, that I've forgotton to add the following last night: After the first bisection round, I was so glad about a result that time, that I reverted this mentioned patch from the 3.13.8 kernel, but this didn't fix it.

Quoted 121 lines · Manuel Krause

Quoted 97 lines · Guenter Roeck

Quoted 76 lines · Manuel Krause

Quoted 75 lines · Guenter Roeck

Quoted 55 lines · Manuel Krause

Quoted 47 lines · Manuel Krause

Quoted 8 lines · Manuel Krause

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Rafael J. Wysocki

Quoted 5 lines · Manuel Krause

Quoted 4 lines · Guenter Roeck

Quoted 3 lines · Jean Delvare

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:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?id=71711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system) can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 7 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

Quoted 22 lines

Quoted 5 lines

ACPI / AC: convert ACPI ac driver to platform bus

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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

Quoted 4 lines

Sorry, that I've forgotton to add the following last night: After the first bisection round, I was so glad about a result that time, that I reverted this mentioned patch from the 3.13.8 kernel, but this didn't fix it.

This means that the commit in question didn't introduce the problem you're seeing.

Please check out commit 7f2dc5c4bcbf (Merge tag 'dm-3.13-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm),
build a kernel from that and see if you can reprocude the problem with it.
If so, it can be used as your new "first known bad" kernel for bisection.
Otherwise, you can use it as the "first good" one and commit cc8ef52707341
as "first known bad".

Thanks!

Quoted 6 lines

Quoted 6 lines

O.k. I've now followed your latest directions:
git checkout -b testing cc8ef52707341e67a12067d6ead991d56ea017ca => result after rebuild was BAD =>
git revert cc8ef52707341e67a12067d6ead991d56ea017ca
=> result after rebuild was GOOD

Quoted 2 lines

Quoted 2 lines

Reverting that commit in question from this very git tree makes the kernel work as expected.

Quoted 3 lines

Report the results you have above. That should show without question that cc8ef52707341e67a12067d6ead991d56ea017ca is the bad commit, and it should be easy to reproduce.

Quoted 156 lines · Rafael J. Wysocki

Quoted 134 lines · Manuel Krause

Quoted 111 lines · Guenter Roeck

Quoted 85 lines · Manuel Krause

Quoted 84 lines · Guenter Roeck

Quoted 62 lines · Manuel Krause

Quoted 54 lines · Manuel Krause

Quoted 11 lines · Manuel Krause

Quoted 10 lines · Manuel Krause

Quoted 9 lines · Rafael J. Wysocki

Quoted 7 lines · Manuel Krause

Quoted 6 lines · Guenter Roeck

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:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?idq711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system)
can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything
wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad
commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 10 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

ACPI / AC: convert ACPI ac driver to platform bus

Quoted 21 lines

Quoted 4 lines

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki

<[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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?idq711

Manuel Krause

Quoted 4 lines

Sorry, that I've forgotton to add the following last night: After the first bisection round, I was so glad about a result that time, that I reverted this mentioned patch from the 3.13.8 kernel, but this didn't fix it.

This means that the commit in question didn't introduce the problem
you're seeing.

Please check out commit 7f2dc5c4bcbf (Merge tag
'dm-3.13-changes' of
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm),

build a kernel from that and see if you can reprocude the problem with it.
If so, it can be used as your new "first known bad" kernel for bisection.
Otherwise, you can use it as the "first good" one and commit cc8ef52707341
as "first known bad".

Quoted 2 lines

Thanks!

Sorry, for any inconvenience, but you should forget about what I've written, that reverting the patch in question from 3.13.x didn't fix it. Of course it didn't fix it, as the patch doesn't cleanly revert from release-kernels at all. My mistake!

I' ve been guided by Guenter Roeck through two more bisecting sessions/ways on this, that always pointed to the commit in question.

Some citation:
Me:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

O.k. I've now followed your latest directions:
git checkout -b testing cc8ef52707341e67a12067d6ead991d56ea017ca => result after rebuild was BAD =>
git revert cc8ef52707341e67a12067d6ead991d56ea017ca
=> result after rebuild was GOOD

[ ...]

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Reverting that commit in question from this very git tree makes the
kernel work as expected.

[ ... ]
Guenter:

Quoted 4 lines

Quoted 4 lines

Report the results you have above. That should show without question
that cc8ef52707341e67a12067d6ead991d56ea017ca is the bad commit, and it should be easy to reproduce.

That seems to be all I can do for you for now. Please let me know of any preliminary patches to test!
And I want to add special thanks to Guenter Roeck for his always-just-in-time assistance over so many days,

Manuel Krause

Quoted 193 lines · Manuel Krause

Quoted 156 lines · Rafael J. Wysocki

Quoted 134 lines · Manuel Krause

Quoted 111 lines · Guenter Roeck

Quoted 85 lines · Manuel Krause

Quoted 84 lines · Guenter Roeck

Quoted 62 lines · Manuel Krause

Quoted 54 lines · Manuel Krause

Quoted 11 lines · Manuel Krause

Quoted 10 lines · Manuel Krause

Quoted 9 lines · Rafael J. Wysocki

Quoted 7 lines · Manuel Krause

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:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?idq711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system)
can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything
wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad
commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 10 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

ACPI / AC: convert ACPI ac driver to platform bus

Quoted 21 lines

Quoted 4 lines

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki

<[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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?idq711

Manuel Krause

Quoted 4 lines

Sorry, that I've forgotton to add the following last night: After the first bisection round, I was so glad about a result that time, that I reverted this mentioned patch from the 3.13.8 kernel, but this didn't fix it.

This means that the commit in question didn't introduce the problem
you're seeing.

Please check out commit 7f2dc5c4bcbf (Merge tag
'dm-3.13-changes' of
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm),

build a kernel from that and see if you can reprocude the problem with it.
If so, it can be used as your new "first known bad" kernel for bisection.
Otherwise, you can use it as the "first good" one and commit cc8ef52707341
as "first known bad".

Quoted 2 lines

Thanks!

Sorry, for any inconvenience, but you should forget about what I've written, that reverting the patch in question from 3.13.x didn't fix it. Of course it didn't fix it, as the patch doesn't cleanly revert from release-kernels at all. My mistake!

I' ve been guided by Guenter Roeck through two more bisecting sessions/ways on this, that always pointed to the commit in question.

Some citation:
Me:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

O.k. I've now followed your latest directions:
git checkout -b testing cc8ef52707341e67a12067d6ead991d56ea017ca => result after rebuild was BAD =>
git revert cc8ef52707341e67a12067d6ead991d56ea017ca
=> result after rebuild was GOOD

[ ...]

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Reverting that commit in question from this very git tree makes the
kernel work as expected.

[ ... ]
Guenter:

Quoted 4 lines

Quoted 4 lines

Report the results you have above. That should show without question
that cc8ef52707341e67a12067d6ead991d56ea017ca is the bad commit, and it should be easy to reproduce.

That seems to be all I can do for you for now. Please let me know of any preliminary patches to test!
And I want to add special thanks to Guenter Roeck for his always-just-in-time assistance over so many days,

Quoted 2 lines

Manuel Krause

BTW -- applying this patch in question to a 3.12.17 kernel, that worked optimal WITHOUT it, makes it FAIL as described for 3.13.x kernels. (And, yes, the patch applied cleanly, compiled fine and boots nicely.)

Manuel Krause

Quoted 194 lines · Manuel Krause

Quoted 193 lines · Manuel Krause

Quoted 156 lines · Rafael J. Wysocki

Quoted 134 lines · Manuel Krause

Quoted 111 lines · Guenter Roeck

Quoted 85 lines · Manuel Krause

Quoted 84 lines · Guenter Roeck

Quoted 62 lines · Manuel Krause

Quoted 54 lines · Manuel Krause

Quoted 11 lines · Manuel Krause

Quoted 10 lines · Manuel Krause

Quoted 9 lines · Rafael J. Wysocki

On Sunday, March 09, 2014 01:10:25 AM Manuel Krause
wrote:
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:

[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.

Quoted 6 lines

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

Quoted 7 lines

This is still BUG 71711
https://bugzilla.kernel.org/show_bug.cgi?idq711

3.12.15 works very well
3.13.7 fails
3.14.0-rc8 fails

Best you can do would really be to bisect the problem. Unfortunately only you (or someone else with an affected system)
can do that. Once the culprit is known it would be much easier to get it fixed.

To answer your earlier question: I don't think you did anything
wrong.
I guess everyone else is just as clueless as I am (if not, speak up
and help ;-).

Quoted 8 lines

Quoted 2 lines

Guenter

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.

Not really. Keep in mint that you were able to track down the bad
commit
among more than 10,000 commits in a reasonably short period of time.

Quoted 10 lines

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 protected]>
Date:   Wed Sep 25 20:39:45 2013 +0800

ACPI / AC: convert ACPI ac driver to platform bus

Quoted 21 lines

Quoted 4 lines

Signed-off-by Zhang Rui <[email protected]>

Signed-off-by Rafael J. Wysocki

<[email protected]>

Off to the two of you...

Guenter

Quoted 12 lines

: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?idq711

Manuel Krause

Quoted 4 lines

Sorry, that I've forgotton to add the following last night: After the first bisection round, I was so glad about a result that time, that I reverted this mentioned patch from the 3.13.8 kernel, but this didn't fix it.

This means that the commit in question didn't introduce the problem
you're seeing.

Please check out commit 7f2dc5c4bcbf (Merge tag
'dm-3.13-changes' of
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm),

build a kernel from that and see if you can reprocude the problem with it.
If so, it can be used as your new "first known bad" kernel for bisection.
Otherwise, you can use it as the "first good" one and commit cc8ef52707341
as "first known bad".

Quoted 2 lines

Thanks!

Sorry, for any inconvenience, but you should forget about what I've written, that reverting the patch in question from 3.13.x didn't fix it. Of course it didn't fix it, as the patch doesn't cleanly revert from release-kernels at all. My mistake!

I' ve been guided by Guenter Roeck through two more bisecting sessions/ways on this, that always pointed to the commit in question.

Some citation:
Me:

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

O.k. I've now followed your latest directions:
git checkout -b testing cc8ef52707341e67a12067d6ead991d56ea017ca => result after rebuild was BAD =>
git revert cc8ef52707341e67a12067d6ead991d56ea017ca
=> result after rebuild was GOOD

[ ...]

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Reverting that commit in question from this very git tree makes the
kernel work as expected.

[ ... ]
Guenter:

Quoted 4 lines

Quoted 4 lines

Report the results you have above. That should show without question
that cc8ef52707341e67a12067d6ead991d56ea017ca is the bad commit, and it should be easy to reproduce.

That seems to be all I can do for you for now. Please let me know of any preliminary patches to test!
And I want to add special thanks to Guenter Roeck for his always-just-in-time assistance over so many days,

Quoted 8 lines

Quoted 2 lines

Manuel Krause

BTW -- applying this patch in question to a 3.12.17 kernel, that worked optimal WITHOUT it, makes it FAIL as described for 3.13.x kernels. (And, yes, the patch applied cleanly, compiled fine and boots nicely.)

could you please apply commit 50a2bc5429f07ec4d53df2d287b03bdbceb281bb on top of commit cc8ef52707341e67a12067d6ead991d56ea017ca and check if the problem still exist in 3.12.17 kernel?

thanks,
rui