RE: cpufreq stops working after a while

[Carlos Garcia Campos <carlosgc@gnome.org>]

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