Bug 180338

Summary: 2.6.15, 2.6.16 on Athlon XP CPU runs hot: blocks s2k disconnect power saving
Product: [Fedora] Fedora Reporter: Dave Jenkins <iamaluddite>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-24 17:47:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Jenkins 2006-02-07 13:27:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7

Description of problem:
My Athlon XP runs approx 15 degrees C hotter at idle with 2.6.15-1.1830 than with 2.6.14-1.1656 or any previous kernel I've tried. It seems that 2.6.15-1.1830 does not allow the CPU to enter s2k disconnect power saving mode.

Hardware: Athlon XP 2600+ Barton, MSI KM4M-L motherboard (Via KM400).
BIOS provides CPU Disconnect Control:
"The item is to reduce the power consumption of the AMD K7 system. When set to Enabled, the processor is allowed to disconnect the s2k interface when the AMD K7 system is in some power saving states."

CPU temperatures with BIOS CPU Disconnect enabled versus disabled, for 2.6.14-1.1656 versus 2.6.15-1.1830 (I'm using a low-speed CPU fan, so the temp differences are larger than they might be):

Kernel      CPU Disconnect      CPU idle temp, degrees C
2.6.14      enabled             35.5
2.6.14      disabled            46
2.6.15      enabled             49.5
2.6.15      disabled            49.5

I conclude that the higher temps with 2.6.15 are due to the s2k disconnect not operating with this kernel.

I have tried to track down the culprit by booting into runlevel 1, then removing all unused modules, just leaving those required for lm_sensors so that I can check the CPU temp. This is the smallest set of modules I got down to:

Module                  Size  Used by
w83627hf               24017  0
hwmon_vid               2753  1 w83627hf
hwmon                   3269  1 w83627hf
i2c_isa                 5185  1 w83627hf
i2c_core               21697  2 w83627hf,i2c_isa
ext3                  129993  8
jbd                    57941  1 ext3
dm_mod                 56665  9

(w83627hf is the module for the Winbond chip queried by lm_sensors).
With just these modules loaded, in runlevel 1 with the system idling, the s2k disconnect still does not occur with 2.6.15 . Whereas in 2.6.14, it occurs quite happily in every runlevel I've tried, even with 50+ kernel modules loaded - the only exception being after attaching a USB storage device, as described in bug 172592.

Version-Release number of selected component (if applicable):
kernel-2.6.15-1.1830_FC4

How reproducible:
Always

Steps to Reproduce:
1. Enable CPU Disconnect in BIOS.
2. Note CPU idle temperature.
  

Actual Results:  With 2.6.15, idle temperature is the same as with CPU Disconnect disabled in BIOS.

Expected Results:  Idle temperature should be significantly lower than with CPU Disconnect disabled in BIOS, i.e. behaviour should be as with 2.6.14 .

Additional info:

Comment 1 Dave Jenkins 2006-03-04 10:15:17 UTC
Still broken in kernel-2.6.15-1.1833_FC4.

Comment 2 Dave Jenkins 2006-03-30 13:19:26 UTC
Also broken in kernel-2.6.16-1.2069_FC4.

Comment 3 Dave Jenkins 2006-04-21 10:20:19 UTC
Remains broken in kernel-2.6.16-1.2096_FC4.

Comment 4 Dave Jenkins 2006-05-08 17:41:25 UTC
Brokenness persists in kernel-2.6.16-1.2107_FC4 and kernel-2.6.16-1.2108_FC4.
The problem also occurs with kernel.org 2.6.16.14 so it's not specific to Fedora
patches or configuration. In view of this and the silence here, I suppose I'd
better take this upstream.

Comment 5 Dave Jenkins 2006-05-24 17:47:45 UTC
It turns out that this isn't a bug, it's a bug-fixing from 2.16.14 to 2.16.15
that  exposed a misconfiguration on my PC. Briefly, in 2.6.14 ACPI power-saving
was operating when it shouldn't have been. In 2.6.15 this was fixed, exposing
the fact that HLT power-saving was not operating.