cpufreq problem wrt suspend/resume on Athlon64

cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

Hi,

I have noticed that the condition (cur_freq != cpu_policy->cur), which is
unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
on my box (Athlon64-based Asus).  Every time the box resumes, I get a message
like that:

Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 1800000 kHz.

(the numbers vary: there may be 800000 vs 1600000 or even 800000 vs 1800000).

Also, when the box is suspended on AC power and resumed on batteries, it often
reboots.

Please let me know if there's anything (relatively simple :-)) that I can do
about it.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> on my box (Athlon64-based Asus).  Every time the box resumes, I get a message
> like that:
> 
> Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 1800000 kHz.
> 
> (the numbers vary: there may be 800000 vs 1600000 or even 800000 vs 1800000).
> 
> Also, when the box is suspended on AC power and resumed on batteries, it often
> reboots.
> 
> Please let me know if there's anything (relatively simple :-)) that I can do
> about it.

Introduce _suspend() routine to cpufreq, and force cpu to 800MHz
during suspend(). Put it back to right frequency during resume().

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Wednesday, 2 of February 2005 14:31, Pavel Machek wrote:
> Hi!
> 
> > I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> > unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> > on my box (Athlon64-based Asus).  Every time the box resumes, I get a message
> > like that:
> > 
> > Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 1800000 kHz.
> > 
> > (the numbers vary: there may be 800000 vs 1600000 or even 800000 vs 1800000).
> > 
> > Also, when the box is suspended on AC power and resumed on batteries, it often
> > reboots.
> > 
> > Please let me know if there's anything (relatively simple :-)) that I can do
> > about it.
> 
> Introduce _suspend() routine to cpufreq, and force cpu to 800MHz
> during suspend().

Do you mean like that:

--- linux-2.6.11-rc2-orig/drivers/cpufreq/cpufreq.c	2005-01-30 23:30:53.000000000 +0100
+++ linux-2.6.11-rc2/drivers/cpufreq/cpufreq.c	2005-02-03 00:50:05.000000000 +0100
@@ -939,10 +939,42 @@
 	return ret;
 }
 
+static int cpufreq_suspend(struct sys_device * sysdev, u32 state)
+{
+	int cpu = sysdev->id;
+	struct cpufreq_policy *cpu_policy;
+
+	dprintk("suspending cpu %u\n", cpu);
+
+	if (!cpu_online(cpu))
+		return 0;
+
+	cpu_policy = cpufreq_cpu_get(cpu);
+	if (!cpu_policy)
+		return -EINVAL;
+
+	/* only handle each CPU group once */
+	if (unlikely(cpu_policy->cpu != cpu)) {
+		cpufreq_cpu_put(cpu_policy);
+		return 0;
+	}
+
+	if (cpufreq_driver->target) {
+		dprintk("cpufreq: trying to set CPU frequency to the minimal (%u kHz)\n", 
+				cpu_policy->min);
+		cpufreq_driver->target(cpu_policy, cpu_policy->min,
+			CPUFREQ_RELATION_L);
+	}
+
+	cpufreq_cpu_put(cpu_policy);
+	return 0;
+}
+	
 static struct sysdev_driver cpufreq_sysdev_driver = {
 	.add		= cpufreq_add_dev,
 	.remove		= cpufreq_remove_dev,
 	.resume		= cpufreq_resume,
+	.suspend	= cpufreq_suspend,
 };
 
 

> Put it back to right frequency during resume(). 

Well, I don't know which one is right, because the box might have been
suspended in different conditions (eg AC power vs batteries).  I think it's
better to leave it at the minimal frequency for a while.  Moreover, I don't
know if it's not necessary to force the minimal frequency again in resume()
(I imagine that some CPUs may change the frequency on the fly if they
are sufficiently loaded, and eg in swsusp we restore the image between
suspend() and resume(), so this may very well happen sometimes, it
seems).

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> > > I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> > > unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> > > on my box (Athlon64-based Asus).  Every time the box resumes, I get a message
> > > like that:
> > > 
> > > Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 1800000 kHz.
> > > 
> > > (the numbers vary: there may be 800000 vs 1600000 or even 800000 vs 1800000).
> > > 
> > > Also, when the box is suspended on AC power and resumed on batteries, it often
> > > reboots.
> > > 
> > > Please let me know if there's anything (relatively simple :-)) that I can do
> > > about it.
> > 
> > Introduce _suspend() routine to cpufreq, and force cpu to 800MHz
> > during suspend().
> 
> Do you mean like that:

Yes, this looks okay. Does it fix your "it reboots during resume" problem?

> --- linux-2.6.11-rc2-orig/drivers/cpufreq/cpufreq.c	2005-01-30 23:30:53.000000000 +0100
> +++ linux-2.6.11-rc2/drivers/cpufreq/cpufreq.c	2005-02-03 00:50:05.000000000 +0100
> @@ -939,10 +939,42 @@
>  	return ret;
>  }
>  
> +static int cpufreq_suspend(struct sys_device * sysdev, u32 state)
> +{
> +	int cpu = sysdev->id;
> +	struct cpufreq_policy *cpu_policy;
> +
> +	dprintk("suspending cpu %u\n", cpu);
> +
> +	if (!cpu_online(cpu))
> +		return 0;
> +
> +	cpu_policy = cpufreq_cpu_get(cpu);
> +	if (!cpu_policy)
> +		return -EINVAL;
> +
> +	/* only handle each CPU group once */
> +	if (unlikely(cpu_policy->cpu != cpu)) {
> +		cpufreq_cpu_put(cpu_policy);
> +		return 0;
> +	}
> +
> +	if (cpufreq_driver->target) {
> +		dprintk("cpufreq: trying to set CPU frequency to the minimal (%u kHz)\n", 
> +				cpu_policy->min);
> +		cpufreq_driver->target(cpu_policy, cpu_policy->min,
> +			CPUFREQ_RELATION_L);
> +	}
> +
> +	cpufreq_cpu_put(cpu_policy);
> +	return 0;
> +}
> +	
>  static struct sysdev_driver cpufreq_sysdev_driver = {
>  	.add		= cpufreq_add_dev,
>  	.remove		= cpufreq_remove_dev,
>  	.resume		= cpufreq_resume,
> +	.suspend	= cpufreq_suspend,
>  };
>  
>  
> 
> > Put it back to right frequency during resume(). 
> 
> Well, I don't know which one is right, because the box might have been
> suspended in different conditions (eg AC power vs batteries).  I think it's
> better to leave it at the minimal frequency for a while.  Moreover, I don't
> know if it's not necessary to force the minimal frequency again in resume()
> (I imagine that some CPUs may change the frequency on the fly if they
> are sufficiently loaded, and eg in swsusp we restore the image between
> suspend() and resume(), so this may very well happen sometimes, it
> seems).

Okay, you are right, restoring it unconditionaly would be bad
idea. Still it would be nice to tell cpufreq governor "please change
the frequency ASAP" so it does not run at 800MHz for half an hour
compiling kernels on AC power.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Dominik Brodowski]

Hi,

On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> Okay, you are right, restoring it unconditionaly would be bad
> idea. Still it would be nice to tell cpufreq governor "please change
> the frequency ASAP" so it does not run at 800MHz for half an hour
> compiling kernels on AC power.

It already does that... or at least it should. in cpufreq_resume() there is
a call to schedule_work(&cpu_policy->update); which will cause a call
cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
governor, and it is supposed to adjust the frequency to the user's wish
then.

	Dominik

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > Okay, you are right, restoring it unconditionaly would be bad
> > idea. Still it would be nice to tell cpufreq governor "please change
> > the frequency ASAP" so it does not run at 800MHz for half an hour
> > compiling kernels on AC power.
> 
> It already does that... or at least it should. in cpufreq_resume() there is
> a call to schedule_work(&cpu_policy->update); which will cause a call
> cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> governor, and it is supposed to adjust the frequency to the user's wish
> then.

Ok, so Rafael's suspend() routine seems like good fix... Please
apply...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Dominik Brodowski]

On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> Hi!
> 
> > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > Okay, you are right, restoring it unconditionaly would be bad
> > > idea. Still it would be nice to tell cpufreq governor "please change
> > > the frequency ASAP" so it does not run at 800MHz for half an hour
> > > compiling kernels on AC power.
> > 
> > It already does that... or at least it should. in cpufreq_resume() there is
> > a call to schedule_work(&cpu_policy->update); which will cause a call
> > cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> > governor, and it is supposed to adjust the frequency to the user's wish
> > then.
> 
> Ok, so Rafael's suspend() routine seems like good fix...

No. I don't see a reason why my desktop P4 should drop to 12.5 frequency
(p4-clockmod) if I ask it to suspend to mem.

	Dominik

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Thursday, 3 of February 2005 12:01, Dominik Brodowski wrote:
> On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > idea. Still it would be nice to tell cpufreq governor "please change
> > > > the frequency ASAP" so it does not run at 800MHz for half an hour
> > > > compiling kernels on AC power.
> > > 
> > > It already does that... or at least it should. in cpufreq_resume() there is
> > > a call to schedule_work(&cpu_policy->update); which will cause a call
> > > cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> > > governor, and it is supposed to adjust the frequency to the user's wish
> > > then.
> > 
> > Ok, so Rafael's suspend() routine seems like good fix...
> 
> No. I don't see a reason why my desktop P4 should drop to 12.5 frequency
> (p4-clockmod) if I ask it to suspend to mem.

So, would it be acceptable to check in _suspend() if the state is S4
and drop the frequency in that case or do nothing otherwise?

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Dominik Brodowski]

On Thu, Feb 03, 2005 at 12:30:19PM +0100, Rafael J. Wysocki wrote:
> On Thursday, 3 of February 2005 12:01, Dominik Brodowski wrote:
> > On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > idea. Still it would be nice to tell cpufreq governor "please change
> > > > > the frequency ASAP" so it does not run at 800MHz for half an hour
> > > > > compiling kernels on AC power.
> > > > 
> > > > It already does that... or at least it should. in cpufreq_resume() there is
> > > > a call to schedule_work(&cpu_policy->update); which will cause a call
> > > > cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> > > > governor, and it is supposed to adjust the frequency to the user's wish
> > > > then.
> > > 
> > > Ok, so Rafael's suspend() routine seems like good fix...
> > 
> > No. I don't see a reason why my desktop P4 should drop to 12.5 frequency
> > (p4-clockmod) if I ask it to suspend to mem.
> 
> So, would it be acceptable to check in _suspend() if the state is S4
> and drop the frequency in that case or do nothing otherwise?

No. The point is that this is _very_ system-specific. Some systems resume
always at full speed, some always at low speed; for S4 the behaviour may be
completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
seems to be the best thing to me. The good thing is, after all, that cpufreq
detected this situation and tries to correct for it.

	Dominik

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Thursday, 3 of February 2005 13:40, Dominik Brodowski wrote:
[-- snip --]
> > So, would it be acceptable to check in _suspend() if the state is S4
> > and drop the frequency in that case or do nothing otherwise?
> 
> No. The point is that this is _very_ system-specific. Some systems resume
> always at full speed, some always at low speed; for S4 the behaviour may be
> completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> seems to be the best thing to me. The good thing is, after all, that cpufreq
> detected this situation and tries to correct for it.

Well, the warning is not a big problem, as far as I'm concerned.  The problem is
that the box often reboots when it's woken up on batteries and this certainly
is related to cpufreq (ie it does not happen if cpufreq is not compiled in).

Pavel has suggested that it may happen when the frequency of
the CPU is too high on resume, so I'm trying to verify if this is the case.  If so,
which I'm not entirely convinced about yet, I'll be going to provide a fix
for it, but I wouldn't like to do anything that's not acceptable from the
start.

I'm currently thinking that the proper approach may be to add a ->suspend()
routine to struct cpufreq_driver and call the driver-specific ->suspend()
(if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
whatever-is-necessary on a per-driver basis.  Just a thought. :-)

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> > > So, would it be acceptable to check in _suspend() if the state is S4
> > > and drop the frequency in that case or do nothing otherwise?
> > 
> > No. The point is that this is _very_ system-specific. Some systems resume
> > always at full speed, some always at low speed; for S4 the behaviour may be
> > completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> > 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> > seems to be the best thing to me. The good thing is, after all, that cpufreq
> > detected this situation and tries to correct for it.
> 
> Well, the warning is not a big problem, as far as I'm concerned.  The problem is
> that the box often reboots when it's woken up on batteries and this certainly
> is related to cpufreq (ie it does not happen if cpufreq is not compiled in).
> 
> Pavel has suggested that it may happen when the frequency of
> the CPU is too high on resume, so I'm trying to verify if this is the case.  If so,
> which I'm not entirely convinced about yet, I'll be going to provide a fix
> for it, but I wouldn't like to do anything that's not acceptable from the
> start.

Well, try to force your machine to 2GHz while it is on battery. If it
crashes, you have verified it is indeed the problem. [Insert standard
disclaimer about exploding batteries here.]

> I'm currently thinking that the proper approach may be to add a ->suspend()
> routine to struct cpufreq_driver and call the driver-specific ->suspend()
> (if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
> whatever-is-necessary on a per-driver basis.  Just a thought. :-)

Yes, that seems like right solution.
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
> Hi!
> 
> > > > So, would it be acceptable to check in _suspend() if the state is S4
> > > > and drop the frequency in that case or do nothing otherwise?
> > > 
> > > No. The point is that this is _very_ system-specific. Some systems resume
> > > always at full speed, some always at low speed; for S4 the behaviour may be
> > > completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> > > 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> > > seems to be the best thing to me. The good thing is, after all, that cpufreq
> > > detected this situation and tries to correct for it.
> > 
> > Well, the warning is not a big problem, as far as I'm concerned.  The problem is
> > that the box often reboots when it's woken up on batteries and this certainly
> > is related to cpufreq (ie it does not happen if cpufreq is not compiled in).
> > 
> > Pavel has suggested that it may happen when the frequency of
> > the CPU is too high on resume, so I'm trying to verify if this is the case.  If so,
> > which I'm not entirely convinced about yet, I'll be going to provide a fix
> > for it, but I wouldn't like to do anything that's not acceptable from the
> > start.
> 
> Well, try to force your machine to 2GHz while it is on battery. If it
> crashes, you have verified it is indeed the problem. [Insert standard
> disclaimer about exploding batteries here.]

Instead of trying to blow up the battery I used the patch that forces the CPU
to 800 MHz and it apparently survives resuming on batteries - at least 3
times out of 3 attempts (I'll try some times more tomorrow).

It seems to boot at 1800 MHz, though, every time, according to
cpufreq_resume().


> > I'm currently thinking that the proper approach may be to add a ->suspend()
> > routine to struct cpufreq_driver and call the driver-specific ->suspend()
> > (if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
> > whatever-is-necessary on a per-driver basis.  Just a thought. :-)
> 
> Yes, that seems like right solution.

Then I'll try to do something along this line.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Nigel Cunningham]

Hi.

On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> Instead of trying to blow up the battery I used the patch that forces the CPU
> to 800 MHz and it apparently survives resuming on batteries - at least 3
> times out of 3 attempts (I'll try some times more tomorrow).
> 
> It seems to boot at 1800 MHz, though, every time, according to
> cpufreq_resume().

Sounds like some good work. Is 800 the minimum for your laptop? I'm just
wondering how you know what speed to choose on other systems.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Friday, 4 of February 2005 00:34, Nigel Cunningham wrote:
> Hi.
> 
> On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> > Instead of trying to blow up the battery I used the patch that forces the CPU
> > to 800 MHz and it apparently survives resuming on batteries - at least 3
> > times out of 3 attempts (I'll try some times more tomorrow).
> > 
> > It seems to boot at 1800 MHz, though, every time, according to
> > cpufreq_resume().
> 
> Sounds like some good work. Is 800 the minimum for your laptop?

Yes, it is.

> I'm just wondering how you know what speed to choose on other systems.

Well, I don't know.  It seems that for k8-based CPUs the minimum is
a reasonable choice, but it apparently is not so for other processors.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64 [update]

[Rafael J. Wysocki]

Hi,

On Friday, 4 of February 2005 00:15, Rafael J. Wysocki wrote:
> On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
[-- snip --] 
> > > I'm currently thinking that the proper approach may be to add a ->suspend()
> > > routine to struct cpufreq_driver and call the driver-specific ->suspend()
> > > (if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
> > > whatever-is-necessary on a per-driver basis.  Just a thought. :-)
> > 
> > Yes, that seems like right solution.
> 
> Then I'll try to do something along this line.

Previously I had made a mistake and compiled the cpufreq drivers as modules
instead of compiling them directly into the kernel.  When I compiled cpufreq
in directly, it turned out that any such patches were not necessary, as the
warning about the differences in the CPU frequency went away.  Nonetheless,
I used such a patch in testing the resume/suspend behaviour when
resuming on either AC or battery power (this patch is available at:
http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/cpufreq-k8-suspend.patch).

The results of the testing are as follows:
1) When the cpufreq drivers are compiled directly into the kernel:
	a) the box resumes successfully if:
		i) it is on AC power during resume, or
		ii) it is started on AC power (ie bootloader starts on AC
		power) and disconnected from the AC before the kernel
		is loaded (!?)
	b) the box hangs solid as soon as the image is restored if it is
	started and the kernel is booted on battery power.
2) When the cpufreq drivers are not compiled into the kernel, the box reboots
on resume as soon as the image is restored.

The above results do not depend on whether the patch that forces the minimal
frequency of the CPU before suspend is used.

The results 1)a)ii) and 2) indicate that cpufreq is not to blame in this case,
so sorry for the noise here.

I think it is a BIOS-related issue and it seems to me that it's also related
to ACPI.  As the results 1)a)i) and 1)a)ii) are reproducible with probability
1, I'm going to investigate it a bit further, so if anyone on linux-acpi could
give me a hint on what to do next, I'd be grateful.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> > > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > > idea. Still it would be nice to tell cpufreq governor "please change
> > > > > > the frequency ASAP" so it does not run at 800MHz for half an hour
> > > > > > compiling kernels on AC power.
> > > > > 
> > > > > It already does that... or at least it should. in cpufreq_resume() there is
> > > > > a call to schedule_work(&cpu_policy->update); which will cause a call
> > > > > cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> > > > > governor, and it is supposed to adjust the frequency to the user's wish
> > > > > then.
> > > > 
> > > > Ok, so Rafael's suspend() routine seems like good fix...
> > > 
> > > No. I don't see a reason why my desktop P4 should drop to 12.5 frequency
> > > (p4-clockmod) if I ask it to suspend to mem.
> > 
> > So, would it be acceptable to check in _suspend() if the state is S4
> > and drop the frequency in that case or do nothing otherwise?
> 
> No. The point is that this is _very_ system-specific. Some systems resume
> always at full speed, some always at low speed; for S4 the behaviour may be
> completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> seems to be the best thing to me. The good thing is, after all, that cpufreq
> detected this situation and tries to correct for it.

You may not run k8 notebook on max frequency on battery. Your system
will crash; and you might even damage battery.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

On Thursday, 3 of February 2005 15:20, Pavel Machek wrote:
> Hi!
> 
> > > > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > > > idea. Still it would be nice to tell cpufreq governor "please change
> > > > > > > the frequency ASAP" so it does not run at 800MHz for half an hour
> > > > > > > compiling kernels on AC power.
> > > > > > 
> > > > > > It already does that... or at least it should. in cpufreq_resume() there is
> > > > > > a call to schedule_work(&cpu_policy->update); which will cause a call
> > > > > > cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the
> > > > > > governor, and it is supposed to adjust the frequency to the user's wish
> > > > > > then.
> > > > > 
> > > > > Ok, so Rafael's suspend() routine seems like good fix...
> > > > 
> > > > No. I don't see a reason why my desktop P4 should drop to 12.5 frequency
> > > > (p4-clockmod) if I ask it to suspend to mem.
> > > 
> > > So, would it be acceptable to check in _suspend() if the state is S4
> > > and drop the frequency in that case or do nothing otherwise?
> > 
> > No. The point is that this is _very_ system-specific. Some systems resume
> > always at full speed, some always at low speed; for S4 the behaviour may be
> > completely unpredictable. And in fact I wouldn't want my desktop P4 drop th
> > 12.5 % frequency if I ask it to suspend to disk, too. "Ignoring" the warning
> > seems to be the best thing to me. The good thing is, after all, that cpufreq
> > detected this situation and tries to correct for it.
> 
> You may not run k8 notebook on max frequency on battery. Your system
> will crash; and you might even damage battery.

When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
all the time, on AC power as well as on battery.  Along with what you're
saying it leads to the conclusion that in fact I have to compile in cpufreq
or I can damage the battery otherwise.  Is that right?

Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
> 
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery.  Along with what you're
> saying it leads to the conclusion that in fact I have to compile in cpufreq
> or I can damage the battery otherwise.  Is that right?

Yes.

[It is strange, k8 notebooks are supposed to boot at 800MHz. Older
arima prototype got it wrong and in 50% crashed during boot on battery
power. OTOH if your machine is stable at battery at 1.8GHz... well
then we'll have to search for other problem in cpufreq&resume....]

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: cpufreq problem wrt suspend/resume on Athlon64

[Rafael J. Wysocki]

Hi,

On Thursday, 3 of February 2005 23:00, Pavel Machek wrote:
> Hi!
> 
> > > You may not run k8 notebook on max frequency on battery. Your system
> > > will crash; and you might even damage battery.
> > 
> > When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> > all the time, on AC power as well as on battery.  Along with what you're
> > saying it leads to the conclusion that in fact I have to compile in cpufreq
> > or I can damage the battery otherwise.  Is that right?
> 
> Yes.
> 
> [It is strange, k8 notebooks are supposed to boot at 800MHz. Older
> arima prototype got it wrong and in 50% crashed during boot on battery
> power. OTOH if your machine is stable at battery at 1.8GHz... well
> then we'll have to search for other problem in cpufreq&resume....]

It seems to be stable, although I must admit I haven't run it on battery power
for longer than 5 min. without cpufreq and now I'm a bit reluctant to try. ;-)

Anyway the failing case seems to be when the frequency during suspend
is higher than during resume (eg when the image is created at 1800 MHz and the
CPU is running at 800 MHz right after restoring the image).
 
Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: cpufreq problem wrt suspend/resume on Athlon64

[Pavel Machek]

Hi!

> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
> 
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery.  Along with what you're
> saying it leads to the conclusion that in fact I have to compile in cpufreq
> or I can damage the battery otherwise.  Is that right?

To clarify:

Your vendor did the wrong thing. They should probably fix their
BIOS.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!