headers
bugme-daemon | 1 Feb 2007 13:00

[Bug 5122] cpufreq/powernowd is still not working on my AMD64x2 3800+

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

------- Additional Comments From etorix <at> gmail.com  2007-02-01 03:51 -------
2.6.20-rc7 64-bit SMP , cpufreq is not working on  my AMD64x2 3800+
Software Environment:64-bit debian sid
will build 32-bit later today

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
bugme-daemon | 1 Feb 2007 22:52

[Bug 5122] cpufreq/powernowd is still not working on my AMD64x2 3800+

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

etorix <at> gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Resolution|                            |CODE_FIX

------- Additional Comments From etorix <at> gmail.com  2007-02-01 13:44 -------
Bug was reported for 2.6.13-rc7 32-bit [i stopped using powernow-xx on that box]
Result from  Linux version 2.6.20-rc7-eto-1 (etorix <at> gigabod) (gcc version 4.1.2
20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Thu Feb 1 20:23:26 GMT 2007
Feb  1 21:14:00 gigabod kernel: BIOS-provided physical RAM map:
from /var/log/messages:
Feb  1 21:14:04 gigabod powersaved: Loading powernow_k8
Feb  1 21:14:04 gigabod kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual
Core Processor 3800+ processors (version 2.00.00)
Feb  1 21:14:04 gigabod kernel: powernow-k8: invalid freq entries 3900000 kHz
vs. 65535000 kHz
Feb  1 21:14:04 gigabod last message repeated 3 times
Feb  1 21:14:04 gigabod kernel: powernow-k8:    0 : fid 0xc (2000 MHz), vid 0xa
Feb  1 21:14:04 gigabod kernel: powernow-k8:    1 : fid 0x2 (1000 MHz), vid 0x12
Feb  1 21:14:04 gigabod powersaved: enter 'powernow_k8' into CPUFREQD_MODULE in
/etc/powersave/cpufreq.
Feb  1 21:14:04 gigabod powersaved: this will speed up starting powersaved and
avoid unnecessary warnings in syslog.
Feb  1 21:14:05 gigabod powersaved: Starting powersaved with ACPI support

looks pretty much fixed, for 32-bit SMP , to me,eh
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Berg | 1 Feb 2007 21:14
Favicon

CPU hotplug vs. cpufreq on ppc64

I'm having an odd problem with ppc64 cpufreq and cpu hotplug. The cpu
hotplug I'm doing is just fake, but I need to unplug the CPUs for
suspend.

When the system boots up, all CPUs are added as such:
[   18.132830] cpufreq-core: trying to register driver powermac
[   18.132835] cpufreq-core: adding CPU 0
[   18.132976] cpufreq-core: CPU 1 already managed, adding link
[   18.132983] cpufreq-core: CPU 2 already managed, adding link
[   18.132989] cpufreq-core: CPU 3 already managed, adding link
[   18.132998] cpufreq-core: setting new policy for CPU 0: 1250000 - 2500000 kHz
[   18.133025] cpufreq-core: new min and max freqs are 1250000 - 2500000 kHz
[   18.133029] cpufreq-core: governor switch
[   18.133033] cpufreq-core: __cpufreq_governor for CPU 0, event 1
[   18.133043] cpufreq-core: target for CPU 0: 2500000 kHz, relation 1
[   18.133056] cpufreq-core: governor: change or update limits
[   18.133060] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[   18.133069] cpufreq-core: target for CPU 0: 2500000 kHz, relation 1
[   18.133082] cpufreq-core: initialization complete
[   18.133086] cpufreq-core: adding CPU 1
[   18.133089] cpufreq-core: adding CPU 2
[   18.133092] cpufreq-core: adding CPU 3
[   18.133097] cpufreq-core: driver powermac up and running

This says that the 4 CPUs can actually only be switched all together
with CPU0. This is achieved by doing

        policy->cpus = cpu_possible_map;
in
g5_cpufreq_cpu_init (arch/powerpc/platforms/powermac/cpufreq_64.c)
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jeremy Fitzhardinge | 2 Feb 2007 22:25
Gravatar

Re: Speedstep centrino

David Tunkrans wrote:
> I found your email adress in the speedstep centrino kernel source. Ive
> put down a lot of time into getting ACPI and speedstep working on my
> Mac Pro Ubuntu amd64 installation, with no success. Seems like the
> cpufreq parameters are "missing" even though the specification says
> that woodcrest Xeons do support speedstep. Also I suspect that there
> has to be specific support for Xeon processors in this driver? I would
> really appreciate if you could point me in the right direction.

In general, the newer CPUs require ACPI support to get the right
operating point parameters for the CPU; only the older Banias Pentium
M's have support built directly into the driver.  I don't know if Mac
Pros have ACPI; perhaps there needs to be some other way of getting that
info out of the BIOS, assuming its there at all.

    J
Permalink | Reply | 1 comment |
headers
Pallipadi, Venkatesh | 2 Feb 2007 23:04
Picon
Favicon

RE: Speedstep centrino


>-----Original Message-----
>From: cpufreq-bounces <at> lists.linux.org.uk 
>[mailto:cpufreq-bounces <at> lists.linux.org.uk] On Behalf Of 
>Jeremy Fitzhardinge
>Sent: Friday, February 02, 2007 1:26 PM
>To: David Tunkrans
>Cc: cpufreq <at> lists.linux.org.uk
>Subject: Re: Speedstep centrino
>
>David Tunkrans wrote:
>> I found your email adress in the speedstep centrino kernel 
>source. Ive
>> put down a lot of time into getting ACPI and speedstep working on my
>> Mac Pro Ubuntu amd64 installation, with no success. Seems like the
>> cpufreq parameters are "missing" even though the specification says
>> that woodcrest Xeons do support speedstep. Also I suspect that there
>> has to be specific support for Xeon processors in this 
>driver? I would
>> really appreciate if you could point me in the right direction.
>
>In general, the newer CPUs require ACPI support to get the right
>operating point parameters for the CPU; only the older Banias Pentium
>M's have support built directly into the driver.  I don't know if Mac
>Pros have ACPI; perhaps there needs to be some other way of 
>getting that
>info out of the BIOS, assuming its there at all.
>

Can you try acpi-cpufreq driver instead. If that doesn't work, probably
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dietz Proepper | 4 Feb 2007 11:57
X-Face
Picon

"new" (aus of 2.6.20) acpi_cpufreq and thinkpad z61m

Hi,

I've been playing around a lttle with a thikpad z61m (core 2 duo cpu,  945 
chipset) and acpi_cpufreq from 2.6.20-rc6 and found the follwoing strage 
behaviour:

Under "normal" circumstances, if I disconnect the ac power, the laptop 
pulls about 18W from the battery when idle (which nearly matchs idle 
consumption under Windows XP and is totally ok for the machine). 

But, every now and then, idle consumption goes up to about 25W, and goes 
down again only after a reboot (suspending to disk and resuming does not 
help). Needlessly to say that max/min frequencies are set to the right 
value and /sys/.../cpuinfo_cur_freq is at the min freq.

It seems that I can reproduce the above behaviour by setting the laptop 
under heavy load for some minutes (building a kernel seems to be 
sufficient).

Any idea?

thx alot,
	Dietz
Permalink | Reply | 2 comments |
headers
Rafał Bilski | 4 Feb 2007 15:58
Picon
Favicon

[PATCH] Longhaul - Fix guess_fsb function


This is bug reported by John-Marc Chandonia:
> Detected 1002.292 MHz processor.
> longhaul: VIA C3 'Nehemiah B' [C5N] CPU detected.  Powersaver supported.
> longhaul: Using throttling support.
> longhaul: Invalid (reserved) FSB!
FSB is correcly guessed for 999.554 MHz CPU.
To fix this error:
- ROUNDING should be range, not mask - at it's current value it is +7 -8,
- more precise calculations inside guess_fsb - 7.5x133MHz is 1000MHz now.

Signed-off-by: Rafal Bilski <rafalbilski <at> interia.pl>
---
 arch/i386/kernel/cpu/cpufreq/longhaul.c |   32 +++++++++---------------------
 1 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
 <at>  <at>  -318,31 +318,19  <at>  <at>  static void longhaul_setstate(unsigned int clock_ratio_index)

 #define ROUNDING	0xf

-static int _guess(int guess, int mult)
-{
-	int target;
-
-	target = ((mult/10)*guess);
-	if (mult%10 != 0)
-		target += (guess/2);
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rafał Bilski | 4 Feb 2007 18:43
Picon
Favicon

[PATCH] Longhaul - Add VT8235 support


I don't know why it is working and how, but it is working. On my 
Epia transition time is by default set to 100us. I'm changing it to 
200us. After that I can change frequency from min (x4.0) to max (x7.5) 
without lockup. Many times.
There is a paranoid check at a beginning of a patch. Probably dead 
code, but I don't have better ideas for CL10000 case at the moment. 
Only way to to detect broken chip seems to be looking in log for 
spurious interrupts.

Signed-off-by: Rafal Bilski <rafalbilski <at> interia.pl>
---
 arch/i386/kernel/cpu/cpufreq/longhaul.c |   62 +++++++++++++++++++++++++------
 1 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c b/arch/i386/kernel/cpu/cpufreq/longhaul.c
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
 <at>  <at>  -56,6 +56,7  <at>  <at> 
 /* Flags */
 #define USE_ACPI_C3		(1 << 1)
 #define USE_NORTHBRIDGE		(1 << 2)
+#define USE_VT8235		(1 << 3)

 static int cpu_model;
 static unsigned int numscales=16;
 <at>  <at>  -544,20 +545,50  <at>  <at>  static int enable_arbiter_disable(void)
 	if (dev != NULL) {
 		/* Enable access to port 0x22 */
 		pci_read_config_byte(dev, reg, &pci_cmd);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Renninger | 5 Feb 2007 00:20
Picon

Re: "new" (aus of 2.6.20) acpi_cpufreq and thinkpad z61m

On Sun, 2007-02-04 at 11:57 +0100, Dietz Proepper wrote:
> Hi,
> 
> I've been playing around a lttle with a thikpad z61m (core 2 duo cpu,  945 
> chipset) and acpi_cpufreq from 2.6.20-rc6 and found the follwoing strage 
> behaviour:
> 
> Under "normal" circumstances, if I disconnect the ac power, the laptop 
> pulls about 18W from the battery when idle (which nearly matchs idle 
> consumption under Windows XP and is totally ok for the machine). 
> 
> But, every now and then, idle consumption goes up to about 25W, and goes 
> down again only after a reboot (suspending to disk and resuming does not 
> help). Needlessly to say that max/min frequencies are set to the right 
> value and /sys/.../cpuinfo_cur_freq is at the min freq.
It could also be the processor sleeping states:
cat /proc/acpi/processor/*/power

Try to unload drivers that could poll hardware and/or produce bus master
activity.
AFAIK this could be some wlan and USB modules and possibly others.

If you want to play a bit with power consumption:
latest -mm kernel should have dyntick patches in, which disables the
frequent
timer interrupt for a while in idle to be able to stay in deeper
sleeping states
for longer time. This should save you (if bus master activity stays low
and userspace
programs do not poll too much) a lot of battery life time.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Benjamin Herrenschmidt | 5 Feb 2007 02:39

Re: CPU hotplug vs. cpufreq on ppc64


> which seems fine. However, when I resume, I get
> [  168.446692] cpufreq-core: resuming cpu 0
> [  168.446708] cpufreq-core: resuming cpu 1
> [  168.446715] cpufreq-core: resuming cpu 2
> [  168.446721] cpufreq-core: resuming cpu 3
> [  168.624880] cpufreq-core: handle_update for cpu 0 called
> [  168.624893] cpufreq-core: updating policy for CPU 0
> [  168.624905] cpufreq-core: setting new policy for CPU 0: 1250000 - 2500000 kHz
> [  168.624965] cpufreq-core: new min and max freqs are 1250000 - 2500000 kHz
> [  168.624974] cpufreq-core: governor: change or update limits
> [  168.624982] cpufreq-core: __cpufreq_governor for CPU 0, event 3
> [  168.625009] cpufreq-core: target for CPU 0: 1250000 kHz, relation 0
> [  169.232726] cpufreq-core: adding CPU 1
> [  169.232741] cpufreq-core: initialization failed
> [  169.239623] cpufreq-core: adding CPU 2
> [  169.239636] cpufreq-core: initialization failed
> [  169.247240] cpufreq-core: adding CPU 3
> [  169.247255] cpufreq-core: initialization failed
> 
> The question now is where this needs to be handled, and how. The driver
> can't really say that it initialised fine because it's still initialised
> on CPU0. However, I suppose that for real CPU hotplug cpufreq can't try
> to remember the pre-unplug groups either...

So you mean that the policy->cpus mask is lost on unplug/replug ? Hrm...
I'm not sure what's the best way to restore it. Do we have a cpufreq
backend callback on hotplug to restore things ?

Ben.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane