[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #2 from rjwysocki@sisk.pl  2007-08-08 10:11 -------
Does the issue remain in the newest kernels (eg. 2.6.23-rc2)?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #3 from rjwysocki@sisk.pl  2007-09-23 05:26 -------
There are some important fixes related to ACPI/suspend in the current Linus'
tree (2.6.23-rc7-git4 as of today).  Can you test it please?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #4 from rjwysocki@sisk.pl  2007-10-06 08:38 -------
Please test the 2.6.23-rc9 kernel or 2.6.23 final when it's out.

[I'm going to close this entry if there's no response in two weeks from now.]


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #5 from eo@nebensachen.de  2007-10-08 06:47 -------
[Sorry for the delay.]

There still are some issues. On 2.6.22 and 2.6.23-rc9-git6 I see this
behaviour:

Driver: acpi-cpufreq
Governor: conservative

When issuing
echo mem > /sys/power/state
and resuming afterwards, /proc/cpuinfo reports maximum frequency. It
stays that way during normal operation until a more demanding process
is being launched. For instance when starting to compile the kernel,
the cpu is switched to the but lowest frequency (after some threshold,
of course) and behaves as expected from now on. So, there are two odd
things:
1. cpu stays at highest frequency after a suspend/resume cycle;
2. once there is enough load to trigger a frequency switching event,
   the switching algorithm behaves as if the cpu had been at the
   lowest frequency all the time, i.e., it steps through all the
   possible frequencies starting at the low end of the scale.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #6 from rjwysocki@sisk.pl  2007-10-12 12:48 -------
Well, I'm not familiar with the cpufreq code.  I'll try to have a look at it,
though (I can't promise that will be soon).


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Comment #7 from eo@nebensachen.de  2007-10-21 06:13 -------
Created an attachment (id=13218)
 --> (http://bugzilla.kernel.org/attachment.cgi?id=13218&action=view)
Applies to 2.6.23.1

Please apply the attached patch. Since it is a small one, I think it
should go to the stable team as well.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581


davej@codemonkey.org.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|cpufreq@www.linux.org.uk    |davej@codemonkey.org.uk
             Status|NEW                         |ASSIGNED




------- Comment #8 from davej@codemonkey.org.uk  2007-10-21 17:24 -------
there's some whitespace damage in this patch (spaces instead of tabs).
Asides from that though, it looks like the right thing to do.
Can you fix that up, and bounce a copy to cpufreq@www.linux.org.uk please?

Thanks.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.

Re: [Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[Elias Oltmanns]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8581
>
>
> davej@codemonkey.org.uk changed:
[...]
> ------- Comment #8 from davej@codemonkey.org.uk  2007-10-21 17:24 -------
> there's some whitespace damage in this patch (spaces instead of tabs).
> Asides from that though, it looks like the right thing to do.
> Can you fix that up, and bounce a copy to cpufreq@www.linux.org.uk please?

Well, since this patch was mainly a copy-and-paste job from
cpufreq_userspace.c, the whitespace damages have been inherited once. In
fact, I have stumbled upon some more whitespace issues in in the cpufreq
subsystem and there are also some problems with lacking whitespace
causing misprinted debugging messages. If you're interested, I can come
up with a patch fixing all those problems I've accidentally come across.

Here is the patch fixing cpufreq_conservative.c anyway. It applies to
2.6.23.

Regards,

Elias

--------

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: conservative-handle-resume-2.patch --]
[-- Type: text/x-patch, Size: 2115 bytes --]

Make cpufreq_conservative handle out-of-sync events properly

Currently, the cpufreq_conservative governor doesn't get notified when the
actual frequency the cpu is running at differs from what cpufreq thought it
was. As a result the cpu may stay at the maximum frequency after a s2ram /
resume cycle even though the system is idle.

Signed-off-by: Elias Oltmanns <eo@nebensachen.de>
---

 drivers/cpufreq/cpufreq_conservative.c |   32 ++++++++++++++++++++++++++++++--
 1 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
index 26f440c..7ad91d2 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -116,6 +116,27 @@ static inline unsigned int get_cpu_idle_
 	return ret;
 }
 
+/* keep track of frequency transitions */
+static int
+dbs_cpufreq_notifier(struct notifier_block *nb, unsigned long val,
+		     void *data)
+{
+	struct cpufreq_freqs *freq = data;
+	struct cpu_dbs_info_s *this_dbs_info = &per_cpu(cpu_dbs_info,
+							freq->cpu);
+
+	if (!this_dbs_info->enable)
+		return 0;
+
+	this_dbs_info->requested_freq = freq->new;
+
+	return 0;
+}
+
+static struct notifier_block dbs_cpufreq_notifier_block = {
+	.notifier_call = dbs_cpufreq_notifier
+};
+
 /************************** sysfs interface ************************/
 static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
 {
@@ -514,6 +535,9 @@ static int cpufreq_governor_dbs(struct c
 			dbs_tuners_ins.sampling_rate = def_sampling_rate;
 
 			dbs_timer_init();
+			cpufreq_register_notifier(
+					&dbs_cpufreq_notifier_block,
+					CPUFREQ_TRANSITION_NOTIFIER);
 		}
 		
 		mutex_unlock(&dbs_mutex);
@@ -528,9 +552,13 @@ static int cpufreq_governor_dbs(struct c
 		 * Stop the timerschedule work, when this governor
 		 * is used for first time
 		 */
-		if (dbs_enable == 0) 
+		if (dbs_enable == 0) {
 			dbs_timer_exit();
-		
+			cpufreq_unregister_notifier(
+					&dbs_cpufreq_notifier_block,
+					CPUFREQ_TRANSITION_NOTIFIER);
+		}
+
 		mutex_unlock(&dbs_mutex);
 
 		break;

[-- Attachment #3: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

Re: [Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[Dave Jones]

On Mon, Oct 22, 2007 at 09:50:13AM +0200, Elias Oltmanns wrote:

 > > there's some whitespace damage in this patch (spaces instead of tabs).
 > > Asides from that though, it looks like the right thing to do.
 > > Can you fix that up, and bounce a copy to cpufreq@www.linux.org.uk please?
 > 
 > Well, since this patch was mainly a copy-and-paste job from
 > cpufreq_userspace.c, the whitespace damages have been inherited once. In
 > fact, I have stumbled upon some more whitespace issues in in the cpufreq
 > subsystem and there are also some problems with lacking whitespace
 > causing misprinted debugging messages. If you're interested, I can come
 > up with a patch fixing all those problems I've accidentally come across.

Yeah, it does seem to be a bit of a disaster.  I've just removed some
of the more obvious whitespace damage in cpufreq.git.  If you spot
any others after that, patches gratefully accepted.

 > Here is the patch fixing cpufreq_conservative.c anyway. It applies to
 > 2.6.23.

Applied, thanks Elias.

	Dave

-- 
http://www.codemonkey.org.uk

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581

rjwysocki@sisk.pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |7216
              nThis|                            |



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 8581] acpi-cpufreq gets very confused on suspend to ram

[bugme-daemon]

http://bugzilla.kernel.org/show_bug.cgi?id=8581





------- Additional Comments From eo@nebensachen.de  2007-06-04 05:41 -------
Just for the record, speedstep-centrino which I've been using until
now still works as expected. In my configuration its switching the
cpufreq driver that triggers the problem. And there is another
difference although it might be known and considered a limitation
rather than a bug: Whereas the speedstep-centrino module apparently
can be unloaded during normal operation, the same does not apply to
acpi-cpufreq as the module is claimed to be in use even after
switching to the performance governor and setting everything to the
startup defaults.

Regards,

Elias

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.