RE: cpufreq stops working after a while

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Carlos Garcia Campos
>Sent: Tuesday, August 15, 2006 4:07 AM
>To: cpufreq@lists.linux.org.uk
>Subject: Re: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
>> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
>> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
>> > 
>> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz 
>Pentium-M ULV processor.
>> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
>> > > 
>> > > I use speedstep-centrino with it, and after boot all is 
>usually okay.
>> > > But after a few hours of operation, it stops shifting to 
>the highest frequency
>> > > even under continuous 100% load (or not).  Eventually it 
>gets stuck at 600Mhz
>> > > and stays there until I reboot.
>
>I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
>Pentium(R) M processor 1.60GHz). If I'm compiling something, for
>example, that takes a long time, scaling_max_freq is set to 600000 (the
>lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
>Only after some time if the cpu load is not high I can echoing 1600000
>again and it works without need to reboot. 
>

Looks like you have the same problem that Mark had in this original thread. Thermal.
It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 2612 bytes --]

El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk 
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >Carlos Garcia Campos
> >Sent: Tuesday, August 15, 2006 4:07 AM
> >To: cpufreq@lists.linux.org.uk
> >Subject: Re: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
> >> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> >> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> >> > 
> >> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz 
> >Pentium-M ULV processor.
> >> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> >> > > 
> >> > > I use speedstep-centrino with it, and after boot all is 
> >usually okay.
> >> > > But after a few hours of operation, it stops shifting to 
> >the highest frequency
> >> > > even under continuous 100% load (or not).  Eventually it 
> >gets stuck at 600Mhz
> >> > > and stays there until I reboot.
> >
> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >example, that takes a long time, scaling_max_freq is set to 600000 (the
> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >Only after some time if the cpu load is not high I can echoing 1600000
> >again and it works without need to reboot. 
> >
> 
> Looks like you have the same problem that Mark had in this original thread. Thermal.

It never happened with older kernels (< 2.6.17, I think)

> It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

Yes, my system has fans. Here is the contents of the files
under /proc/acpi/termal_zone/*/*, if it helps:

$ cat /proc/acpi/thermal_zone/THM/*
<setting not supported>
cooling mode:   critical
<polling disabled>
state:                   ok
temperature:             47 C
critical (S5):           102 C

How can I solve the problem then? It's very annoying. 

> Thanks,
> Venki
> 

Thanks a lot, 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

Re: cpufreq stops working after a while

[Len Brown]

> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >example, that takes a long time, scaling_max_freq is set to 600000 (the
> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >Only after some time if the cpu load is not high I can echoing 1600000
> >again and it works without need to reboot. 
> >
> 
> Looks like you have the same problem that Mark had in this original thread. Thermal.
> It is not a bug in cpufreq. Just that due to cpu load, system is getting heated up and platform decides to reduce the temperature using passive cooling and as a result reduces the frequency. Does your system have active cooling (fans) or does it allow only passive cooling? You can monitor the temperature by looking at stuff under /proc/acpi/termal_zone/*/*.

I've got a D600 and have noticed thermal throttling also.
The way I noticed it is because bltk showed poor performance
compared to other similar laptops when measuring battery life:

http://sourceforge.net/projects/bltk
 
I found that this was independent of cpufreq, and would still happen even if the performance governor was used.
Sometimes I noticed that the T-state in /proc/acpi/processor/*/throttling was not 0, which was unexpected.

I blamed SuSE's stupid powersavd at the time (IIR, it was SL10.1) , but maybe that wasn't the root cause.

-Len

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Carlos Garcia Campos
>Sent: Wednesday, August 16, 2006 3:11 AM
>To: cpufreq@lists.linux.org.uk
>Subject: RE: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
>> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
>> >  
>> > 
>> > Can you confirm the latest version of the kernel where the 
>problem was not there. That will help on narrowing this down.
>> 
>> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
>> right now.
>> 
>> > >> It is not a bug in cpufreq. Just that due to cpu load, 
>> > >system is getting heated up and platform decides to reduce the 
>> > >temperature using passive cooling and as a result reduces the 
>> > >frequency. Does your system have active cooling (fans) or does 
>> > >it allow only passive cooling? You can monitor the temperature 
>> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
>> > >
>> > >Yes, my system has fans. Here is the contents of the files
>> > >under /proc/acpi/termal_zone/*/*, if it helps:
>> > >
>> > >$ cat /proc/acpi/thermal_zone/THM/*
>> > ><setting not supported>
>> > >cooling mode:   critical
>> > ><polling disabled>
>> > >state:                   ok
>> > >temperature:             47 C
>> > >critical (S5):           102 C
>> > >
>> > >How can I solve the problem then? It's very annoying. 
>> > 
>> > 
>> > Can you watch the temperature as you see the frequency 
>drop. Continuously (every second) cat cpufreq_max_freq in /sys 
>and temperature in /proc as you run you load. My feeling is 
>you will see the drop in max freq as your temperature goes to 
>around 60 degrees or so.
>> 
>> Here are the results:
>> 
>> ................
>> 1600000 - 85 C
>> 1600000 - 84 C
>> 1600000 - 85 C
>> 1600000 - 76 C
>> 600000 - 76 C
>> 600000 - 71 C
>> 600000 - 70 C
>> 600000 - 69 C
>> ................
>> 
>> It changed at 76 C.
>
>I forgot to mention that if I boot from battery scaling_max_freq is set
>to 600000 and I have to echo 1600000. At boot time temperature is not
>high so I'm not sure it's a thermal problem, or at least not only a
>thermal problem. 
>

That looks like a different problem. It may be a policy being set by some userland daemon/startup script. Enable CPU_FREQ_DEBUG and boot with boot parameter cpufreq.debug=7 you should see when and why max_freq is changing. Infact for the other problem as well, get the messages from debug.

One other thing you can try is changing thermal_zone polling_frequency to 1 and see whether it change the behavior when you run the workload.

Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 6336 bytes --]

El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: cpufreq-bounces@lists.linux.org.uk 
> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >Carlos Garcia Campos
> >Sent: Wednesday, August 16, 2006 3:11 AM
> >To: cpufreq@lists.linux.org.uk
> >Subject: RE: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
> >> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
> >> >  
> >> > 
> >> > Can you confirm the latest version of the kernel where the 
> >problem was not there. That will help on narrowing this down.
> >> 
> >> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
> >> right now.
> >> 
> >> > >> It is not a bug in cpufreq. Just that due to cpu load, 
> >> > >system is getting heated up and platform decides to reduce the 
> >> > >temperature using passive cooling and as a result reduces the 
> >> > >frequency. Does your system have active cooling (fans) or does 
> >> > >it allow only passive cooling? You can monitor the temperature 
> >> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
> >> > >
> >> > >Yes, my system has fans. Here is the contents of the files
> >> > >under /proc/acpi/termal_zone/*/*, if it helps:
> >> > >
> >> > >$ cat /proc/acpi/thermal_zone/THM/*
> >> > ><setting not supported>
> >> > >cooling mode:   critical
> >> > ><polling disabled>
> >> > >state:                   ok
> >> > >temperature:             47 C
> >> > >critical (S5):           102 C
> >> > >
> >> > >How can I solve the problem then? It's very annoying. 
> >> > 
> >> > 
> >> > Can you watch the temperature as you see the frequency 
> >drop. Continuously (every second) cat cpufreq_max_freq in /sys 
> >and temperature in /proc as you run you load. My feeling is 
> >you will see the drop in max freq as your temperature goes to 
> >around 60 degrees or so.
> >> 
> >> Here are the results:
> >> 
> >> ................
> >> 1600000 - 85 C
> >> 1600000 - 84 C
> >> 1600000 - 85 C
> >> 1600000 - 76 C
> >> 600000 - 76 C
> >> 600000 - 71 C
> >> 600000 - 70 C
> >> 600000 - 69 C
> >> ................
> >> 
> >> It changed at 76 C.
> >
> >I forgot to mention that if I boot from battery scaling_max_freq is set
> >to 600000 and I have to echo 1600000. At boot time temperature is not
> >high so I'm not sure it's a thermal problem, or at least not only a
> >thermal problem. 
> >
> 
> That looks like a different problem. It may be a policy being set by some userland daemon/startup script. Enable CPU_FREQ_DEBUG and boot with boot parameter cpufreq.debug=7 you should see when and why max_freq is changing. Infact for the other problem as well, get the messages from debug.

I have a script in /etc/init.d to set conservative governor at startup. 

> One other thing you can try is changing thermal_zone polling_frequency to 1 and see whether it change the behavior when you run the workload.

I tried it, but it didn't work. 

Here is what I got from debug messages: 

1.- scaling_max_freq is set to 600000

speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
cpufreq-core: notification 0 of frequency transition to 1400000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
cpufreq-core: notification 1 of frequency transition to 1400000 kHz
cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
printk: 42 messages suppressed.
cpufreq-core: updating policy for CPU 0
cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
cpufreq-core: notification 0 of frequency transition to 600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
cpufreq-core: notification 1 of frequency transition to 600000 kHz
cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 600000 kHz, relation 1
freq-table: request for target 600000 kHz (relation: 1) for cpu 0

2.- I can set 1600000 again and it works

cpufreq-core: updating policy for CPU 0
cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
cpufreq-core: notification 0 of frequency transition to 1600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
cpufreq-core: notification 1 of frequency transition to 1600000 kHz
userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 600000 - 600000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 600000 kHz, relation 1
freq-table: request for target 600000 kHz (relation: 1) for cpu 0
freq-table: target is 7 (600000 kHz, 1554)
speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612

I hope it helps to catch the problem. 

> Thanks,
> Venki
> 

Thanks,
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

RE: cpufreq stops working after a while

[Thomas Renninger]

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

On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >  
> Here is what I got from debug messages: 
> 
> 1.- scaling_max_freq is set to 600000
> 
> speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> printk: 42 messages suppressed.
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
BIOS probably reduced freq behind kernel's back (you didn't unplug AC?,
so this machine might also just reduce freq by BIOS for thermal
issues?):
I expect you run through:
 drivers/cpufreq/cpufreq.c:cpufreq_update_policy():
      /* BIOS might change freq behind our back
          -> ask driver for current freq and notify governors about a change */
        if (cpufreq_driver->get) {
                policy.cur = cpufreq_driver->get(cpu);
                if (!data->cur) {
                        dprintk("Driver did not initialize current freq");
                        data->cur = policy.cur;
                } else {
                        if (data->cur != policy.cur)
                                cpufreq_out_of_sync(cpu, data->cur, policy.cur);
                }
        }

> cpufreq-core: notification 0 of frequency transition to 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: notification 1 of frequency transition to 600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> 
> 2.- I can set 1600000 again and it works
> 
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
Looks like BIOS decided that we can use highest freq again and directly
sets the freq to 1600 and kernel didn't notice.
> cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
Oh something went wrong, request should always be from (600000-1600000).
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
Eventually freq could get limited here if BIOS (_PPC) still does not
allow highest freq. But here it would/should allow it again.
It seems as if the "real" max_freq can still be accidently overridden by
the temporary limited max_freq.
I think this could only happen by calling cpufreq_set_policy(..) (or the
one used by min,max sysfs writes), but maybe it may also happen
somewhere else...

> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> freq-table: target is 7 (600000 kHz, 1554)
> speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> 
> I hope it helps to catch the problem. 

If you could tell us what kind of userspace tool you are using to
control cpufreq, that would help a lot.

If this tool still makes use of the deprecated /proc/ interface then
better upgrade this one.

IMO cpufreq_set_policy should not be exported as it is quite dangerous,
doing:

policy.max=xy
cpufreq_set_policy(&policy)

Will override the static max_freq (data->user_policy.max) with the
temporarily limited one (what should only happen if writing to
scaling_max_freq).

Only place I found this call was in drivers/acpi/processor_perflib.c
If your userspace tool sets frequency over that one (what it should not
do):
/proc/acpi/processor/XY/performance
this patch might help, otherwise it will not.

But instead of this patch, I think it's better to rip out this file
totally as it also does not provide SMP capabilities (on an SMP system
writing to it, may randomly modify frequency of one of the CPUs).

Compile tested and patched again 2.6.18-rc4:

 drivers/acpi/processor_perflib.c |    9 +++++----
 drivers/cpufreq/cpufreq.c        |    4 +---
 2 files changed, 6 insertions(+), 7 deletions(-)

Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
+++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
@@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
 	struct acpi_processor *pr = (struct acpi_processor *)m->private;
 	struct acpi_processor_performance *perf;
 	char state_string[12] = { '\0' };
-	unsigned int new_state = 0;
+	unsigned int new_state, new_freq = 0;
 	struct cpufreq_policy policy;
 
 
@@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
 	cpufreq_get_policy(&policy, pr->id);
 
 	policy.cpu = pr->id;
-	policy.min = perf->states[new_state].core_frequency * 1000;
-	policy.max = perf->states[new_state].core_frequency * 1000;
+	new_freq = perf->states[new_state].core_frequency * 1000;
+
+	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
+
 
-	result = cpufreq_set_policy(&policy);
 	if (result)
 		return result;
 
Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1448,7 +1448,7 @@ error_out:
  *
  *	Sets a new CPU frequency and voltage scaling policy.
  */
-int cpufreq_set_policy(struct cpufreq_policy *policy)
+static int cpufreq_set_policy(struct cpufreq_policy *policy)
 {
 	int ret = 0;
 	struct cpufreq_policy *data;
@@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_set_policy);
-
 
 /**
  *	cpufreq_update_policy - re-evaluate an existing cpufreq policy



[-- Attachment #2: cpufreq_dont_override_max_freq.patch --]
[-- Type: text/x-patch, Size: 1832 bytes --]

 drivers/acpi/processor_perflib.c |    9 +++++----
 drivers/cpufreq/cpufreq.c        |    4 +---
 2 files changed, 6 insertions(+), 7 deletions(-)

Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
+++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
@@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
 	struct acpi_processor *pr = (struct acpi_processor *)m->private;
 	struct acpi_processor_performance *perf;
 	char state_string[12] = { '\0' };
-	unsigned int new_state = 0;
+	unsigned int new_state, new_freq = 0;
 	struct cpufreq_policy policy;
 
 
@@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
 	cpufreq_get_policy(&policy, pr->id);
 
 	policy.cpu = pr->id;
-	policy.min = perf->states[new_state].core_frequency * 1000;
-	policy.max = perf->states[new_state].core_frequency * 1000;
+	new_freq = perf->states[new_state].core_frequency * 1000;
+
+	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
+
 
-	result = cpufreq_set_policy(&policy);
 	if (result)
 		return result;
 
Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1448,7 +1448,7 @@ error_out:
  *
  *	Sets a new CPU frequency and voltage scaling policy.
  */
-int cpufreq_set_policy(struct cpufreq_policy *policy)
+static int cpufreq_set_policy(struct cpufreq_policy *policy)
 {
 	int ret = 0;
 	struct cpufreq_policy *data;
@@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
 
 	return ret;
 }
-EXPORT_SYMBOL(cpufreq_set_policy);
-
 
 /**
  *	cpufreq_update_policy - re-evaluate an existing cpufreq policy

[-- 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: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 8402 bytes --]

El jue, 17-08-2006 a las 12:46 +0200, Thomas Renninger escribió:
> On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> > El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> > >  
> > Here is what I got from debug messages: 
> > 
> > 1.- scaling_max_freq is set to 600000
> > 
> > speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> > cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> > cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> > cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> > printk: 42 messages suppressed.
> > cpufreq-core: updating policy for CPU 0
> > cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
> BIOS probably reduced freq behind kernel's back (you didn't unplug AC?,
> so this machine might also just reduce freq by BIOS for thermal
> issues?):

No, AC is always plugged.

> I expect you run through:
>  drivers/cpufreq/cpufreq.c:cpufreq_update_policy():
>       /* BIOS might change freq behind our back
>           -> ask driver for current freq and notify governors about a change */
>         if (cpufreq_driver->get) {
>                 policy.cur = cpufreq_driver->get(cpu);
>                 if (!data->cur) {
>                         dprintk("Driver did not initialize current freq");
>                         data->cur = policy.cur;
>                 } else {
>                         if (data->cur != policy.cur)
>                                 cpufreq_out_of_sync(cpu, data->cur, policy.cur);
>                 }
>         }
> 
> > cpufreq-core: notification 0 of frequency transition to 600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> > cpufreq-core: notification 1 of frequency transition to 600000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> > cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> > freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> > cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> > cpufreq-core: governor: change or update limits
> > cpufreq-core: __cpufreq_governor for CPU 0, event 3
> > cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> > freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> > 
> > 2.- I can set 1600000 again and it works
> > 
> > cpufreq-core: updating policy for CPU 0
> > cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
> Looks like BIOS decided that we can use highest freq again and directly
> sets the freq to 1600 and kernel didn't notice.
> > cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> > cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> > cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> > userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> > cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> Oh something went wrong, request should always be from (600000-1600000).
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> > freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> > freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> Eventually freq could get limited here if BIOS (_PPC) still does not
> allow highest freq. But here it would/should allow it again.
> It seems as if the "real" max_freq can still be accidently overridden by
> the temporary limited max_freq.
> I think this could only happen by calling cpufreq_set_policy(..) (or the
> one used by min,max sysfs writes), but maybe it may also happen
> somewhere else...
> 
> > cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> > cpufreq-core: governor: change or update limits
> > cpufreq-core: __cpufreq_governor for CPU 0, event 3
> > cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> > freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> > freq-table: target is 7 (600000 kHz, 1554)
> > speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> > 
> > I hope it helps to catch the problem. 
> 
> If you could tell us what kind of userspace tool you are using to
> control cpufreq, that would help a lot.

I don't use any tool. I use conservative governor. When scaling_max_freq
is set to 600 I try to set 1600 again directly with echo. I don't use
any other tool to control cpufreq.

> If this tool still makes use of the deprecated /proc/ interface then
> better upgrade this one.

No, it's even not compiled. 

> IMO cpufreq_set_policy should not be exported as it is quite dangerous,
> doing:
> 
> policy.max=xy
> cpufreq_set_policy(&policy)
> 
> Will override the static max_freq (data->user_policy.max) with the
> temporarily limited one (what should only happen if writing to
> scaling_max_freq).
> 
> Only place I found this call was in drivers/acpi/processor_perflib.c
> If your userspace tool sets frequency over that one (what it should not
> do):
> /proc/acpi/processor/XY/performance
> this patch might help, otherwise it will not.
> 
> But instead of this patch, I think it's better to rip out this file
> totally as it also does not provide SMP capabilities (on an SMP system
> writing to it, may randomly modify frequency of one of the CPUs).
> 
> Compile tested and patched again 2.6.18-rc4:
> 
>  drivers/acpi/processor_perflib.c |    9 +++++----
>  drivers/cpufreq/cpufreq.c        |    4 +---
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> Index: linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
> ===================================================================
> --- linux-2.6.18-rc4.orig/drivers/acpi/processor_perflib.c
> +++ linux-2.6.18-rc4/drivers/acpi/processor_perflib.c
> @@ -457,7 +457,7 @@ acpi_processor_write_performance(struct 
>  	struct acpi_processor *pr = (struct acpi_processor *)m->private;
>  	struct acpi_processor_performance *perf;
>  	char state_string[12] = { '\0' };
> -	unsigned int new_state = 0;
> +	unsigned int new_state, new_freq = 0;
>  	struct cpufreq_policy policy;
>  
> 
> @@ -480,10 +480,11 @@ acpi_processor_write_performance(struct 
>  	cpufreq_get_policy(&policy, pr->id);
>  
>  	policy.cpu = pr->id;
> -	policy.min = perf->states[new_state].core_frequency * 1000;
> -	policy.max = perf->states[new_state].core_frequency * 1000;
> +	new_freq = perf->states[new_state].core_frequency * 1000;
> +
> +	__cpufreq_driver_target(&policy, new_freq, CPUFREQ_RELATION_L);
> +
>  
> -	result = cpufreq_set_policy(&policy);
>  	if (result)
>  		return result;
>  
> Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
> ===================================================================
> --- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
> +++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
> @@ -1448,7 +1448,7 @@ error_out:
>   *
>   *	Sets a new CPU frequency and voltage scaling policy.
>   */
> -int cpufreq_set_policy(struct cpufreq_policy *policy)
> +static int cpufreq_set_policy(struct cpufreq_policy *policy)
>  {
>  	int ret = 0;
>  	struct cpufreq_policy *data;
> @@ -1478,8 +1478,6 @@ int cpufreq_set_policy(struct cpufreq_po
>  
>  	return ret;
>  }
> -EXPORT_SYMBOL(cpufreq_set_policy);
> -
>  
>  /**
>   *	cpufreq_update_policy - re-evaluate an existing cpufreq policy
> 
> 

Thanks a lot, 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

RE: cpufreq stops working after a while

[Thomas Renninger]

On Wed, 2006-08-16 at 20:19 +0200, Carlos Garcia Campos wrote:
> El mié, 16-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >  

Sorry, I don't see it... A last guess...
When these Dells allow freqs again after (un-)plugging AC, a processor
event is thrown, _PPC is reread and freqs are allowed again.
This works AFAIK.

Maybe this processor event is missing when the machine unlimits freq
because of thermal issues and _PPC does not get updated.

You should be able to test this by:
If you run into this issue (freq limited), wait a while until the
machine is cool (better wait a bit longer..) then unplug and replug the
AC adapter. Then wait for ten seconds. _PPC should get reevaluated and
max_freq should be set to highest freq again.

You can watch the acpi events by stopping hal/acpid whatever
accesses /proc/acpi/events, then do cat /proc/acpi/events.
Something like:
processor CPU0 0000008X 00000000
allows all freqs again
processor CPU0 0000008X 00000002
e.g. limits frequencies to the third highest.

If this is the case (processor event to allow all freqs again is
missing), the attached patch (patch is on top of the one I posted some
minutes ago) might help.

> 1.- scaling_max_freq is set to 600000
> 
> speedstep-centrino: target=1520000kHz old=1600000 new=1400000 msr=0e24
> cpufreq-core: notification 0 of frequency transition to 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: notification 1 of frequency transition to 1400000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1395912 for frequency 1400000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1400000 kHz
> cpufreq-core: target for CPU 0: 1440000 kHz, relation 1
> printk: 42 messages suppressed.
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1600000, is 600000 kHz.
> cpufreq-core: notification 0 of frequency transition to 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: notification 1 of frequency transition to 600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 598248 for frequency 600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 1600000 kHz
> freq-table: request for verification of policy (600000 - 1600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 1600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> 
> 2.- I can set 1600000 again and it works
> 
> cpufreq-core: updating policy for CPU 0
> cpufreq-core: Warning: CPU frequency out of sync: cpufreq and timing core thinks of 600000, is 1600000 kHz.
This is where I expect freqs are allowed again and simply increase
max_freq to current_freq..., it's as ugly as the machine' BIOS ...

> cpufreq-core: notification 0 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: scaling loops_per_jiffy to 1595328 for frequency 1600000 kHz
> cpufreq-core: notification 1 of frequency transition to 1600000 kHz
> userspace: saving cpu_cur_freq of cpu 0 to be 1600000 kHz
> cpufreq-core: setting new policy for CPU 0: 600000 - 600000 kHz
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> freq-table: request for verification of policy (600000 - 600000 kHz) for cpu 0
> freq-table: verification lead to (600000 - 600000 kHz) for cpu 0
> cpufreq-core: new min and max freqs are 600000 - 600000 kHz
> cpufreq-core: governor: change or update limits
> cpufreq-core: __cpufreq_governor for CPU 0, event 3
> cpufreq-core: target for CPU 0: 600000 kHz, relation 1
> freq-table: request for target 600000 kHz (relation: 1) for cpu 0
> freq-table: target is 7 (600000 kHz, 1554)
> speedstep-centrino: target=600000kHz old=1600000 new=600000 msr=0612
> 
> I hope it helps to catch the problem. 

Hope that helps, if not I run out of ideas...

 drivers/cpufreq/cpufreq.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.18-rc4.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.18-rc4/drivers/cpufreq/cpufreq.c
@@ -1514,8 +1514,12 @@ int cpufreq_update_policy(unsigned int c
 			dprintk("Driver did not initialize current freq");
 			data->cur = policy.cur;
 		} else {
-			if (data->cur != policy.cur)
+			if (data->cur != policy.cur){
 				cpufreq_out_of_sync(cpu, data->cur, policy.cur);
+				if (data->cur > policy.max)
+					data->user_policy.max = policy.max =
+						data->cur;
+			}
 		}
 	}

RE: cpufreq stops working after a while

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
>Sent: Tuesday, August 15, 2006 8:08 AM
>To: Pallipadi, Venkatesh
>Cc: cpufreq@lists.linux.org.uk
>Subject: RE: cpufreq stops working after a while
>
>El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
>>  
>> >-----Original Message-----
>> >From: cpufreq-bounces@lists.linux.org.uk 
>> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>> >Carlos Garcia Campos
>> >Sent: Tuesday, August 15, 2006 4:07 AM
>> >To: cpufreq@lists.linux.org.uk
>> >Subject: Re: cpufreq stops working after a while
>> >
>> >
>> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
>> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
>> >example, that takes a long time, scaling_max_freq is set to 
>600000 (the
>> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
>> >Only after some time if the cpu load is not high I can 
>echoing 1600000
>> >again and it works without need to reboot. 
>> >
>> 
>> Looks like you have the same problem that Mark had in this 
>original thread. Thermal.
>
>It never happened with older kernels (< 2.6.17, I think)
>

Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.

>> It is not a bug in cpufreq. Just that due to cpu load, 
>system is getting heated up and platform decides to reduce the 
>temperature using passive cooling and as a result reduces the 
>frequency. Does your system have active cooling (fans) or does 
>it allow only passive cooling? You can monitor the temperature 
>by looking at stuff under /proc/acpi/termal_zone/*/*.
>
>Yes, my system has fans. Here is the contents of the files
>under /proc/acpi/termal_zone/*/*, if it helps:
>
>$ cat /proc/acpi/thermal_zone/THM/*
><setting not supported>
>cooling mode:   critical
><polling disabled>
>state:                   ok
>temperature:             47 C
>critical (S5):           102 C
>
>How can I solve the problem then? It's very annoying. 


Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.


Thanks,
Venki

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3078 bytes --]

El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
>  
> >-----Original Message-----
> >From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
> >Sent: Tuesday, August 15, 2006 8:08 AM
> >To: Pallipadi, Venkatesh
> >Cc: cpufreq@lists.linux.org.uk
> >Subject: RE: cpufreq stops working after a while
> >
> >El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> >>  
> >> >-----Original Message-----
> >> >From: cpufreq-bounces@lists.linux.org.uk 
> >> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> >> >Carlos Garcia Campos
> >> >Sent: Tuesday, August 15, 2006 4:07 AM
> >> >To: cpufreq@lists.linux.org.uk
> >> >Subject: Re: cpufreq stops working after a while
> >> >
> >> >
> >> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> >> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> >> >example, that takes a long time, scaling_max_freq is set to 
> >600000 (the
> >> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> >> >Only after some time if the cpu load is not high I can 
> >echoing 1600000
> >> >again and it works without need to reboot. 
> >> >
> >> 
> >> Looks like you have the same problem that Mark had in this 
> >original thread. Thermal.
> >
> >It never happened with older kernels (< 2.6.17, I think)
> >
> 
> Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.

I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
right now.

> >> It is not a bug in cpufreq. Just that due to cpu load, 
> >system is getting heated up and platform decides to reduce the 
> >temperature using passive cooling and as a result reduces the 
> >frequency. Does your system have active cooling (fans) or does 
> >it allow only passive cooling? You can monitor the temperature 
> >by looking at stuff under /proc/acpi/termal_zone/*/*.
> >
> >Yes, my system has fans. Here is the contents of the files
> >under /proc/acpi/termal_zone/*/*, if it helps:
> >
> >$ cat /proc/acpi/thermal_zone/THM/*
> ><setting not supported>
> >cooling mode:   critical
> ><polling disabled>
> >state:                   ok
> >temperature:             47 C
> >critical (S5):           102 C
> >
> >How can I solve the problem then? It's very annoying. 
> 
> 
> Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.

Here are the results:

................
1600000 - 85 C
1600000 - 84 C
1600000 - 85 C
1600000 - 76 C
600000 - 76 C
600000 - 71 C
600000 - 70 C
600000 - 69 C
................

It changed at 76 C.

> 
> Thanks,
> Venki
> 
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

RE: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3578 bytes --]

El mar, 15-08-2006 a las 19:46 +0200, Carlos Garcia Campos escribió:
> El mar, 15-08-2006 a las 08:23 -0700, Pallipadi, Venkatesh escribió:
> >  
> > >-----Original Message-----
> > >From: Carlos Garcia Campos [mailto:carlosgc@gnome.org] 
> > >Sent: Tuesday, August 15, 2006 8:08 AM
> > >To: Pallipadi, Venkatesh
> > >Cc: cpufreq@lists.linux.org.uk
> > >Subject: RE: cpufreq stops working after a while
> > >
> > >El mar, 15-08-2006 a las 06:27 -0700, Pallipadi, Venkatesh escribió:
> > >>  
> > >> >-----Original Message-----
> > >> >From: cpufreq-bounces@lists.linux.org.uk 
> > >> >[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
> > >> >Carlos Garcia Campos
> > >> >Sent: Tuesday, August 15, 2006 4:07 AM
> > >> >To: cpufreq@lists.linux.org.uk
> > >> >Subject: Re: cpufreq stops working after a while
> > >> >
> > >> >
> > >> >I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
> > >> >Pentium(R) M processor 1.60GHz). If I'm compiling something, for
> > >> >example, that takes a long time, scaling_max_freq is set to 
> > >600000 (the
> > >> >lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
> > >> >Only after some time if the cpu load is not high I can 
> > >echoing 1600000
> > >> >again and it works without need to reboot. 
> > >> >
> > >> 
> > >> Looks like you have the same problem that Mark had in this 
> > >original thread. Thermal.
> > >
> > >It never happened with older kernels (< 2.6.17, I think)
> > >
> > 
> > Can you confirm the latest version of the kernel where the problem was not there. That will help on narrowing this down.
> 
> I'm not sure at all . . . I don't have any kernel < 2.6.17 compiled
> right now.
> 
> > >> It is not a bug in cpufreq. Just that due to cpu load, 
> > >system is getting heated up and platform decides to reduce the 
> > >temperature using passive cooling and as a result reduces the 
> > >frequency. Does your system have active cooling (fans) or does 
> > >it allow only passive cooling? You can monitor the temperature 
> > >by looking at stuff under /proc/acpi/termal_zone/*/*.
> > >
> > >Yes, my system has fans. Here is the contents of the files
> > >under /proc/acpi/termal_zone/*/*, if it helps:
> > >
> > >$ cat /proc/acpi/thermal_zone/THM/*
> > ><setting not supported>
> > >cooling mode:   critical
> > ><polling disabled>
> > >state:                   ok
> > >temperature:             47 C
> > >critical (S5):           102 C
> > >
> > >How can I solve the problem then? It's very annoying. 
> > 
> > 
> > Can you watch the temperature as you see the frequency drop. Continuously (every second) cat cpufreq_max_freq in /sys and temperature in /proc as you run you load. My feeling is you will see the drop in max freq as your temperature goes to around 60 degrees or so.
> 
> Here are the results:
> 
> ................
> 1600000 - 85 C
> 1600000 - 84 C
> 1600000 - 85 C
> 1600000 - 76 C
> 600000 - 76 C
> 600000 - 71 C
> 600000 - 70 C
> 600000 - 69 C
> ................
> 
> It changed at 76 C.

I forgot to mention that if I boot from battery scaling_max_freq is set
to 600000 and I have to echo 1600000. At boot time temperature is not
high so I'm not sure it's a thermal problem, or at least not only a
thermal problem. 

> > 
> > Thanks,
> > Venki
> > 

Thanks a lot for your help,
-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

Re: cpufreq stops working after a while

[Andrew Morton]

On Fri, 11 Aug 2006 14:25:26 -0400
Mark Lord <lkml@rtr.ca> wrote:

> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> 
> I use speedstep-centrino with it, and after boot all is usually okay.
> But after a few hours of operation, it stops shifting to the highest frequency
> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> and stays there until I reboot.
> 
> Sometimes rebooting doesn't even restore it.
> 
> /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
> showing the available frequencies and other info.  All of the attribs
> there look fine, except for "scaling_max_freq", which is what seems
> to gradually get set smaller.  For instance, right now it is set to 800000,
> and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.
> 
> WHY?

cpufreq seems to have relatively frequent problems.

>  And how can I fix it?

You could start by telling us which kernel versions are affected ;)

Re: cpufreq stops working after a while

[Mark Lord]

Andrew Morton wrote:
> Mark Lord <lkml@rtr.ca> wrote:
..
>> I use speedstep-centrino with it, and after boot all is usually okay.
>> But after a few hours of operation, it stops shifting to the highest frequency
>> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
>> and stays there until I reboot.
..
>> WHY?
> 
> cpufreq seems to have relatively frequent problems.
> 
>>  And how can I fix it?
> 
> You could start by telling us which kernel versions are affected ;)

Heh.  2.6.17.6 and 2.6.18-rc3-git4 are the two kernels I have for it,
and both exhibit the problem.

Dave Jones wrote:
>boot with cpufreq.debug=7, and capture dmesg output after it fails

I'll reboot with the debug options and see..

Cheers

Re: cpufreq stops working after a while

[Mark Lord]

Andrew Morton wrote:
> On Fri, 11 Aug 2006 14:25:26 -0400
> Mark Lord <lkml@rtr.ca> wrote:
> 
>> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
>> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
>>
>> I use speedstep-centrino with it, and after boot all is usually okay.
>> But after a few hours of operation, it stops shifting to the highest frequency
>> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
>> and stays there until I reboot.
>>
>> Sometimes rebooting doesn't even restore it.
>>
>> /sys/devices/system/cpu/cpu0/cpufreq is all very normal looking,
>> showing the available frequencies and other info.  All of the attribs
>> there look fine, except for "scaling_max_freq", which is what seems
>> to gradually get set smaller.  For instance, right now it is set to 800000,
>> and it won't let me change it (echo 11000000 > scaling_max_freq has no effect.
>>
>> WHY?
> 
> cpufreq seems to have relatively frequent problems.
> 
>>  And how can I fix it?
> 
> You could start by telling us which kernel versions are affected ;)


Mmm.. since it appears to be related, kbuild dumps this out when building the kernel:

WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf29) and 'acpi_processor_cst_has_changed'

A possible source for the bug, or total red herring ?

Re: cpufreq stops working after a while

[Andrew Morton]

On Fri, 11 Aug 2006 15:10:16 -0400
Mark Lord <lkml@rtr.ca> wrote:

> >> WHY?
> > 
> > cpufreq seems to have relatively frequent problems.
> > 
> >>  And how can I fix it?
> > 
> > You could start by telling us which kernel versions are affected ;)
> 
> 
> Mmm.. since it appears to be related, kbuild dumps this out when building the kernel:
> 
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf29) and 'acpi_processor_cst_has_changed'
> 
> A possible source for the bug, or total red herring ?

An RH.  acpi_processor_power_init() is actually non-buggy, due to its
interesting games with `first_run'.

A section error would usually trigger a wild oops if you're affected by it.

Re: cpufreq stops working after a while

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 530 bytes --]

On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:

> One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> 
> I use speedstep-centrino with it, and after boot all is usually okay.
> But after a few hours of operation, it stops shifting to the highest frequency
> even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> and stays there until I reboot.

Can't it be TM2 pulling the handbrake?

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]

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

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

Re: cpufreq stops working after a while

[Thomas Renninger]

On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> 
> > One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> > 
> > I use speedstep-centrino with it, and after boot all is usually okay.
> > But after a few hours of operation, it stops shifting to the highest frequency
> > even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> > and stays there until I reboot.

After a few hours, urgh.

Dells limit their frequency to lowest after unplugging AC and allow all
freqs after some time (some secs) again.

There were two issues solved on the Dells some months ago:

- The frequency after you unplug AC adapter is already reduced by BIOS, 
  that confused the cpufreq driver.
- There was a race in sysfs writes. If you e.g. change governor or 
  possibly some other cpufreq related sysfs file while the frequency
  got limited by BIOS, the real max freq value got overridden by the
  temporarily limited max freq value and you are stuck to lowest freq
  forever.

Do you use any userspace daemon (cpuspeed, powersaved, ...) to control
cpuspeed?
If yes, you should first try without. It should be enough to:
- load your hw cpufreq module
- load the ondemand governor module
- echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

If it still happens we know at least it can't be some kind of sysfs race
again or userspace tools do not remember the wrong max_freq value. Then
some debug output or how to reproduce this a bit faster would be nice...

Maybe with something like that:
LOAD_FACTOR=40   # adjust this one to the power of your machine to let
                 # cpufreq switch up and down, or if it does not switch 
                 # up and down in the beginning it should stay at
                 # 800 (could be 5-20 on yours?),
                 # check with (in separate console):
# cd /sys/devices/system/cpu/cpu0/cpufreq/
# watch -n1  cat scaling_cur_freq scaling_max_freq

for ((x=200;x<1000;x+=5));do
    # give load
    for ((y=0;y<$LOAD_FACTOR;y++)); do
        echo "10 k 2 v p" |dc >/dev/null
    done;
    # then sleep
    usleep $((x*1000))   # maybe the right value here triggers the bug?
    echo "sleep $x milli secs"
done;

Maybe it's triggered if you start some other process(es) while this is
running?

    Thomas

Re: cpufreq stops working after a while

[Carlos Garcia Campos]

[-- Attachment #1.1: Type: text/plain, Size: 3629 bytes --]

El mar, 15-08-2006 a las 09:49 +0200, Thomas Renninger escribió:
> On Sat, 2006-08-12 at 10:52 +0200, Erik Slagter wrote:
> > On Fri, 11 Aug 2006 14:25:26 -0400 Mark Lord <lkml@rtr.ca> wrote:
> > 
> > > One of my notebooks (Dell Latitude X1) has a 1.1GHz Pentium-M ULV processor.
> > > This chip can change CPU speeds from 600 -> 800 -> 1100 Mhz.
> > > 
> > > I use speedstep-centrino with it, and after boot all is usually okay.
> > > But after a few hours of operation, it stops shifting to the highest frequency
> > > even under continuous 100% load (or not).  Eventually it gets stuck at 600Mhz
> > > and stays there until I reboot.

I have the same problem. My laptop is Dell Latitude D600 (Intel(R)
Pentium(R) M processor 1.60GHz). If I'm compiling something, for
example, that takes a long time, scaling_max_freq is set to 600000 (the
lowest). If I try to echo 1600000 to scaling_max_freq it do nothing.
Only after some time if the cpu load is not high I can echoing 1600000
again and it works without need to reboot. 

> After a few hours, urgh.
> 
> Dells limit their frequency to lowest after unplugging AC and allow all
> freqs after some time (some secs) again.
> 
> There were two issues solved on the Dells some months ago:
> 
> - The frequency after you unplug AC adapter is already reduced by BIOS, 
>   that confused the cpufreq driver.
> - There was a race in sysfs writes. If you e.g. change governor or 
>   possibly some other cpufreq related sysfs file while the frequency
>   got limited by BIOS, the real max freq value got overridden by the
>   temporarily limited max freq value and you are stuck to lowest freq
>   forever.
> 
> Do you use any userspace daemon (cpuspeed, powersaved, ...) to control
> cpuspeed?

In my case I use conservative governor and kernel version is
2.6.18-rc4. 

> If yes, you should first try without. It should be enough to:
> - load your hw cpufreq module
> - load the ondemand governor module
> - echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> If it still happens we know at least it can't be some kind of sysfs race
> again or userspace tools do not remember the wrong max_freq value. Then
> some debug output or how to reproduce this a bit faster would be nice...

It happens to me every time I try to compile something that takes a long
time (evolution, mozilla, even kernel)

> Maybe with something like that:
> LOAD_FACTOR=40   # adjust this one to the power of your machine to let
>                  # cpufreq switch up and down, or if it does not switch 
>                  # up and down in the beginning it should stay at
>                  # 800 (could be 5-20 on yours?),
>                  # check with (in separate console):
> # cd /sys/devices/system/cpu/cpu0/cpufreq/
> # watch -n1  cat scaling_cur_freq scaling_max_freq
> 
> for ((x=200;x<1000;x+=5));do
>     # give load
>     for ((y=0;y<$LOAD_FACTOR;y++)); do
>         echo "10 k 2 v p" |dc >/dev/null
>     done;
>     # then sleep
>     usleep $((x*1000))   # maybe the right value here triggers the bug?
>     echo "sleep $x milli secs"
> done;
> 
> Maybe it's triggered if you start some other process(es) while this is
> running?
> 
>     Thomas
> 
> 
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@lists.linux.org.uk
> http://lists.linux.org.uk/mailman/listinfo/cpufreq

-- 
Carlos Garcia Campos (KaL)
   elkalmail@yahoo.es
   carlosgc@gnome.org
   http://carlosgc.linups.org
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

[-- Attachment #1.2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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