# user undervolting

## albright

I've got a fujitsu p7010 centrino and I've heard of a windows

utility that lets you "dynamically" set the cpu voltage (it's

called rightmark). This extends battery life, lowers temperatures,

and reduces fan noise (so I'm told).

Is there any equivalent utility for linux? Or some magic number

you could write to some magic place in /sys or something?

Just curious ...

----------

## moocha

https://forums.gentoo.org/viewtopic-t-284375.html

https://forums.gentoo.org/viewtopic-t-329382.html

https://forums.gentoo.org/viewtopic-t-340193.html

http://www.gentoo.org/doc/en/power-management-guide.xml

Please don't be lazy. Search is there for a reason.

----------

## bollucks

Why assume that cpu frequency control==undervolting? Undervolting is changing the actual core voltage to reduce power usage more than cpu frequency alone can do, and thus also decrease heat and also noise from the cooling. I have yet to see anything that does it in software in linux. There is a utility for later amds on linux but not the centrino as far as I'm aware.

----------

## ian!

 *moocha wrote:*   

> https://forums.gentoo.org/viewtopic-t-284375.html
> 
> https://forums.gentoo.org/viewtopic-t-329382.html
> 
> https://forums.gentoo.org/viewtopic-t-340193.html
> ...

 

Thanks moocha.

Moved from 'Kernel & Hardware'.

----------

## albright

I put up this post:

https://forums.gentoo.org/viewtopic-t-341298-highlight-.html

first in kernel and hardware. It was moved to 

"redundant posts" after a "veteran"

gave a bunch of links to cpufreq discussions

which so far as I could see do not address my

issue ...

I call BS on this one. My question was: is there a utility

(like rightmark for windows) which allows the use

to control the core cpu voltage. This is NOT the same

as the cpufreq and speedstep technology. I wanted

to reduce the core voltage AND run the cpu at

top speed (for obvious reasons plus fun).

So I'm kind of bugged about this.     :Evil or Very Mad: 

----------

## pjp

Clueless users (Moved from OTG).

----------

## Naib

reducing CORE voltage AND increasing switching freqency is not a good idea.

When you increase the switching freqency, the power avaialble in the syncronous clock cannot be gueneteed to be sufficent to ensure it shap is sufficent. Increasing CORE voltage ensure that the clock keeps its profile

That is why you have to increase CORE voltage with increase CPU speed.

This doesnt answer your question, just an aside.

have you googled?

and why insult admins?

----------

## albright

yes, I've googled and I had searched the gentoo forums

At a site devoted to laptops I found that undervolting the fujitsu p7010 (centrino)

has been very successful in windows land. The system

remains stable and battery use, heat and hence fan use

are substantially decreased. So I thought it would be

fun to try in linux if there's a way to do it.

so I asked on kernel & hardware forum, and was moderated

"redundant" and post deleted.

I insult the moderator for not doing his/her job. My post had

nothing to do with cpufreq (ostensible reason for deletion).

I'm too easily annoyed I guess ...

----------

## pilla

AFAIK, cpufreq does both voltage and clock scaling (together)

reference

----------

## pilla

 *Naib wrote:*   

> 
> 
> and why insult admins?

 

It seems to be fashion these days...

----------

## albright

 *Quote:*   

> 
> 
> AFAIK, cpufreq does both voltage and clock scaling (together) 
> 
> 

 

that's great ... now all I need to find out (why won't somebody

just give me a break and *tell* me) how to control the

voltage *independently* of the clock speed (which is what

I wanted and said I wanted in the first place)  :Wink: 

If it can't be done ... well, then it can't be done

I was only wondering if there is a linux equivalent

to the windows utility called rightmark. I got the 

idea when I happened upon a thread in a notebook

enthusiasts webpage and was struck by this comment:

 *Quote:*   

> 
> 
> Undervolting the CPU reduces power consumption, thus 
> 
> allowing your laptop to run cooler and increasing battery life.
> ...

 

The fun of this game apparently is to see how low you can drop

the cpu voltage (not cpu speed) while still having a stable

system (I'm sure you've all fooled with this on your desktop)

but the utility in question lets you do it on laptops. I thought

it would be fun to try in linux but I am sorry to have caused

so much trouble with the moderators ...  :Rolling Eyes: 

----------

## pilla

 *albright wrote:*   

>  *Quote:*   
> 
> AFAIK, cpufreq does both voltage and clock scaling (together) 
> 
>  
> ...

 

I mean... it can't be done. If processors could work reliably with less voltage and the same clock, then I'm sure that the manufactures would release the processors with these settings.

----------

## nixnut

 *pilla wrote:*   

>  *albright wrote:*    *Quote:*   
> 
> AFAIK, cpufreq does both voltage and clock scaling (together) 
> 
>  
> ...

 

Hmm, not necessarily. When churning out wafers of chips, some of these chips will be able to run at different speeds and voltages than others. The selection process and the sorting of it is done not per chip, but usually based on their position on the wafer afaik. This means that you may find yourself in posession of a processor capable of more than it's signed off for. And while overclocking is a notoriously tricky thing for systems on which you compile, underclocking is not as dangerous. Though ofcourse you can take that too far too. Tweaking voltages etc can often be done via the bios screens, sometimes via a tool while an os is running. Finding one for linux however may prove impossible.

Er.. is this thread still in the right place? Not really forums feedback anymore is it?  :Wink: 

----------

## pilla

 *nixnut wrote:*   

> 
> 
> Hmm, not necessarily. When churning out wafers of chips, some of these chips will be able to run at different speeds and voltages than others. The selection process and the sorting of it is done not per chip, but usually based on their position on the wafer afaik. This means that you may find yourself in posession of a processor capable of more than it's signed off for. And while overclocking is a notoriously tricky thing for systems on which you compile, underclocking is not as dangerous. Though ofcourse you can take that too far too. Tweaking voltages etc can often be done via the bios screens, sometimes via a tool while an os is running. Finding one for linux however may prove impossible.

 

I don't consider any overclocked chip to be reliable, and I don't consider undevoltaging processors under the manufacture specifications to be reliable too.

edit: fixed quotation

merged with the previous thread about this subject.

----------

## albright

 *Quote:*   

> 
> 
>  If processors could work reliably with less voltage and the same clock, then I'm sure that the manufactures would release the processors with these settings.
> 
> 

 

As we know from the experience of overclockers, the manufacturers

are usually very conservative in their settings. I suspect that just as overclocking

is possible with various degrees of success dependent on the particular

chip you have, so too undervolting is generally possible ... Anyway,

many people have reported success

For example, there is windows utility for amd processors called

CrystalCPUID which allows undervolting; one user writes:

 *Quote:*   

> 
> 
> CrystalCPUID's configuration process is very time-consuming, but the 
> 
> rewards are beneficial. On my computer, while running at 2 GHz, I was 
> ...

 

The same person added:

 *Quote:*   

> 
> 
> there does not appear to be an equivalent utility for Linux users, 
> 
> who have to resort to modifying the kernel code/driver to attain 
> ...

 

I was asking whether this was still true .... I guess it is  :Crying or Very sad: 

----------

## pilla

Brought back from Dup Threads as the same discussion was going on GFF.

----------

## rschwarze

You can change the voltage manually, if you use the file "speedstep-centrino.c". This file is in the kernel for the old banias centrino, but you could also use it for your dothan or sonoma centrino.

What you have to do:

X86_SPEEDSTEP_CENTRINO_ACPI =n in your kernel, so that the kernel doesn't use the acpi-tables to get the frequency-voltage pairs.

Then you have to edit /usr/src/linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c and recompile the kernel. thats all.

Here is the interesting part of my speedstep-centrino.c, I have already add some dothan and one sonoma centrino and edited the 1.4 Dothan voltages to my favourit values ;) it works very nice, my notebook is cool and quiet now!

struct cpu_id

{

	__u8	x86;            /* CPU family */

	__u8	x86_model;	/* model */

	__u8	x86_mask;	/* stepping */

};

enum {

	CPU_BANIAS,

	CPU_DOTHAN_A1,

	CPU_DOTHAN_A2,

	CPU_DOTHAN_B0,

	CPU_DOTHAN_C0,

};

static const struct cpu_id cpu_ids[] = {

	[CPU_BANIAS]	= { 6,  9, 5 },

	[CPU_DOTHAN_A1]	= { 6, 13, 1 },

	[CPU_DOTHAN_A2]	= { 6, 13, 2 },

	[CPU_DOTHAN_B0]	= { 6, 13, 6 },

	[CPU_DOTHAN_C0]	= { 6, 13, 8 },

};

#define N_IDS	(sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

	const struct cpu_id *cpu_id;

	const char	*model_name;

	unsigned	max_freq; /* max clock in kHz */

	struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)							\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) << 8) | ((mv - 700) / 16)		\

	}

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

	OP(600,  844),

	OP(800,  988),

	OP(900, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

	OP(600,   844),

	OP(800,   972),

	OP(900,   988),

	OP(1000, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

	OP( 600,  956),

	OP( 800, 1020),

	OP( 900, 1100),

	OP(1000, 1164),

	OP(1100, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP( 900, 1020),

	OP(1000, 1100),

	OP(1100, 1164),

	OP(1200, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

	OP( 600,  956),

	OP( 800, 1260),

	OP(1000, 1292),

	OP(1200, 1356),

	OP(1300, 1388),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

	OP( 600,  956),

	OP( 800, 1180),

	OP(1000, 1308),

	OP(1200, 1436),

	OP(1400, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

	OP( 600,  956),

	OP( 800, 1116),

	OP(1000, 1228),

	OP(1200, 1356),

	OP(1400, 1452),

	OP(1500, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1600[] =

{

	OP( 600,  956),

	OP( 800, 1036),

	OP(1000, 1164),

	OP(1200, 1276),

	OP(1400, 1420),

	OP(1600, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP(1000, 1116),

	OP(1200, 1228),

	OP(1400, 1308),

	OP(1700, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each

   frequency (VID#A through VID#D) - this macro allows us to define all

   of these but we only use the VID#C voltages at compile time - this may

   need some work if we want to select the voltage profile at runtime. */

#define OP(mhz, mva, mvb, mvc, mvd)					\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) << 8) | ((mvc - 700) / 16)       	\

	}

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

	OP( 600,  700,  700,  700,  700),

	OP( 800,  770,  770,  770,  770),

	OP(1000,  840,  840,  840,  840),

	OP(1200,  910,  910,  910,  910),

	OP(1400,  980,  980,  980,  980),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1068, 1068, 1068, 1052),

	OP(1000, 1148, 1148, 1132, 1116),

	OP(1200, 1228, 1212, 1212, 1180),

	OP(1500, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1068, 1068, 1052, 1052),

	OP(1000, 1132, 1132, 1116, 1116),

	OP(1200, 1212, 1196, 1180, 1164),

	OP(1400, 1276, 1260, 1244, 1228),

	OP(1600, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1700[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1052),

	OP(1000, 1116, 1116, 1116, 1100),

	OP(1200, 1180, 1180, 1164, 1148),

	OP(1400, 1244, 1244, 1228, 1212),

	OP(1700, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1800[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1036),

	OP(1000, 1116, 1100, 1100, 1084),

	OP(1200, 1164, 1164, 1148, 1132),

	OP(1400, 1228, 1212, 1212, 1180),

	OP(1600, 1292, 1276, 1260, 1228),

	OP(1800, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */

static struct cpufreq_frequency_table dothan_2000[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1036, 1036, 1036),

	OP(1000, 1100, 1084, 1084, 1084),

	OP(1200, 1148, 1132, 1132, 1116),

	OP(1400, 1196, 1180, 1180, 1164),

	OP(1600, 1244, 1228, 1228, 1196),

	OP(1800, 1292, 1276, 1276, 1244),

	OP(2000, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 750 / 1.86GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1867[] =

{

	OP( 800,  880,  880,  880,  880),

	OP(1333, 1010, 1010, 1010, 1010),

	OP(1867, 1120, 1120, 1120, 1120),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

#define _BANIAS(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "MHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= banias_##max,	\

}

#define BANIAS(max)	_BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "GHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= dothan_##max,	\

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

	_BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

	BANIAS(1000),

	BANIAS(1100),

	BANIAS(1200),

	BANIAS(1300),

	BANIAS(1400),

	BANIAS(1500),

	BANIAS(1600),

	BANIAS(1700),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1400, "1.40"),	

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1500, "1.50"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1600, "1.60"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1700, "1.70"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1800, "1.80"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 2000, "2.00"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1867, "1.86"),

	/* NULL model_name is a wildcard */

	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

	{ NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN

----------

## Gentree

 *Quote:*   

> I don't consider any overclocked chip to be reliable

  So my Athlon-XP 1800+ , official clock 1.667GHz that has been running at 2.2GHZ since about 10 months ago without a glitch is unreliable. 

Phew , I'm glad you told me ! 

Luckily my mobo has not caught on yet (ssssh!)   :Wink: 

Manufacturers have to design in some margin for error in other components so on most systems there is some possibility for fine tuning if you know how to adequately test the resulting config.

@albright: cant you alter Vcore from your BIOS? This is the sort I thing I like to handle directly at the lowest level possible and with max ammount of testing.

If the BIOS wont let you alter it I cant see any software being able to do it either .

I have no knowlege of Intel but I have u/c another athlon-xp by one step and it behaved perfectly at std clock rate.

You will need to do some _serious_ testing if you want to play around like this. Read up on cpuburn and memtest86+ for starters.

HTH  :Cool: 

----------

## albright

 *Quote:*   

> @albright: cant you alter Vcore from your BIOS? This is the sort I thing I like to handle directly at the lowest level possible and with max ammount of testing. 
> 
>  If the BIOS wont let you alter it I cant see any software being able to do it either . 
> 
>  I have no knowlege of Intel but I have u/c another athlon-xp by one step and it behaved perfectly at std clock rate. 
> ...

 

My fujitsu p7010 notebook does not have a very powerful bios

setup system and voltage cannot be manipulated.

But there are several windows programs that let you adjust voltage

for this intel chipset.

All I was asking was whether there is an equivalent linux utility. I guess

there is isn't  :Sad: 

Thanks to rschwarze (earlier in thread) who gives some nice info about how to undervolt

via kernel configuration -- which means a recompile for every voltage

tweak -- not so much fun but worth a try! But maybe not this summer,

while my little fujitsu is my only available computer  :Wink: 

----------

## rschwarze

you can test the vcore under windows with "centrino hardware control" and find out what sttings are best for your prcoessor. then change the vcore in the linux-kernel.

if you are interested i can mail you my speedstep-centrino.c file. put in in the kernelsource and recompile with your normal settings (just change the X86_SPEEDSTEP_CENTRINO_ACPI).

Then make a new entry in your bootmanager, and if your system doesn't start you can use the old kernel to boot.

I tried this hack with the kernelversions 2.6.11 and 2.6.12 (gentoo-sources) and it was very easy!

(There was no program like "centrino hardware control" under linux because only the kernel is allowed to change the vcore.)

----------

## albright

 *Quote:*   

> if you are interested i can mail you my speedstep-centrino.c file. put in in the kernelsource and recompile with your normal settings (just change the X86_SPEEDSTEP_CENTRINO_ACPI). 

 

thanks, that would be great. If you get a minute please send it

to cdbroad_at_gmail.com

if I get up the courage I'll post how things went ....

----------

## BetterUnborn

Hmm, very interesting for me, too.

But I can't get it working with my sonoma cntrino and pentium m 730 ... somehow kernel doesn't use the values from the table. In my kernel config, I have

```

CPU_FREQ=y

X86_ACPI_CPUFREQ=y

X86_SPEEDSTEP_CENTRINO=y

X86_SPEEDSTEP_CENTRINO_ACPI=n

X86_SPEEDSTEP_CENTRINO_TABLE=y

```

So there should be nothing wrong with that. In my speedstep-centrino.c I use

```

/* Intel Pentium M processor 730 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

OP( 800, 812, 812, 812, 812),

OP(1067, 700, 700, 700, 700),

OP(1333, 1004, 1004, 1004, 1004),

OP(1600, 1100, 1100, 1100, 1100),

{ .frequency = CPUFREQ_TABLE_END }

};

...

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

   _BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

   BANIAS(1000),

   BANIAS(1100),

   BANIAS(1200),

   BANIAS(1300),

   BANIAS(1400),

   BANIAS(1500),

   BANIAS(1600),

   BANIAS(1700),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1600,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_A1],1600,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_A2],1600,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0],1600,"1.60"),

   /* NULL model_name is a wildcard */

   { &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

   { &cpu_ids[CPU_MP4HT_D0], NULL, 0, NULL },

   { &cpu_ids[CPU_MP4HT_E0], NULL, 0, NULL },

   { NULL, }

};

```

I set the voltage for 1.067 GHz to 700mV for verifying the CPU actually uses the given values. From experiments under windows I know that the system should immediately freeze with that low voltage. But nothing happens!

I don't have any warnings or errors in dmesg.

btw, in the kernel help it says for X86_SPEEDSTEP_CENTRINO_ACPI:

 *Quote:*   

> 
> 
> ...
> 
> It is required for the driver to work on non-Banias CPUs.
> ...

 

So no chance for getting it work for sonoma people??

----------

## Devport

I am in the same situation and try to achieve that with my nforce4 AMD64. Its another geek thing that can be done easily on windows only.

My findings as of yet were that to adjust the cpu voltage the way to go seems to be lmsensors. One needs a module for chipset / chip which sets the cpu voltage. Then there should be a writebale value "vcore" or similar with which one can set the voltage. For me that does not yet work because a pending lmsensors nforce4 patch has not yet been applied to the kernel and a compatible lm87 sensor does not permit to change vcore. But maybe theres a driver for Pentium-M / Intel Chipsets which allows to set vcore in which case one would have to use a patched version of cpufreqd which sets clock and voltage which can be found here

http://punnoor.de/linux_frameset.html

https://forums.gentoo.org/viewtopic-t-273047-highlight-atxp.html

However, changing the kernel voltage table probably is an easier way as long as it works.

----------

## rschwarze

you have to put X86_SPEEDSTEP_CENTRINO_ACPI to "no", because we want the kernel to use the speedstep file for the centrino.

have you change the entry of the sonoma to your values?

in the cpu-models section which you have posted there is no entry for your processor, i think.

edit: i think you should use 1599 mhz. because you have a frontside bus of 533 with a multiplikator of 3.

maybe this is the problem.

edit2: here my speedstep centrino datei. for the sonoma user: you have a frontsidebus of 533. all frequencies should be a multiple of 533. you can change the entry for the 1.87 ghz centrino, because that is a sonoma.

http://www.math.uni-bielefeld.de/~schwarze/speedstep-centrino.c

----------

## albright

I have the same problem as BetterUnborn. My modified 

speedstep-centrino.c file compiles fine and the 

kernel boots properly.

I do have X86_SPEEDSTEP_CENTRINO_ACPI=n set.

But the voltages are not being set. I told the

chip to run on .812 volts at 1100 mhz. In windows,

this instantly crashes the machine. But my

system works normally  :Sad:  (pretty weird, *wanting*

your system to crash)

Here's my modified speedstep-centrino.c file. Maybe

somebody can spot what's wrong - why the system isn't

setting the voltages as per my table

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/init.h>

#include <linux/cpufreq.h>

#include <linux/config.h>

#include <linux/delay.h>

#include <linux/compiler.h>

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

#include <linux/acpi.h>

#include <acpi/processor.h>

#endif

#include <asm/msr.h>

#include <asm/processor.h>

#include <asm/cpufeature.h>

#include "speedstep-est-common.h"

#define PFX		"speedstep-centrino: "

#define MAINTAINER	"Jeremy Fitzhardinge <jeremy@goop.org>"

#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)

struct cpu_id

{

	__u8	x86;            /* CPU family */

	__u8	x86_model;	/* model */

	__u8	x86_mask;	/* stepping */

};

enum {

	CPU_BANIAS,

	CPU_DOTHAN_A1,

	CPU_DOTHAN_A2,

	CPU_DOTHAN_B0,

	CPU_DOTHAN_C0,

};

static const struct cpu_id cpu_ids[] = {

	[CPU_BANIAS]	= { 6,  9, 5 },

	[CPU_DOTHAN_A1]	= { 6, 13, 1 },

	[CPU_DOTHAN_A2]	= { 6, 13, 2 },

	[CPU_DOTHAN_B0]	= { 6, 13, 6 },

	[CPU_DOTHAN_C0]	= { 6, 13, 8 },

};

#define N_IDS	(sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

	const struct cpu_id *cpu_id;

	const char	*model_name;

	unsigned	max_freq; /* max clock in kHz */

	struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)							\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) <<  :Cool:  | ((mv - 700) / 16)		\

	}

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

	OP(600,  844),

	OP(800,  988),

	OP(900, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

	OP(600,   844),

	OP(800,   972),

	OP(900,   988),

	OP(1000, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

	OP( 600,  956),

	OP( 800, 1020),

	OP( 900, 1100),

	OP(1000, 1164),

	OP(1100, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP( 900, 1020),

	OP(1000, 1100),

	OP(1100, 1164),

	OP(1200, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

	OP( 600,  956),

	OP( 800, 1260),

	OP(1000, 1292),

	OP(1200, 1356),

	OP(1300, 1388),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

	OP( 600,  956),

	OP( 800, 1180),

	OP(1000, 1308),

	OP(1200, 1436),

	OP(1400, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

	OP( 600,  956),

	OP( 800, 1116),

	OP(1000, 1228),

	OP(1200, 1356),

	OP(1400, 1452),

	OP(1500, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1600[] =

{

	OP( 600,  956),

	OP( 800, 1036),

	OP(1000, 1164),

	OP(1200, 1276),

	OP(1400, 1420),

	OP(1600, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP(1000, 1116),

	OP(1200, 1228),

	OP(1400, 1308),

	OP(1700, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

 /* Dothan processor datasheet 30218903.pdf defines 4 voltages for each 

 frequency (VID#A through VID#D) - this macro allows us to define all 

 of these but we only use the VID#C voltages at compile time - this may 

 need some work if we want to select the voltage profile at runtime. */ 

 #define OP(mhz, mva, mvb, mvc, mvd) \

 { \

 .frequency = (mhz) * 1000, \

 .index = (((mhz)/100) <<  :Cool:  | ((mvc - 700) / 16) \

 } 

 /* Intel Pentium M processor 733 / 1.10GHz (Dothan) */ 

 static struct cpufreq_frequency_table dothan_1100[] = 

 { 

 OP( 600, 700, 700, 700, 700), 

 OP( 800, 748, 748, 748, 748), 

 OP( 900, 780, 780, 780, 780), 

 OP(1000, 812, 812, 812, 812),

 OP(1100, 812, 812, 812, 812), 

 { .frequency = CPUFREQ_TABLE_END } 

 }; 

#undef OP

#define _BANIAS(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "MHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= banias_##max,	\

}

#define BANIAS(max)	_BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M Processor " name "GHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= dothan_##max,	\

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

	_BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

	BANIAS(1000),

	BANIAS(1100),

	BANIAS(1200),

	BANIAS(1300),

	BANIAS(1400),

	BANIAS(1500),

	BANIAS(1600),

	BANIAS(1700),

	DOTHAN(&cpu_ids[CPU_DOTHAN_A1], 1100, "1.10"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_A2], 1100, "1.10"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1100, "1.10"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1100, "1.10"),

	/* NULL model_name is a wildcard */

	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

	{ NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN

----------

## rschwarze

can you tell me the output of cpufreq-info?

this might be helpfull.

----------

## BetterUnborn

First of all: thx for the fast support!

Yes, the values are for my cpu, windows is running for over one month now and I never had a problem at all (except for the 700mV at 1,067GHz, but thats just for checking out)

I've changed the given sonoma section from 750 to 730

Setting X86_SPEEDSTEP_CENTRINO_ACPI=n doesn't change a thing, after running make the .config is reverted to "not set".

I've tried adding annother section with 1599MHz

```

/* Intel Pentium M processor 730 / 1.599GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1599[] =

{

OP( 800, 812, 812, 812, 812),

OP(1067, 700, 700, 700, 700),

OP(1333, 1004, 1004, 1004, 1004),

OP(1600, 1100, 1100, 1100, 1100),

{ .frequency = CPUFREQ_TABLE_END }

};

```

but in vain, the system still doesn't crash (yes, thats really a weird thing to hope for).

Could it be useful to change the freqency values in the OP(...) lines? As far as I can see the values there should be exactly the same as the bios reports (see /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies)

Apropos "a multiplier of 533": 1866/533 = 3.50094 and 1867/533 = 3.50281 

1866MHz would obviously be more fitting than 1867MHz

There must be annother thing we've overseen so far!

----------

## BetterUnborn

I forgot:

```

styx linux # cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.60GHz

stepping        : 8

cpu MHz         : 797.995

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2

bogomips        : 1576.96

```

----------

## rschwarze

but why do you change the value for 1067 to .700? are you really using this rate? do you set it to this rate by using cpufreq-set -f 1067000?

i don't really understand your test  :Wink: 

(and i don't have a sonoma so i can't check it myself)

edit: becuase of your cpuinfo you really have a sonoma.  :Wink: 

so you have to use  [CPU_DOTHAN_C0]	= { 6, 13, 8 }

(6,8,13 are the values in your output)

but this doesn't help...

----------

## BetterUnborn

Well, I don't want to wait till my fan starts for "quick testing"  :Wink: 

I simply force my cpu to 1.067GHz by typing

```

styx ~ # echo 1067000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

```

with userspace governor enabled. At boot, the cpu is at full speed, and with issuing this command I should have a system freeze.

----------

## rschwarze

okay. what is the output of cpufreq-info? (btw: what kernel are you using?)

my output is like this:

tux-acer roman # cpufreq-info

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 600 MHz - 1.40 GHz

  available frequency steps: 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 600 MHz and 1.40 GHz.

                  The governor "ondemand" may decide which speed to use

                  within this range.

  current CPU frequency is 600 MHz (asserted by call to hardware).

----------

## BetterUnborn

I use gentoo-sources-2.6.12-r4

cpufreq-info shows a possible problem ...

```

styx linux # cpufreq-info

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: acpi-cpufreq

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 800 MHz - 1.60 GHz

  available frequency steps: 1.60 GHz, 1.33 GHz, 1.07 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 1.60 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 1.07 GHz.

```

I didn't think of that  :Embarassed: 

I still had the ACPI driver for processor p-states enabled (CONFIG_X86_ACPI_CPUFREQ=y)

Let's see whats going on after a recompile!

----------

## BetterUnborn

Recompiling didn't help at all ...

the speedstep-centrino driver won't load  :Evil or Very Mad: 

```

styx ~ # modprobe speedstep-centrino

FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.12-gentoo-r4/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device

```

No difference if its compiled-in or a module 

```

styx ~ # cpufreq-info

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  no or unknown cpufreq driver is active on this CPU

```

Seems like the warning that ACPI-tables are mandatory for non-banias cpus should be taken seriously. Is there maybe a way to trick the driver into loading and *assuming* it uses values from ACPI tables?

Or, just the other way round: Is anyone out there whogot it working with a post-Banias Pentium M??

----------

## rschwarze

yes of course! i have a dothan pentium m 710 ! you see it in my centrino-sppedstep file.

i don't know, why the kernel option don't do it for you. what kernel version do you have? do you make it with menuconfig or do you change the .config manually? i don't have any error at compiling!

this is the interesting part of .config:

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=y

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=y

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

# CONFIG_X86_SPEEDSTEP_ICH is not set

# CONFIG_X86_SPEEDSTEP_SMI is not set

# CONFIG_X86_P4_CLOCKMOD is not set

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

#

# shared options

#

CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y

# CONFIG_X86_SPEEDSTEP_LIB is not set

i would say, change the frequency values and these things until the kernel compile cleanly  :Rolling Eyes: 

sorry, i don't have any better ideas

----------

## BetterUnborn

I have exactly the same settings ... doesn't work for me.

Things get weirder by minute ... I can't load the speedstep-centrino driver even if I enable CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI!!

It keeps reporting "no such device", so no chance to seeing the wanted "centrino" as driver for my speedstep.

My kernel does compile cleanly, no errors and/or warnings

I can only test with a reboot

----------

## rschwarze

i don't think thats weired. i think in your speedstep-centrino there is no entry which your kernel thinks is okay for your processor. so i would try to fix the speedstep centrino file  :Confused: 

----------

## BetterUnborn

Got it! Got it! Got it!

 :Very Happy:   :Very Happy:   :Very Happy: 

My Bad, I got a typo in my speedstep-centrino.c ... wrote "1.6" instead of 1.60"  :Embarassed: 

Now here's my interesting section:

```

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1600,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1599,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1598,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1597,"1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1596,"1.60"),

```

I don't know, which one exactly is used, maybe I'll try out later.

But one cool opportunity came along: why not use the table to add new entries? Something about going *below* 800 MHz (which is in most cases over-sufficient)

Well, here it comes:

```

/* Intel Pentium M processor 730 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

OP( 533, 812, 812, 812, 812),

OP( 800, 908, 908, 908, 908),

OP(1067, 1004, 1004, 1004, 1004),

OP(1333, 1100, 1100, 1100, 1100),

OP(1600, 1100, 1100, 1100, 1100),

{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

```

Just added a 533MHz entry, and voila, it is used like the others

Quite annoying: in linux I can't reduce my voltages as much as under windows ... 812 mV for 800MHz is rock-solid under Windows ... in Linux I get an immediate system crash. Maybe I can improve the 908mV, but with 533MHz as the lowest entry this is almost permanently used, so I shouldn't bother too much about the 800MHz any more  :Cool: 

Now my system is quite "cool"

----------

## rschwarze

That's cool that you got it. i hope that albright fix his problems, too.

yes, you can use lower frequencies. I use this table at the moment. my only problem ist, that you can't use voltage lower then 0.700 volt.

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

        OP( 400,  700,  700,  700,  700),

        OP( 600,  700,  700,  700,  700),

        OP( 800,  750,  750,  750,  750),

        OP(1000,  810,  810,  810,  810),

        OP(1200,  870,  870,  870,  870),

        OP(1400,  920,  920,  920,  920),

        { .frequency = CPUFREQ_TABLE_END }

};

----------

## albright

I followed rschwarze's config file more slavishly and now mine

works as well.

 :Razz:   :Razz:  It's great.

this is the table I am using right now:

 /* Intel Pentium M processor 733 / 1.10GHz (Dothan) */

 static struct cpufreq_frequency_table dothan_1100[] =

 {

 	OP( 500, 700, 700, 700, 700),

 	OP( 600, 700, 700, 700, 700),

 	OP( 800, 748, 748, 748, 748),

 	OP( 900, 780, 780, 780, 780),

 	OP(1000, 812, 812, 812, 812),

 	OP(1100, 828, 828, 828, 828),

 	{ .frequency = CPUFREQ_TABLE_END }

 };

I added the 500mhz line and the system uses it ...

Now I'll try to see what kind of a difference it makes to

battery life (too bad the p7010 does not have working temp

monitors! - not even in windows).

Many thanks to rschwarze and BetterUnBorn

----------

## Antimatter

Sorry for this thread necromancy, but anyway I changed my file and now my cpufreq-info has this output.

```

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 200 MHz - 1.70 GHz

  available frequency steps: 200 MHz, 400 MHz, 700 MHz, 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz, 1.70 GHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 200 MHz and 1.70 GHz.

                  The governor "userspace" may decide which speed to use

                  within this range.

  current CPU frequency is 600 MHz (asserted by call to hardware).

```

Then I'll enable and set the minimum acceptable frequency to 200MHz, then set the current frequency to 200MHz and yet i kept on getting snapped back to 600MHz and can't get it to go any low, nor can I get it to go to say 700MHz it has to be 600 or 800.

So I'm wondering how you guys got yours to drop even lower?

[edit]: Hardware information may be a good idea  :Smile: 

Pentium-M 735 Aka 1.70 Ghz Dothan.  And its an IBM Thinkpad T42, also here's my cpu freq addition to the file below

```

/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */

/* Going to try to add a few more frequency levels for starter */

static struct cpufreq_frequency_table dothan_1700[] =

{

OP( 200, 988, 988, 988, 988),

OP( 400, 988, 988, 988, 988),

OP( 700, 988, 988, 988, 988),

OP( 600, 988, 988, 988, 988),

OP( 800, 1052, 1052, 1052, 1052),

OP(1000, 1116, 1116, 1116, 1100), 

OP(1200, 1180, 1180, 1164, 1148),

OP(1400, 1244, 1244, 1228, 1212),

OP(1700, 1340, 1324, 1308, 1276),

{ .frequency = CPUFREQ_TABLE_END }

};

```

And ofc a few other macros and so forth all over the file, it detects and changes the frequency correctly, it just won't go below 600MHz or do an "non" 200MHz step.

----------

## rschwarze

Yes you are right. I don't can go deeper with my frequency. He says it was deeper but when I check it, it isn't really deeper.

So, maybe it isn't possible to go to other frequencies then the normal ones.

----------

## Antimatter

 *rschwarze wrote:*   

> Yes you are right. I don't can go deeper with my frequency. He says it was deeper but when I check it, it isn't really deeper.
> 
> So, maybe it isn't possible to go to other frequencies then the normal ones.

 

I have no idea, but iirc an recent discussion that i read about the Pentium-M is that it has several multiplier between 6 to 20x and that "speedstep" changes the multiplier from 6x to the cpu max top speed, like mine to about 17x I think.  But I'm not sure why the cpu can't change frequency that are in between, like 600MHz to 700MHz then 800MHz, instead it can only do 200MHz jumps, with exception of the "odd" number for the max cpu frequency such as 1700MHz

----------

## rschwarze

for me the only odd frequency i can take is 1100. i have tested them all, but only the frequencies 600, 800, 1000, 1100, 1200, 1400 work.

----------

## Antimatter

 *rschwarze wrote:*   

> for me the only odd frequency i can take is 1100. i have tested them all, but only the frequencies 600, 800, 1000, 1100, 1200, 1400 work.

 

Pretty much the same results, I can only really switch to the frequency already listed/supported by the chip, so i guess this going under 600 MHz is something else, because I've seen screen shot under windows that had the cpu go under 600MHz but when i think about it, it maybe an combation of cpu frequency down to 600MHz + some form of throttling, now the throttling isn't true frequency drop but it would "appear" to the user to drop to that frequency.

----------

## knefas

Hi, I'm trying to get this working for me (1.60Mhz Sonoma). I've modified speedstep-centrino.c as said (I hope!) basically adding 

```
/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

        OP( 600,  988,  988,  988,  988),

        OP( 800, 1068, 1068, 1052, 1052),

        OP(1000, 1132, 1132, 1116, 1116),

        OP(1200, 1212, 1196, 1180, 1164),

        OP(1400, 1276, 1260, 1244, 1228),

        OP(1600, 1340, 1324, 1308, 1276),

        { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1599[] =

{

        OP( 600,  988,  988,  988,  988),

        OP( 800, 1068, 1068, 1052, 1052),

        OP(1000, 1132, 1132, 1116, 1116),

        OP(1200, 1212, 1196, 1180, 1164),

        OP(1400, 1276, 1260, 1244, 1228),

        OP(1599, 1340, 1324, 1308, 1276),

        { .frequency = CPUFREQ_TABLE_END }

}
```

my /proc/cpu shows 

```
delphi linux # cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.60GHz

stepping        : 8

cpu MHz         : 798.020

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2

bogomips        : 1568.76

```

I do have CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=n but modprobe speedstep-centrino reports: 

```
FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.12-gentoo-r9/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): Device or resource busy
```

 anyone can help me?  :Smile: 

----------

## rschwarze

i don't think it works as a module. try to compile it into the kernel.

you have to remove the 1,6 dothan, so that he knows which table to use.

----------

## knefas

thanks a lot for the quick answer, in fact compiling built-in and removing dothan-1600 solved it.  :Smile:  Now it is a bit cooler and much more quiet!

EDIT: unfortunately not so cool and not so quiet...just a little  :Neutral: 

----------

## rschwarze

are the voltage values you are using really the deepest values that works for you?

when you look at my values for the 1,4 dothan you will see that my values are much lower! maybe you can try to use lower voltage? because the heat is quadratic proportional to the voltage!

----------

## knefas

```
/* Intel Pentium M processor 725 / 1.60GHz (Sonoma) */

static struct cpufreq_frequency_table dothan_1599[] =

{

        OP( 800, 750, 750, 750, 750),

        OP(1000, 828, 828, 828, 828),

        OP(1200, 900, 900, 900, 900),

        OP(1400, 908, 908, 908, 908),

        OP(1600, 908, 908, 908, 908),

        { .frequency = CPUFREQ_TABLE_END }

};
```

this is my table, I cant go any lower with 800 or I get a freeze. As you see I concentraded expecially on 800 and 1600. But the heat for 800 is the same as before.

BTW: why there are 4 voltage numbers? I've seen in your file that they are different...I set them all the same, but what that means? Can we use any voltage? 

(Thanks a lot for your help!)  :Smile: 

----------

## rschwarze

i don't know what the four voltage numbers mean.

but if you have the same heat with 750 mv as with 900 mv than something is wrong. i think you should check if this is really the voltage table the kernel is using. you can do so by adding a funny new frequency, for example 170 mhz. the kernel will not really use this voltage but you will see it when you type cpufreq-info.

if you are sure, that the kernel uses this table, then the current temperature is the best you can get.

btw, which temperature do you get in idle mode? and which temperature while compiling?

----------

## Grooby

just out of curiousity, has anyone done any battery benchmark?  how much extra time do you get out of these undervolted CPUs?

----------

## knefas

 *rschwarze wrote:*   

> i don't know what the four voltage numbers mean.
> 
> btw, which temperature do you get in idle mode? and which temperature while compiling?

 

I get 55C idle, and 60/61C compiling (1600 @ 0.908 volt). Before @ 1600 I got over 76, so this is very very good. 

I've added a dummy mode (200) and cpufreq-info is showing it.

The only thing (one of the many things, actually!  :Wink:  ) I don't understand is why on Windows I can go 800 @ 0.700 Volt and here in Linux a have to run at least 0.750 Volt. On Win I can stay 49C idle, here I can't go lower than 54. That's quite a mistery!

----------

## rschwarze

someone in this thread says, that he can do lower voltage when he use 600 mhz. this is a bit strange, because i don't think that the processor really use the 600 mhz. but maybe it is worse a try.

my idle temperature is about 48-50°C.

during long compilation my temperature goes up to 60 degrees, but then the cooler cooles it down to 50 degrees again.

@grooby: for me the battery time in idle mode is 4h without and 4.5h with undervolting. but thats not so important for me. without undervolting my cooler runs nearly all the time and the notebook is very hot (which isn't good for the battery, for example). with the undervolting, the cooler runs only during compilation and not all the time but 40% i think.

----------

## Matt.Shure

Hi, 

I didn't manage to get it working for me, can you help me? I'm running Suse 9.3 (Kernel 2.6.11.4-21.9), but I think that won't make any difference, am I right? 

My System is a Samsung X20 1600V, powered by an Intel Centrino 1,60Ghz Prozessor (Modelnumber 730, codename sonoma) 

Perhaps anyone who has the same processor can post his complete speedstep-centrino.c? 

Thank you!

And is there any programm that can read the vcore actually used by the kernel? 

I think I followed all hints posted in this thread, but it didn't seem to work. cpufreq-info still says 

cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004

Bitte melden Sie Fehler an linux@brodo.de.

analysiere CPU 0:

  Treiber: acpi-cpufreq

  Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0

  Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 1.60 GHz

  mögliche Taktfrequenzen: 1.60 GHz, 1.33 GHz, 1.07 GHz, 800 MHz

  mögliche Regler: userspace, performance

  momentane Taktik: die Frequenz soll innerhalb 800 MHz und 1.60 GHz.

                    liegen. Der Regler "userspace" kann frei entscheiden,

                    welche Taktfrequenz innerhalb dieser Grenze verwendet wird.

  momentane Taktfrequenz ist 800 MHz.

My config files: 

.config 

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=m

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=m

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

# CONFIG_X86_SPEEDSTEP_ICH is not set

# CONFIG_X86_SPEEDSTEP_SMI is not set

# CONFIG_X86_P4_CLOCKMOD is not set

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

#

# shared options

#

CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y

#

# Bus options (PCI, PCMCIA, EISA, MCA, ISA)

#

CONFIG_PCI=y

# CONFIG_PCI_GOBIOS is not set

# CONFIG_PCI_GOMMCONFIG is not set

# CONFIG_PCI_GODIRECT is not set

CONFIG_PCI_GOANY=y

CONFIG_PCI_BIOS=y

CONFIG_PCI_DIRECT=y

CONFIG_PCI_MMCONFIG=y

CONFIG_PCIEPORTBUS=y

CONFIG_HOTPLUG_PCI_PCIE=m

# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set

CONFIG_PCI_MSI=y

# CONFIG_PCI_LEGACY_PROC is not set

# CONFIG_PCI_NAMES is not set

CONFIG_ISA=y

# CONFIG_EISA is not set

# CONFIG_MCA is not set

CONFIG_SCx200=m

speedstep-centrino.c 

/*

 * cpufreq driver for Enhanced SpeedStep, as found in Intel's Pentium

 * M (part of the Centrino chipset).

 *

 * Despite the "SpeedStep" in the name, this is almost entirely unlike

 * traditional SpeedStep.

 *

 * Modelled on speedstep.c

 *

 * Copyright (C) 2003 Jeremy Fitzhardinge <jeremy@goop.org>

 *

 * WARNING WARNING WARNING

 *

 * This driver manipulates the PERF_CTL MSR, which is only somewhat

 * documented.  While it seems to work on my laptop, it has not been

 * tested anywhere else, and it may not work for you, do strange

 * things or simply crash.

 */

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/init.h>

#include <linux/cpufreq.h>

#include <linux/config.h>

#include <linux/delay.h>

#include <linux/compiler.h>

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

#include <linux/acpi.h>

#include <acpi/processor.h>

#endif

#include <asm/msr.h>

#include <asm/processor.h>

#include <asm/cpufeature.h>

#include "speedstep-est-common.h"

#define PFX		"speedstep-centrino: "

#define MAINTAINER	"Jeremy Fitzhardinge <jeremy@goop.org>"

#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)

struct cpu_id

{

	__u8	x86;            /* CPU family */

	__u8	x86_model;	/* model */

	__u8	x86_mask;	/* stepping */

};

enum {

	CPU_BANIAS,

	CPU_DOTHAN_A1,

	CPU_DOTHAN_A2,

	CPU_DOTHAN_B0,

	CPU_DOTHAN_C0,

};

static const struct cpu_id cpu_ids[] = {

	[CPU_BANIAS]	= { 6,  9, 5 },

	[CPU_DOTHAN_A1]	= { 6, 13, 1 },

	[CPU_DOTHAN_A2]	= { 6, 13, 2 },

	[CPU_DOTHAN_B0]	= { 6, 13, 6 },

	[CPU_DOTHAN_C0]	= { 6, 13, 8 },

};

#define N_IDS	(sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

	const struct cpu_id *cpu_id;

	const char	*model_name;

	unsigned	max_freq; /* max clock in kHz */

	struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)							\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) <<  :Cool:  | ((mv - 700) / 16)		\

	}

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

	OP(600,  844),

	OP(800,  988),

	OP(900, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

	OP(600,   844),

	OP(800,   972),

	OP(900,   988),

	OP(1000, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

	OP( 600,  956),

	OP( 800, 1020),

	OP( 900, 1100),

	OP(1000, 1164),

	OP(1100, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP( 900, 1020),

	OP(1000, 1100),

	OP(1100, 1164),

	OP(1200, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

	OP( 600,  956),

	OP( 800, 1260),

	OP(1000, 1292),

	OP(1200, 1356),

	OP(1300, 1388),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

	OP( 600,  956),

	OP( 800, 1180),

	OP(1000, 1308),

	OP(1200, 1436),

	OP(1400, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

	OP( 600,  956),

	OP( 800, 1116),

	OP(1000, 1228),

	OP(1200, 1356),

	OP(1400, 1452),

	OP(1500, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1600[] =

{

	OP( 600,  956),

	OP( 800, 1036),

	OP(1000, 1164),

	OP(1200, 1276),

	OP(1400, 1420),

	OP(1600, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP(1000, 1116),

	OP(1200, 1228),

	OP(1400, 1308),

	OP(1700, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each

   frequency (VID#A through VID#D) - this macro allows us to define all

   of these but we only use the VID#C voltages at compile time - this may

   need some work if we want to select the voltage profile at runtime. */

#define OP(mhz, mva, mvb, mvc, mvd)					\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) <<  :Cool:  | ((mvc - 700) / 16)       	\

	}

 /* Intel Pentium M processor 733 / 1.10GHz (Dothan) */

 static struct cpufreq_frequency_table dothan_1100[] =

{

 	OP( 500, 700, 700, 700, 700),

 	OP( 600, 700, 700, 700, 700),

 	OP( 800, 748, 748, 748, 748),

 	OP( 900, 764, 764, 764, 764),

 	OP(1000, 812, 812, 812, 812),

 	OP(1100, 844, 844, 844, 844),

 	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

	OP( 400,  700,  700,  700,  700),

	OP( 600,  700,  700,  700,  700),

	OP( 800,  750,  750,  750,  750),

	OP(1000,  810,  810,  810,  810),

	OP(1200,  870,  870,  870,  870),

	OP(1400,  920,  920,  920,  920),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1068, 1068, 1068, 1052),

	OP(1000, 1148, 1148, 1132, 1116),

	OP(1200, 1228, 1212, 1212, 1180),

	OP(1500, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

	OP( 600,  800,  988,  988,  988),

	OP( 800,  800, 1068, 1052, 1052),

	OP(1000, 1132, 1132, 1116, 1116),

	OP(1200, 1212, 1196, 1180, 1164),

	OP(1400, 1276, 1260, 1244, 1228),

	OP(1600, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1700[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1052),

	OP(1000, 1116, 1116, 1116, 1100),

	OP(1200, 1180, 1180, 1164, 1148),

	OP(1400, 1244, 1244, 1228, 1212),

	OP(1700, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1800[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1036),

	OP(1000, 1116, 1100, 1100, 1084),

	OP(1200, 1164, 1164, 1148, 1132),

	OP(1400, 1228, 1212, 1212, 1180),

	OP(1600, 1292, 1276, 1260, 1228),

	OP(1800, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */

static struct cpufreq_frequency_table dothan_2000[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1036, 1036, 1036),

	OP(1000, 1100, 1084, 1084, 1084),

	OP(1200, 1148, 1132, 1132, 1116),

	OP(1400, 1196, 1180, 1180, 1164),

	OP(1600, 1244, 1228, 1228, 1196),

	OP(1800, 1292, 1276, 1276, 1244),

	OP(2000, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 750 / 1.86GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1867[] =

{

	OP( 800,  880,  880,  880,  880),

	OP(1333, 1010, 1010, 1010, 1010),

	OP(1867, 1120, 1120, 1120, 1120),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

#define _BANIAS(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "MHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= banias_##max,	\

}

#define BANIAS(max)	_BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "GHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= dothan_##max,	\

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

	_BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

	BANIAS(1000),

	BANIAS(1100),

	BANIAS(1200),

	BANIAS(1300),

	BANIAS(1400),

	BANIAS(1500),

	BANIAS(1600),

	BANIAS(1700),

        DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1100, "1.10"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1400, "1.40"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1500, "1.50"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1600, "1.60"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1700, "1.70"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1800, "1.80"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 2000, "2.00"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1867, "1.86"),

	/* NULL model_name is a wildcard */

	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

	{ NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN

static int centrino_cpu_init_table(struct cpufreq_policy *policy)

{

	struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

	struct cpu_model *model;

	for(model = models; model->cpu_id != NULL; model++)

		if (centrino_verify_cpu_id(cpu, model->cpu_id) &&

		    (model->model_name == NULL ||

		     strcmp(cpu->x86_model_id, model->model_name) == 0))

			break;

	if (model->cpu_id == NULL) {

		/* No match at all */

		dprintk(KERN_INFO PFX "no support for CPU model \"%s\": "

		       "send /proc/cpuinfo to " MAINTAINER "\n",

		       cpu->x86_model_id);

		return -ENOENT;

	}

	if (model->op_points == NULL) {

		/* Matched a non-match */

		dprintk(KERN_INFO PFX "no table support for CPU model \"%s\": \n",

		       cpu->x86_model_id);

#ifndef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

		dprintk(KERN_INFO PFX "try compiling with CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled\n");

#endif

		return -ENOENT;

	}

	centrino_model[policy->cpu] = model;

	dprintk("found \"%s\": max frequency: %dkHz\n",

	       model->model_name, model->max_freq);

	return 0;

}

#else

static inline int centrino_cpu_init_table(struct cpufreq_policy *policy) { return -ENODEV; }

#endif /* CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE */

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x)

{

	if ((c->x86 == x->x86) &&

	    (c->x86_model == x->x86_model) &&

	    (c->x86_mask == x->x86_mask))

		return 1;

	return 0;

}

/* To be called only after centrino_model is initialized */

static unsigned extract_clock(unsigned msr, unsigned int cpu, int failsafe)

{

	int i;

	/*

	 * Extract clock in kHz from PERF_CTL value

	 * for centrino, as some DSDTs are buggy.

	 * Ideally, this can be done using the acpi_data structure.

	 */

	if ((centrino_cpu[cpu] == &cpu_ids[CPU_BANIAS]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_A1]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_B0]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_C0])) {

		msr = (msr >>  :Cool:  & 0xff;

		return msr * 100000;

	}

	if ((!centrino_model[cpu]) || (!centrino_model[cpu]->op_points))

		return 0;

	msr &= 0xffff;

	for (i=0;centrino_model[cpu]->op_points[i].frequency != CPUFREQ_TABLE_END; i++) {

		if (msr == centrino_model[cpu]->op_points[i].index)

			return centrino_model[cpu]->op_points[i].frequency;

	}

	if (failsafe)

		return centrino_model[cpu]->op_points[i-1].frequency;

	else

		return 0;

}

/* Return the current CPU frequency in kHz */

static unsigned int get_cur_freq(unsigned int cpu)

{

	unsigned l, h;

	unsigned clock_freq;

	cpumask_t saved_mask;

	saved_mask = current->cpus_allowed;

	set_cpus_allowed(current, cpumask_of_cpu(cpu));

	if (smp_processor_id() != cpu)

		return 0;

	rdmsr(MSR_IA32_PERF_STATUS, l, h);

	clock_freq = extract_clock(l, cpu, 0);

	if (unlikely(clock_freq == 0)) {

		/*

		 * On some CPUs, we can see transient MSR values (which are

		 * not present in _PSS), while CPU is doing some automatic

		 * P-state transition (like TM2). Get the last freq set 

		 * in PERF_CTL.

		 */

		rdmsr(MSR_IA32_PERF_CTL, l, h);

		clock_freq = extract_clock(l, cpu, 1);

	}

	set_cpus_allowed(current, saved_mask);

	return clock_freq;

}

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

static struct acpi_processor_performance p;

/*

 * centrino_cpu_init_acpi - register with ACPI P-States library

 *

 * Register with the ACPI P-States library (part of drivers/acpi/processor.c)

 * in order to determine correct frequency and voltage pairings by reading

 * the _PSS of the ACPI DSDT or SSDT tables.

 */

static int centrino_cpu_init_acpi(struct cpufreq_policy *policy)

{

	union acpi_object		arg0 = {ACPI_TYPE_BUFFER};

	u32				arg0_buf[3];

	struct acpi_object_list		arg_list = {1, &arg0};

	unsigned long			cur_freq;

	int				result = 0, i;

	unsigned int			cpu = policy->cpu;

	/* _PDC settings */

	arg0.buffer.length = 12;

	arg0.buffer.pointer = (u8 *) arg0_buf;

	arg0_buf[0] = ACPI_PDC_REVISION_ID;

	arg0_buf[1] = 1;

	arg0_buf[2] = ACPI_PDC_EST_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_MSR;

	p.pdc = &arg_list;

	/* register with ACPI core */

	if (acpi_processor_register_performance(&p, cpu)) {

		dprintk(KERN_INFO PFX "obtaining ACPI data failed\n");

		return -EIO;

	}

	/* verify the acpi_data */

	if (p.state_count <= 1) {

		dprintk("No P-States\n");

		result = -ENODEV;

		goto err_unreg;

	}

	if ((p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) ||

	    (p.status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)) {

		dprintk("Invalid control/status registers (%x - %x)\n",

			p.control_register.space_id, p.status_register.space_id);

		result = -EIO;

		goto err_unreg;

	}

	for (i=0; i<p.state_count; i++) {

		if (p.states[i].control != p.states[i].status) {

			dprintk("Different control (%x) and status values (%x)\n",

				p.states[i].control, p.states[i].status);

			result = -EINVAL;

			goto err_unreg;

		}

		if (!p.states[i].core_frequency) {

			dprintk("Zero core frequency for state %u\n", i);

			result = -EINVAL;

			goto err_unreg;

		}

		if (p.states[i].core_frequency > p.states[0].core_frequency) {

			dprintk("P%u has larger frequency (%u) than P0 (%u), skipping\n", i,

				p.states[i].core_frequency, p.states[0].core_frequency);

			p.states[i].core_frequency = 0;

			continue;

		}

	}

	centrino_model[cpu] = kmalloc(sizeof(struct cpu_model), GFP_KERNEL);

	if (!centrino_model[cpu]) {

		result = -ENOMEM;

		goto err_unreg;

	}

	memset(centrino_model[cpu], 0, sizeof(struct cpu_model));

	centrino_model[cpu]->model_name=NULL;

	centrino_model[cpu]->max_freq = p.states[0].core_frequency * 1000;

	centrino_model[cpu]->op_points =  kmalloc(sizeof(struct cpufreq_frequency_table) *

					     (p.state_count + 1), GFP_KERNEL);

        if (!centrino_model[cpu]->op_points) {

                result = -ENOMEM;

                goto err_kfree;

        }

        for (i=0; i<p.state_count; i++) {

		centrino_model[cpu]->op_points[i].index = p.states[i].control;

		centrino_model[cpu]->op_points[i].frequency = p.states[i].core_frequency * 1000;

		dprintk("adding state %i with frequency %u and control value %04x\n", 

			i, centrino_model[cpu]->op_points[i].frequency, centrino_model[cpu]->op_points[i].index);

	}

	centrino_model[cpu]->op_points[p.state_count].frequency = CPUFREQ_TABLE_END;

	cur_freq = get_cur_freq(cpu);

	for (i=0; i<p.state_count; i++) {

		if (!p.states[i].core_frequency) {

			dprintk("skipping state %u\n", i);

			centrino_model[cpu]->op_points[i].frequency = CPUFREQ_ENTRY_INVALID;

			continue;

		}

		if (extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0) !=

		    (centrino_model[cpu]->op_points[i].frequency)) {

			dprintk("Invalid encoded frequency (%u vs. %u)\n",

				extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0),

				centrino_model[cpu]->op_points[i].frequency);

			result = -EINVAL;

			goto err_kfree_all;

		}

		if (cur_freq == centrino_model[cpu]->op_points[i].frequency)

			p.state = i;

	}

	/* notify BIOS that we exist */

	acpi_processor_notify_smm(THIS_MODULE);

	return 0;

 err_kfree_all:

	kfree(centrino_model[cpu]->op_points);

 err_kfree:

	kfree(centrino_model[cpu]);

 err_unreg:

	acpi_processor_unregister_performance(&p, cpu);

	dprintk(KERN_INFO PFX "invalid ACPI data\n");

	return (result);

}

#else

static inline int centrino_cpu_init_acpi(struct cpufreq_policy *policy) { return -ENODEV; }

#endif

static int centrino_cpu_init(struct cpufreq_policy *policy)

{

	struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

	unsigned freq;

	unsigned l, h;

	int ret;

	int i;

	/* Only Intel makes Enhanced Speedstep-capable CPUs */

	if (cpu->x86_vendor != X86_VENDOR_INTEL || !cpu_has(cpu, X86_FEATURE_EST))

		return -ENODEV;

	for (i = 0; i < N_IDS; i++)

		if (centrino_verify_cpu_id(cpu, &cpu_ids[i]))

			break;

	if (i != N_IDS)

		centrino_cpu[policy->cpu] = &cpu_ids[i];

	if (is_const_loops_cpu(policy->cpu)) {

		centrino_driver.flags |= CPUFREQ_CONST_LOOPS;

	}

	if (centrino_cpu_init_acpi(policy)) {

		if (policy->cpu != 0)

			return -ENODEV;

		if (!centrino_cpu[policy->cpu]) {

			dprintk(KERN_INFO PFX "found unsupported CPU with "

			"Enhanced SpeedStep: send /proc/cpuinfo to "

			MAINTAINER "\n");

			return -ENODEV;

		}

		if (centrino_cpu_init_table(policy)) {

			return -ENODEV;

		}

	}

	/* Check to see if Enhanced SpeedStep is enabled, and try to

	   enable it if not. */

	rdmsr(MSR_IA32_MISC_ENABLE, l, h);

	if (!(l & (1<<16))) {

		l |= (1<<16);

		dprintk("trying to enable Enhanced SpeedStep (%x)\n", l);

		wrmsr(MSR_IA32_MISC_ENABLE, l, h);

		/* check to see if it stuck */

		rdmsr(MSR_IA32_MISC_ENABLE, l, h);

		if (!(l & (1<<16))) {

			printk(KERN_INFO PFX "couldn't enable Enhanced SpeedStep\n");

			return -ENODEV;

		}

	}

	freq = get_cur_freq(policy->cpu);

	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;

	policy->cpuinfo.transition_latency = 10000; /* 10uS transition latency */

	policy->cur = freq;

	dprintk("centrino_cpu_init: cur=%dkHz\n", policy->cur);

	ret = cpufreq_frequency_table_cpuinfo(policy, centrino_model[policy->cpu]->op_points);

	if (ret)

		return (ret);

	cpufreq_frequency_table_get_attr(centrino_model[policy->cpu]->op_points, policy->cpu);

	return 0;

}

static int centrino_cpu_exit(struct cpufreq_policy *policy)

{

	unsigned int cpu = policy->cpu;

	if (!centrino_model[cpu])

		return -ENODEV;

	cpufreq_frequency_table_put_attr(cpu);

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

	if (!centrino_model[cpu]->model_name) {

		dprintk("unregistering and freeing ACPI data\n");

		acpi_processor_unregister_performance(&p, cpu);

		kfree(centrino_model[cpu]->op_points);

		kfree(centrino_model[cpu]);

	}

#endif

	centrino_model[cpu] = NULL;

	return 0;

}

/**

 * centrino_verify - verifies a new CPUFreq policy

 * @policy: new policy

 *

 * Limit must be within this model's frequency range at least one

 * border included.

 */

static int centrino_verify (struct cpufreq_policy *policy)

{

	return cpufreq_frequency_table_verify(policy, centrino_model[policy->cpu]->op_points);

}

/**

 * centrino_setpolicy - set a new CPUFreq policy

 * @policy: new policy

 * @target_freq: the target frequency

 * @relation: how that frequency relates to achieved frequency (CPUFREQ_RELATION_L or CPUFREQ_RELATION_H)

 *

 * Sets a new CPUFreq policy.

 */

static int centrino_target (struct cpufreq_policy *policy,

			    unsigned int target_freq,

			    unsigned int relation)

{

	unsigned int    newstate = 0;

	unsigned int	msr, oldmsr, h, cpu = policy->cpu;

	struct cpufreq_freqs	freqs;

	cpumask_t		saved_mask;

	int			retval;

	if (centrino_model[cpu] == NULL)

		return -ENODEV;

	/*

	 * Support for SMP systems.

	 * Make sure we are running on the CPU that wants to change frequency

	 */

	saved_mask = current->cpus_allowed;

	set_cpus_allowed(current, policy->cpus);

	if (!cpu_isset(smp_processor_id(), policy->cpus)) {

		dprintk("couldn't limit to CPUs in this domain\n");

		return(-EAGAIN);

	}

	if (cpufreq_frequency_table_target(policy, centrino_model[cpu]->op_points, target_freq,

					   relation, &newstate)) {

		retval = -EINVAL;

		goto migrate_end;

	}

	msr = centrino_model[cpu]->op_points[newstate].index;

	rdmsr(MSR_IA32_PERF_CTL, oldmsr, h);

	if (msr == (oldmsr & 0xffff)) {

		retval = 0;

		dprintk("no change needed - msr was and needs to be %x\n", oldmsr);

		goto migrate_end;

	}

	freqs.cpu = cpu;

	freqs.old = extract_clock(oldmsr, cpu, 0);

	freqs.new = extract_clock(msr, cpu, 0);

	dprintk("target=%dkHz old=%d new=%d msr=%04x\n",

		target_freq, freqs.old, freqs.new, msr);

	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);

	/* all but 16 LSB are "reserved", so treat them with

	   care */

	oldmsr &= ~0xffff;

	msr &= 0xffff;

	oldmsr |= msr;

	wrmsr(MSR_IA32_PERF_CTL, oldmsr, h);

	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);

	retval = 0;

migrate_end:

	set_cpus_allowed(current, saved_mask);

	return (retval);

}

static struct freq_attr* centrino_attr[] = {

	&cpufreq_freq_attr_scaling_available_freqs,

	NULL,

};

static struct cpufreq_driver centrino_driver = {

	.name		= "centrino", /* should be speedstep-centrino,

					 but there's a 16 char limit */

	.init		= centrino_cpu_init,

	.exit		= centrino_cpu_exit,

	.verify		= centrino_verify,

	.target		= centrino_target,

	.get		= get_cur_freq,

	.attr           = centrino_attr,

	.owner		= THIS_MODULE,

};

/**

 * centrino_init - initializes the Enhanced SpeedStep CPUFreq driver

 *

 * Initializes the Enhanced SpeedStep support. Returns -ENODEV on

 * unsupported devices, -ENOENT if there's no voltage table for this

 * particular CPU model, -EINVAL on problems during initiatization,

 * and zero on success.

 *

 * This is quite picky.  Not only does the CPU have to advertise the

 * "est" flag in the cpuid capability flags, we look for a specific

 * CPU model and stepping, and we need to have the exact model name in

 * our voltage tables.  That is, be paranoid about not releasing

 * someone's valuable magic smoke.

 */

static int __init centrino_init(void)

{

	struct cpuinfo_x86 *cpu = cpu_data;

	if (!cpu_has(cpu, X86_FEATURE_EST))

		return -ENODEV;

	return cpufreq_register_driver(&centrino_driver);

}

static void __exit centrino_exit(void)

{

	cpufreq_unregister_driver(&centrino_driver);

}

MODULE_AUTHOR ("Jeremy Fitzhardinge <jeremy@goop.org>");

MODULE_DESCRIPTION ("Enhanced SpeedStep driver for Intel Pentium M processors.");

MODULE_LICENSE ("GPL");

late_initcall(centrino_init);

module_exit(centrino_exit);

----------

## rschwarze

i'm not sure. but is it possible, that you try to compile speedstep-centrino as a module?

that will _NOT_ work! you have to compile it into the kernel!

if this isn't the error, please let me know.

greets,

roman

----------

## Matt.Shure

Hi,

Sorry, but I'm a Linux nub, which line do I have to check with "y" for NOT compiling it as a module but directly into the kernel? There are several lines speaking of speedstep or centrino in the .config, but no one has the exact term "speedstep-centrino.c" in it. 

By the way, I copied the CPUFREQ part from the .config file you have posted here, and some parts of the speedstep-centrino.c from other posts in this topic.

----------

## rschwarze

okay. you dont have to edit the .confg file manually. you can use menuconfig for that. when you are at the directory with the kernel sourcecode, (the directory where you do "make && make modules install" to compile your kernel) just type "make menuconfig". then you get a menu where you can make your selektions.

In this menu you go to "power management options". then go to "cpu frequency scaling". at this place you want to select (and you should really select it, not just make it as a module): "<*>   Intel Enhanced SpeedStep". then there is an other option below that, which telly you: " [ ]     Use ACPI tables to decode valid frequency/voltage pairs" this one must be _not_ selected.

so, then go ahead, compile your kernel, change your bootmanager to the new kernel and all that stuff. if you have any questions, also about compiling the kernel and stuff, you can ask me. (but i'm not sure if i can help very much, because i'm relatively new to linux, too)

oh, and i think you should delete the entry for the 1.6 dothan, because the driver don't know which one to use.

----------

## Matt.Shure

Hello,

i recompiled the kernel using the hints you have given me, but it still doesn't work. 

In the menuconfig I can decide which governor to use as standard, performance or userspace, which one shuold I use? 

And which entry am I supposed to delete? There is only one entry for the 1600 dothan. 

Greetings,

Matthias

----------

## rschwarze

okay:

which governor you use is not important for this undervolting thing. i myself use the "<*>   'conservative' cpufreq governor".

if you want to have speedstepping, you should make "Default CPUFreq governor (userspace)  --->".

okay, you have the 1.6 sonoma, right? so in the speedstep-centrino.c file there is also a table of frequencies for the donoma 1.6. so you may want to delete this table.

when you read this whole thread, you ca see that there are several people who have problems with there sonoma. but in the end they all managed it. so, maybe have a look at their postings. 

for example, someone says that he needs to use 1599 as the frequency instead of 1600. maybe thats the problem. just look at your speedstep-centrino.c and try different versions.

then, if you don't got it, send me your speedstep-centrino.c and i will look at it.

----------

## Matt.Shure

Hello, 

I just recognized that the entry for the 730 processor was missing, so I copied BetterUnborn's into my speedstep-centrino.c, but now it doesn't compile any more. It just says: 

```

  CC      arch/i386/kernel/cpu/cpufreq/speedstep-centrino.o

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:346: error: `dothan_1599' unde

clared here (not in a function)

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:346: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:346: error: (near initializati

on for `models[13].op_points')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:346: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:346: error: (near initializati

on for `models[13]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:347: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:347: error: (near initializati

on for `models[14]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:348: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:348: error: (near initializati

on for `models[15]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:349: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:349: error: (near initializati

on for `models[16]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:350: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:350: error: (near initializati

on for `models[17]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:353: error: initializer elemen

t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:353: error: (near initializati                                                                                          on for `models[18]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:354: error: initializer elemen                                                                                          t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:354: error: (near initializati                                                                                          on for `models[19]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:355: error: initializer elemen                                                                                          t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:355: error: (near initializati                                                                                          on for `models[20]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:356: error: initializer elemen                                                                                          t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:356: error: (near initializati                                                                                          on for `models[21]')

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:358: error: initializer elemen                                                                                          t is not constant

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:358: error: (near initializati                                                                                          on for `models[22]')

make[3]: *** [arch/i386/kernel/cpu/cpufreq/speedstep-centrino.o] Fehler 1

make[2]: *** [arch/i386/kernel/cpu/cpufreq] Fehler 2

make[1]: *** [arch/i386/kernel/cpu] Fehler 2

```

My speedstep-centrino.c

```
#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/init.h>

#include <linux/cpufreq.h>

#include <linux/config.h>

#include <linux/delay.h>

#include <linux/compiler.h>

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

#include <linux/acpi.h>

#include <acpi/processor.h>

#endif

#include <asm/msr.h>

#include <asm/processor.h>

#include <asm/cpufeature.h>

#include "speedstep-est-common.h"

#define PFX      "speedstep-centrino: "

#define MAINTAINER   "Jeremy Fitzhardinge <jeremy@goop.org>"

#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)

struct cpu_id

{

   __u8   x86;            /* CPU family */

   __u8   x86_model;   /* model */

   __u8   x86_mask;   /* stepping */

};

enum {

   CPU_BANIAS,

   CPU_DOTHAN_A1,

   CPU_DOTHAN_A2,

   CPU_DOTHAN_B0,

   CPU_DOTHAN_C0,

};

static const struct cpu_id cpu_ids[] = {

   [CPU_BANIAS]   = { 6,  9, 5 },

   [CPU_DOTHAN_A1]   = { 6, 13, 1 },

   [CPU_DOTHAN_A2]   = { 6, 13, 2 },

   [CPU_DOTHAN_B0]   = { 6, 13, 6 },

   [CPU_DOTHAN_C0]   = { 6, 13, 8 },

};

#define N_IDS   (sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

   const struct cpu_id *cpu_id;

   const char   *model_name;

   unsigned   max_freq; /* max clock in kHz */

   struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)                     \

   {                        \

      .frequency = (mhz) * 1000,            \

      .index = (((mhz)/100) << 8) | ((mv - 700) / 16)      \

   }

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

   OP(600,  844),

   OP(800,  988),

   OP(900, 1004),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

   OP(600,   844),

   OP(800,   972),

   OP(900,   988),

   OP(1000, 1004),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

   OP( 600,  956),

   OP( 800, 1020),

   OP( 900, 1100),

   OP(1000, 1164),

   OP(1100, 1180),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

   OP( 600,  956),

   OP( 800, 1004),

   OP( 900, 1020),

   OP(1000, 1100),

   OP(1100, 1164),

   OP(1200, 1180),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

   OP( 600,  956),

   OP( 800, 1260),

   OP(1000, 1292),

   OP(1200, 1356),

   OP(1300, 1388),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

   OP( 600,  956),

   OP( 800, 1180),

   OP(1000, 1308),

   OP(1200, 1436),

   OP(1400, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

   OP( 600,  956),

   OP( 800, 1116),

   OP(1000, 1228),

   OP(1200, 1356),

   OP(1400, 1452),

   OP(1500, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1600[] =

{

   OP( 600,  956),

   OP( 800, 1036),

   OP(1000, 1164),

   OP(1200, 1276),

   OP(1400, 1420),

   OP(1600, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

   OP( 600,  956),

   OP( 800, 1004),

   OP(1000, 1116),

   OP(1200, 1228),

   OP(1400, 1308),

   OP(1700, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

#undef OP

/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each

   frequency (VID#A through VID#D) - this macro allows us to define all

   of these but we only use the VID#C voltages at compile time - this may

   need some work if we want to select the voltage profile at runtime. */

#define OP(mhz, mva, mvb, mvc, mvd)               \

   {                        \

      .frequency = (mhz) * 1000,            \

      .index = (((mhz)/100) << 8) | ((mvc - 700) / 16)          \

   }

 /* Intel Pentium M processor 733 / 1.10GHz (Dothan) */

 static struct cpufreq_frequency_table dothan_1100[] =

{

    OP( 500, 700, 700, 700, 700),

    OP( 600, 700, 700, 700, 700),

    OP( 800, 748, 748, 748, 748),

    OP( 900, 764, 764, 764, 764),

    OP(1000, 812, 812, 812, 812),

    OP(1100, 844, 844, 844, 844),

    { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

   OP( 400,  700,  700,  700,  700),

   OP( 600,  700,  700,  700,  700),

   OP( 800,  750,  750,  750,  750),

   OP(1000,  810,  810,  810,  810),

   OP(1200,  870,  870,  870,  870),

   OP(1400,  920,  920,  920,  920),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

   OP( 600,  988,  988,  988,  988),

   OP( 800, 1068, 1068, 1068, 1052),

   OP(1000,  700, 1148, 1132, 1116),

   OP(1200, 1228, 1212, 1212, 1180),

   OP(1500, 1340, 1324, 1308, 1276),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

   OP( 600,  800,  988,  988,  988),

   OP( 800,  800, 1068, 1052, 1052),

   OP(1000, 1132, 1132, 1116, 1116),

   OP(1200, 1212, 1196, 1180, 1164),

   OP(1400, 1276, 1260, 1244, 1228),

   OP(1600, 1340, 1324, 1308, 1276),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1700[] =

{

   OP( 600,  988,  988,  988,  988),

   OP( 800, 1052, 1052, 1052, 1052),

   OP(1000, 1116, 1116, 1116, 1100),

   OP(1200, 1180, 1180, 1164, 1148),

   OP(1400, 1244, 1244, 1228, 1212),

   OP(1700, 1340, 1324, 1308, 1276),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1800[] =

{

   OP( 600,  988,  988,  988,  988),

   OP( 800, 1052, 1052, 1052, 1036),

   OP(1000, 1116, 1100, 1100, 1084),

   OP(1200, 1164, 1164, 1148, 1132),

   OP(1400, 1228, 1212, 1212, 1180),

   OP(1600, 1292, 1276, 1260, 1228),

   OP(1800, 1340, 1324, 1308, 1276),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */

static struct cpufreq_frequency_table dothan_2000[] =

{

   OP( 600,  988,  988,  988,  988),

   OP( 800, 1052, 1036, 1036, 1036),

   OP(1000, 1100, 1084, 1084, 1084),

   OP(1200, 1148, 1132, 1132, 1116),

   OP(1400, 1196, 1180, 1180, 1164),

   OP(1600, 1244, 1228, 1228, 1196),

   OP(1800, 1292, 1276, 1276, 1244),

   OP(2000, 1340, 1324, 1308, 1276),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 730 / 1.599GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1599[] =

{

   OP( 600, 812, 812, 812, 812)

   OP( 800, 812, 812, 812, 812),

   OP(1067, 700, 700, 700, 700),

   OP(1333, 1004, 1004, 1004, 1004),

   OP(1600, 1100, 1100, 1100, 1100),

   { .frequency = CPUFREQ_TABLE_END }

}; 

/* Intel Pentium M processor 750 / 1.86GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1867[] =

{

   OP( 800,  880,  880,  880,  880),

   OP(1333, 1010, 1010, 1010, 1010),

   OP(1867, 1120, 1120, 1120, 1120),

   { .frequency = CPUFREQ_TABLE_END }

};

#undef OP

#define _BANIAS(cpuid, max, name)   \

{   .cpu_id      = cpuid,   \

   .model_name   = "Intel(R) Pentium(R) M processor " name "MHz", \

   .max_freq   = (max)*1000,   \

   .op_points   = banias_##max,   \

}

#define BANIAS(max)   _BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name)   \

{   .cpu_id      = cpuid,   \

   .model_name   = "Intel(R) Pentium(R) M processor " name "GHz", \

   .max_freq   = (max)*1000,   \

   .op_points   = dothan_##max,   \

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

   _BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

   BANIAS(1000),

   BANIAS(1100),

   BANIAS(1200),

   BANIAS(1300),

   BANIAS(1400),

   BANIAS(1500),

   BANIAS(1600),

   BANIAS(1700),

        DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1100, "1.10"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1400, "1.40"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1500, "1.50"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1600, "1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1599, "1.60"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1700, "1.70"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1800, "1.80"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 2000, "2.00"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1867, "1.86"),

   /* NULL model_name is a wildcard */

   { &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

   { NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN
```

----------

## knefas

try to remove 

```
DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1600, "1.60")
```

and change 

```
static struct cpufreq_frequency_table banias_1600[] = 
```

in

```
static struct cpufreq_frequency_table banias_1599[] = 
```

----------

## Matt.Shure

Hi, 

with the changes you've appointed and after I've fixed two other things, the kernel is compiling now, but says: 

```

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:181: warning: `banias_1599' defined but not used

arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c:253: warning: `dothan_1600' defined but not used

```

Let's see what a reboot will show, so long, thank you!

----------

## Matt.Shure

It still doesn't work   :Sad: 

I'm using cpufreq-info to check whether the kernel is using my new values or not, but it still says 800 - 1600Mhz. In the section for my processor I specified a 600Mhz line for testing purposes (I know that it won't be really used, but in that way, cpufreq-info will show me which definition it is using).

Any more hints?

----------

## rschwarze

why have you defined a banias 1599?

i think you should post your complete speedstep-centrino.c again.

isn't anyone here, who has a working speedstep-centrino for the sonoma 1.6?

here the link to my working file for the dothan 1.4 and the sonoma 1.87:

http://www.math.uni-bielefeld.de/~schwarze/speedstep-centrino.c

I think, the only changes you have to make are: uncomment the entries for the dothan 1.6 and change the entry for the 1.87 sonoma to your values and change the row for the sonoma in the "static struct cpu_model models" section.

i hope that will work.

edit: i looked another time at your posted file and i see that you have a wrong entry in the "static struct cpu_model models" section. because you have an sonoma with a 133 frontsidebus you have to use "C0" instead of "B0" (the same as in the line of the sonoma)

----------

## Matt.Shure

Changing B0 into C0 resulted in the new kernel crashing each time KDE is loaded (when the Suse Bootscreen reappears with the mouse cursor on it saying "Starting User Interface"). I'm using BetterUnborn's voltages, is it possible that the kernel is finally using them and crashes therefore? 

Where can I get the original values for my sonoma 730 cpu? I've browsed Intels datasheet but didn't find anything helfpful. 

Thanks,

Matthias

----------

## rschwarze

it sounds like that!

just try to add 0.1 to each of the voltages.

----------

## Matt.Shure

It works! 

Readjusting the voltages finally gave me a booting kernel that uses my custom voltages. Now I have to figure out the optimal values fpr my system, can anyone give me some hints to do so? 

How can I set the frequency to a certain value? Suse only supports 800Mhz and 1600Mhz. Which programm can I use to check if my system is stable? 

Thanks,

Matthias

----------

## rschwarze

thats great!

 think susu supports everything. (its nothing about the distri).  if you use cpufreq, with cpufreq-info ou got all the information about the frequencies which are possible and about the governer you can use.

with cpufreq-set -g conservative (if you have installed it) your pc uses every voltage an is very battery saving.

just try out cpufreq-set and he gives you all the informations you need.

----------

## Matt.Shure

ok, I managed to set the frequencies manually using cpufreq-set, but can you please tell me a programm that tests the cpu with full load? For WinXP, I use Prime95. 

My speedstep-cenntrino.c,not perfect and I'm sure all that copy & paste during the last days left some unneccessary entries, but working for the sonoma 1,60Ghz (730): 

/*

 * cpufreq driver for Enhanced SpeedStep, as found in Intel's Pentium

 * M (part of the Centrino chipset).

 *

 * Despite the "SpeedStep" in the name, this is almost entirely unlike

 * traditional SpeedStep.

 *

 * Modelled on speedstep.c

 *

 * Copyright (C) 2003 Jeremy Fitzhardinge <jeremy@goop.org>

 *

 * WARNING WARNING WARNING

 *

 * This driver manipulates the PERF_CTL MSR, which is only somewhat

 * documented.  While it seems to work on my laptop, it has not been

 * tested anywhere else, and it may not work for you, do strange

 * things or simply crash.

 */

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/init.h>

#include <linux/cpufreq.h>

#include <linux/config.h>

#include <linux/delay.h>

#include <linux/compiler.h>

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

#include <linux/acpi.h>

#include <acpi/processor.h>

#endif

#include <asm/msr.h>

#include <asm/processor.h>

#include <asm/cpufeature.h>

#include "speedstep-est-common.h"

#define PFX		"speedstep-centrino: "

#define MAINTAINER	"Jeremy Fitzhardinge <jeremy@goop.org>"

#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)

struct cpu_id

{

	__u8	x86;            /* CPU family */

	__u8	x86_model;	/* model */

	__u8	x86_mask;	/* stepping */

};

enum {

	CPU_BANIAS,

	CPU_DOTHAN_A1,

	CPU_DOTHAN_A2,

	CPU_DOTHAN_B0,

	CPU_DOTHAN_C0,

};

static const struct cpu_id cpu_ids[] = {

	[CPU_BANIAS]	= { 6,  9, 5 },

	[CPU_DOTHAN_A1]	= { 6, 13, 1 },

	[CPU_DOTHAN_A2]	= { 6, 13, 2 },

	[CPU_DOTHAN_B0]	= { 6, 13, 6 },

	[CPU_DOTHAN_C0]	= { 6, 13, 8 },

};

#define N_IDS	(sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

	const struct cpu_id *cpu_id;

	const char	*model_name;

	unsigned	max_freq; /* max clock in kHz */

	struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)							\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) <<  :Cool:  | ((mv - 700) / 16)		\

	}

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

	OP(600,  844),

	OP(800,  988),

	OP(900, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

	OP(600,   844),

	OP(800,   972),

	OP(900,   988),

	OP(1000, 1004),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

	OP( 600,  956),

	OP( 800, 1020),

	OP( 900, 1100),

	OP(1000, 1164),

	OP(1100, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP( 900, 1020),

	OP(1000, 1100),

	OP(1100, 1164),

	OP(1200, 1180),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

	OP( 600,  956),

	OP( 800, 1260),

	OP(1000, 1292),

	OP(1200, 1356),

	OP(1300, 1388),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

	OP( 600,  956),

	OP( 800, 1180),

	OP(1000, 1308),

	OP(1200, 1436),

	OP(1400, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

	OP( 600,  956),

	OP( 800, 1116),

	OP(1000, 1228),

	OP(1200, 1356),

	OP(1400, 1452),

	OP(1500, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1599[] =

{

	OP( 600,  956),

	OP( 800, 1036),

	OP(1000, 1164),

	OP(1200, 1276),

	OP(1400, 1420),

	OP(1600, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

	OP( 600,  956),

	OP( 800, 1004),

	OP(1000, 1116),

	OP(1200, 1228),

	OP(1400, 1308),

	OP(1700, 1484),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each

   frequency (VID#A through VID#D) - this macro allows us to define all

   of these but we only use the VID#C voltages at compile time - this may

   need some work if we want to select the voltage profile at runtime. */

#define OP(mhz, mva, mvb, mvc, mvd)					\

	{								\

		.frequency = (mhz) * 1000,				\

		.index = (((mhz)/100) <<  :Cool:  | ((mvc - 700) / 16)       	\

	}

 /* Intel Pentium M processor 733 / 1.10GHz (Dothan) */

 static struct cpufreq_frequency_table dothan_1100[] =

{

 	OP( 500, 700, 700, 700, 700),

 	OP( 600, 700, 700, 700, 700),

 	OP( 800, 748, 748, 748, 748),

 	OP( 900, 764, 764, 764, 764),

 	OP(1000, 812, 812, 812, 812),

 	OP(1100, 844, 844, 844, 844),

 	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

	OP( 400,  700,  700,  700,  700),

	OP( 600,  700,  700,  700,  700),

	OP( 800,  750,  750,  750,  750),

	OP(1000,  810,  810,  810,  810),

	OP(1200,  870,  870,  870,  870),

	OP(1400,  920,  920,  920,  920),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1068, 1068, 1068, 1052),

	OP(1000,  700, 1148, 1132, 1116),

	OP(1200, 1228, 1212, 1212, 1180),

	OP(1500, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 725 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1600[] =

{

	OP( 600,  800,  988,  988,  988),

	OP( 800,  800, 1068, 1052, 1052),

	OP(1000, 1132, 1132, 1116, 1116),

	OP(1200, 1212, 1196, 1180, 1164),

	OP(1400, 1276, 1260, 1244, 1228),

	OP(1600, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 735 / 1.70GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1700[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1052),

	OP(1000, 1116, 1116, 1116, 1100),

	OP(1200, 1180, 1180, 1164, 1148),

	OP(1400, 1244, 1244, 1228, 1212),

	OP(1700, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 745 / 1.80GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1800[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1052, 1052, 1036),

	OP(1000, 1116, 1100, 1100, 1084),

	OP(1200, 1164, 1164, 1148, 1132),

	OP(1400, 1228, 1212, 1212, 1180),

	OP(1600, 1292, 1276, 1260, 1228),

	OP(1800, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 755 / 2.00GHz (Dothan) */

static struct cpufreq_frequency_table dothan_2000[] =

{

	OP( 600,  988,  988,  988,  988),

	OP( 800, 1052, 1036, 1036, 1036),

	OP(1000, 1100, 1084, 1084, 1084),

	OP(1200, 1148, 1132, 1132, 1116),

	OP(1400, 1196, 1180, 1180, 1164),

	OP(1600, 1244, 1228, 1228, 1196),

	OP(1800, 1292, 1276, 1276, 1244),

	OP(2000, 1340, 1324, 1308, 1276),

	{ .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 730 / 1.599GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1599[] =

{

	OP( 800, 812, 912, 912, 912),

	OP(1067, 1104, 1104, 1104, 1104),

	OP(1333, 1104, 1104, 1104, 1104),

	OP(1600, 1200, 1200, 1200, 1200),

	{ .frequency = CPUFREQ_TABLE_END }

}; 

/* Intel Pentium M processor 750 / 1.86GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1867[] =

{

	OP( 800,  880,  880,  880,  880),

	OP(1333, 1010, 1010, 1010, 1010),

	OP(1867, 1120, 1120, 1120, 1120),

	{ .frequency = CPUFREQ_TABLE_END }

};

#undef OP

#define _BANIAS(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "MHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= banias_##max,	\

}

#define BANIAS(max)	_BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name)	\

{	.cpu_id		= cpuid,	\

	.model_name	= "Intel(R) Pentium(R) M processor " name "GHz", \

	.max_freq	= (max)*1000,	\

	.op_points	= dothan_##max,	\

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

	_BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

	BANIAS(1000),

	BANIAS(1100),

	BANIAS(1200),

	BANIAS(1300),

	BANIAS(1400),

	BANIAS(1500),

	BANIAS(1700),

        DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1100, "1.10"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1400, "1.40"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1500, "1.50"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1599, "1.60"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1700, "1.70"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 1800, "1.80"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_B0], 2000, "2.00"),

	DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 1867, "1.86"),

	/* NULL model_name is a wildcard */

	{ &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

	{ &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

	{ NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN

static int centrino_cpu_init_table(struct cpufreq_policy *policy)

{

	struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

	struct cpu_model *model;

	for(model = models; model->cpu_id != NULL; model++)

		if (centrino_verify_cpu_id(cpu, model->cpu_id) &&

		    (model->model_name == NULL ||

		     strcmp(cpu->x86_model_id, model->model_name) == 0))

			break;

	if (model->cpu_id == NULL) {

		/* No match at all */

		dprintk(KERN_INFO PFX "no support for CPU model \"%s\": "

		       "send /proc/cpuinfo to " MAINTAINER "\n",

		       cpu->x86_model_id);

		return -ENOENT;

	}

	if (model->op_points == NULL) {

		/* Matched a non-match */

		dprintk(KERN_INFO PFX "no table support for CPU model \"%s\": \n",

		       cpu->x86_model_id);

#ifndef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

		dprintk(KERN_INFO PFX "try compiling with CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled\n");

#endif

		return -ENOENT;

	}

	centrino_model[policy->cpu] = model;

	dprintk("found \"%s\": max frequency: %dkHz\n",

	       model->model_name, model->max_freq);

	return 0;

}

#else

static inline int centrino_cpu_init_table(struct cpufreq_policy *policy) { return -ENODEV; }

#endif /* CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE */

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x)

{

	if ((c->x86 == x->x86) &&

	    (c->x86_model == x->x86_model) &&

	    (c->x86_mask == x->x86_mask))

		return 1;

	return 0;

}

/* To be called only after centrino_model is initialized */

static unsigned extract_clock(unsigned msr, unsigned int cpu, int failsafe)

{

	int i;

	/*

	 * Extract clock in kHz from PERF_CTL value

	 * for centrino, as some DSDTs are buggy.

	 * Ideally, this can be done using the acpi_data structure.

	 */

	if ((centrino_cpu[cpu] == &cpu_ids[CPU_BANIAS]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_A1]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_B0]) ||

	    (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_C0])) {

		msr = (msr >>  :Cool:  & 0xff;

		return msr * 100000;

	}

	if ((!centrino_model[cpu]) || (!centrino_model[cpu]->op_points))

		return 0;

	msr &= 0xffff;

	for (i=0;centrino_model[cpu]->op_points[i].frequency != CPUFREQ_TABLE_END; i++) {

		if (msr == centrino_model[cpu]->op_points[i].index)

			return centrino_model[cpu]->op_points[i].frequency;

	}

	if (failsafe)

		return centrino_model[cpu]->op_points[i-1].frequency;

	else

		return 0;

}

/* Return the current CPU frequency in kHz */

static unsigned int get_cur_freq(unsigned int cpu)

{

	unsigned l, h;

	unsigned clock_freq;

	cpumask_t saved_mask;

	saved_mask = current->cpus_allowed;

	set_cpus_allowed(current, cpumask_of_cpu(cpu));

	if (smp_processor_id() != cpu)

		return 0;

	rdmsr(MSR_IA32_PERF_STATUS, l, h);

	clock_freq = extract_clock(l, cpu, 0);

	if (unlikely(clock_freq == 0)) {

		/*

		 * On some CPUs, we can see transient MSR values (which are

		 * not present in _PSS), while CPU is doing some automatic

		 * P-state transition (like TM2). Get the last freq set 

		 * in PERF_CTL.

		 */

		rdmsr(MSR_IA32_PERF_CTL, l, h);

		clock_freq = extract_clock(l, cpu, 1);

	}

	set_cpus_allowed(current, saved_mask);

	return clock_freq;

}

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

static struct acpi_processor_performance p;

/*

 * centrino_cpu_init_acpi - register with ACPI P-States library

 *

 * Register with the ACPI P-States library (part of drivers/acpi/processor.c)

 * in order to determine correct frequency and voltage pairings by reading

 * the _PSS of the ACPI DSDT or SSDT tables.

 */

static int centrino_cpu_init_acpi(struct cpufreq_policy *policy)

{

	union acpi_object		arg0 = {ACPI_TYPE_BUFFER};

	u32				arg0_buf[3];

	struct acpi_object_list		arg_list = {1, &arg0};

	unsigned long			cur_freq;

	int				result = 0, i;

	unsigned int			cpu = policy->cpu;

	/* _PDC settings */

	arg0.buffer.length = 12;

	arg0.buffer.pointer = (u8 *) arg0_buf;

	arg0_buf[0] = ACPI_PDC_REVISION_ID;

	arg0_buf[1] = 1;

	arg0_buf[2] = ACPI_PDC_EST_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_MSR;

	p.pdc = &arg_list;

	/* register with ACPI core */

	if (acpi_processor_register_performance(&p, cpu)) {

		dprintk(KERN_INFO PFX "obtaining ACPI data failed\n");

		return -EIO;

	}

	/* verify the acpi_data */

	if (p.state_count <= 1) {

		dprintk("No P-States\n");

		result = -ENODEV;

		goto err_unreg;

	}

	if ((p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) ||

	    (p.status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)) {

		dprintk("Invalid control/status registers (%x - %x)\n",

			p.control_register.space_id, p.status_register.space_id);

		result = -EIO;

		goto err_unreg;

	}

	for (i=0; i<p.state_count; i++) {

		if (p.states[i].control != p.states[i].status) {

			dprintk("Different control (%x) and status values (%x)\n",

				p.states[i].control, p.states[i].status);

			result = -EINVAL;

			goto err_unreg;

		}

		if (!p.states[i].core_frequency) {

			dprintk("Zero core frequency for state %u\n", i);

			result = -EINVAL;

			goto err_unreg;

		}

		if (p.states[i].core_frequency > p.states[0].core_frequency) {

			dprintk("P%u has larger frequency (%u) than P0 (%u), skipping\n", i,

				p.states[i].core_frequency, p.states[0].core_frequency);

			p.states[i].core_frequency = 0;

			continue;

		}

	}

	centrino_model[cpu] = kmalloc(sizeof(struct cpu_model), GFP_KERNEL);

	if (!centrino_model[cpu]) {

		result = -ENOMEM;

		goto err_unreg;

	}

	memset(centrino_model[cpu], 0, sizeof(struct cpu_model));

	centrino_model[cpu]->model_name=NULL;

	centrino_model[cpu]->max_freq = p.states[0].core_frequency * 1000;

	centrino_model[cpu]->op_points =  kmalloc(sizeof(struct cpufreq_frequency_table) *

					     (p.state_count + 1), GFP_KERNEL);

        if (!centrino_model[cpu]->op_points) {

                result = -ENOMEM;

                goto err_kfree;

        }

        for (i=0; i<p.state_count; i++) {

		centrino_model[cpu]->op_points[i].index = p.states[i].control;

		centrino_model[cpu]->op_points[i].frequency = p.states[i].core_frequency * 1000;

		dprintk("adding state %i with frequency %u and control value %04x\n", 

			i, centrino_model[cpu]->op_points[i].frequency, centrino_model[cpu]->op_points[i].index);

	}

	centrino_model[cpu]->op_points[p.state_count].frequency = CPUFREQ_TABLE_END;

	cur_freq = get_cur_freq(cpu);

	for (i=0; i<p.state_count; i++) {

		if (!p.states[i].core_frequency) {

			dprintk("skipping state %u\n", i);

			centrino_model[cpu]->op_points[i].frequency = CPUFREQ_ENTRY_INVALID;

			continue;

		}

		if (extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0) !=

		    (centrino_model[cpu]->op_points[i].frequency)) {

			dprintk("Invalid encoded frequency (%u vs. %u)\n",

				extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0),

				centrino_model[cpu]->op_points[i].frequency);

			result = -EINVAL;

			goto err_kfree_all;

		}

		if (cur_freq == centrino_model[cpu]->op_points[i].frequency)

			p.state = i;

	}

	/* notify BIOS that we exist */

	acpi_processor_notify_smm(THIS_MODULE);

	return 0;

 err_kfree_all:

	kfree(centrino_model[cpu]->op_points);

 err_kfree:

	kfree(centrino_model[cpu]);

 err_unreg:

	acpi_processor_unregister_performance(&p, cpu);

	dprintk(KERN_INFO PFX "invalid ACPI data\n");

	return (result);

}

#else

static inline int centrino_cpu_init_acpi(struct cpufreq_policy *policy) { return -ENODEV; }

#endif

static int centrino_cpu_init(struct cpufreq_policy *policy)

{

	struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

	unsigned freq;

	unsigned l, h;

	int ret;

	int i;

	/* Only Intel makes Enhanced Speedstep-capable CPUs */

	if (cpu->x86_vendor != X86_VENDOR_INTEL || !cpu_has(cpu, X86_FEATURE_EST))

		return -ENODEV;

	for (i = 0; i < N_IDS; i++)

		if (centrino_verify_cpu_id(cpu, &cpu_ids[i]))

			break;

	if (i != N_IDS)

		centrino_cpu[policy->cpu] = &cpu_ids[i];

	if (is_const_loops_cpu(policy->cpu)) {

		centrino_driver.flags |= CPUFREQ_CONST_LOOPS;

	}

	if (centrino_cpu_init_acpi(policy)) {

		if (policy->cpu != 0)

			return -ENODEV;

		if (!centrino_cpu[policy->cpu]) {

			dprintk(KERN_INFO PFX "found unsupported CPU with "

			"Enhanced SpeedStep: send /proc/cpuinfo to "

			MAINTAINER "\n");

			return -ENODEV;

		}

		if (centrino_cpu_init_table(policy)) {

			return -ENODEV;

		}

	}

	/* Check to see if Enhanced SpeedStep is enabled, and try to

	   enable it if not. */

	rdmsr(MSR_IA32_MISC_ENABLE, l, h);

	if (!(l & (1<<16))) {

		l |= (1<<16);

		dprintk("trying to enable Enhanced SpeedStep (%x)\n", l);

		wrmsr(MSR_IA32_MISC_ENABLE, l, h);

		/* check to see if it stuck */

		rdmsr(MSR_IA32_MISC_ENABLE, l, h);

		if (!(l & (1<<16))) {

			printk(KERN_INFO PFX "couldn't enable Enhanced SpeedStep\n");

			return -ENODEV;

		}

	}

	freq = get_cur_freq(policy->cpu);

	policy->governor = CPUFREQ_DEFAULT_GOVERNOR;

	policy->cpuinfo.transition_latency = 10000; /* 10uS transition latency */

	policy->cur = freq;

	dprintk("centrino_cpu_init: cur=%dkHz\n", policy->cur);

	ret = cpufreq_frequency_table_cpuinfo(policy, centrino_model[policy->cpu]->op_points);

	if (ret)

		return (ret);

	cpufreq_frequency_table_get_attr(centrino_model[policy->cpu]->op_points, policy->cpu);

	return 0;

}

static int centrino_cpu_exit(struct cpufreq_policy *policy)

{

	unsigned int cpu = policy->cpu;

	if (!centrino_model[cpu])

		return -ENODEV;

	cpufreq_frequency_table_put_attr(cpu);

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

	if (!centrino_model[cpu]->model_name) {

		dprintk("unregistering and freeing ACPI data\n");

		acpi_processor_unregister_performance(&p, cpu);

		kfree(centrino_model[cpu]->op_points);

		kfree(centrino_model[cpu]);

	}

#endif

	centrino_model[cpu] = NULL;

	return 0;

}

/**

 * centrino_verify - verifies a new CPUFreq policy

 * @policy: new policy

 *

 * Limit must be within this model's frequency range at least one

 * border included.

 */

static int centrino_verify (struct cpufreq_policy *policy)

{

	return cpufreq_frequency_table_verify(policy, centrino_model[policy->cpu]->op_points);

}

/**

 * centrino_setpolicy - set a new CPUFreq policy

 * @policy: new policy

 * @target_freq: the target frequency

 * @relation: how that frequency relates to achieved frequency (CPUFREQ_RELATION_L or CPUFREQ_RELATION_H)

 *

 * Sets a new CPUFreq policy.

 */

static int centrino_target (struct cpufreq_policy *policy,

			    unsigned int target_freq,

			    unsigned int relation)

{

	unsigned int    newstate = 0;

	unsigned int	msr, oldmsr, h, cpu = policy->cpu;

	struct cpufreq_freqs	freqs;

	cpumask_t		saved_mask;

	int			retval;

	if (centrino_model[cpu] == NULL)

		return -ENODEV;

	/*

	 * Support for SMP systems.

	 * Make sure we are running on the CPU that wants to change frequency

	 */

	saved_mask = current->cpus_allowed;

	set_cpus_allowed(current, policy->cpus);

	if (!cpu_isset(smp_processor_id(), policy->cpus)) {

		dprintk("couldn't limit to CPUs in this domain\n");

		return(-EAGAIN);

	}

	if (cpufreq_frequency_table_target(policy, centrino_model[cpu]->op_points, target_freq,

					   relation, &newstate)) {

		retval = -EINVAL;

		goto migrate_end;

	}

	msr = centrino_model[cpu]->op_points[newstate].index;

	rdmsr(MSR_IA32_PERF_CTL, oldmsr, h);

	if (msr == (oldmsr & 0xffff)) {

		retval = 0;

		dprintk("no change needed - msr was and needs to be %x\n", oldmsr);

		goto migrate_end;

	}

	freqs.cpu = cpu;

	freqs.old = extract_clock(oldmsr, cpu, 0);

	freqs.new = extract_clock(msr, cpu, 0);

	dprintk("target=%dkHz old=%d new=%d msr=%04x\n",

		target_freq, freqs.old, freqs.new, msr);

	cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);

	/* all but 16 LSB are "reserved", so treat them with

	   care */

	oldmsr &= ~0xffff;

	msr &= 0xffff;

	oldmsr |= msr;

	wrmsr(MSR_IA32_PERF_CTL, oldmsr, h);

	cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);

	retval = 0;

migrate_end:

	set_cpus_allowed(current, saved_mask);

	return (retval);

}

static struct freq_attr* centrino_attr[] = {

	&cpufreq_freq_attr_scaling_available_freqs,

	NULL,

};

static struct cpufreq_driver centrino_driver = {

	.name		= "centrino", /* should be speedstep-centrino,

					 but there's a 16 char limit */

	.init		= centrino_cpu_init,

	.exit		= centrino_cpu_exit,

	.verify		= centrino_verify,

	.target		= centrino_target,

	.get		= get_cur_freq,

	.attr           = centrino_attr,

	.owner		= THIS_MODULE,

};

/**

 * centrino_init - initializes the Enhanced SpeedStep CPUFreq driver

 *

 * Initializes the Enhanced SpeedStep support. Returns -ENODEV on

 * unsupported devices, -ENOENT if there's no voltage table for this

 * particular CPU model, -EINVAL on problems during initiatization,

 * and zero on success.

 *

 * This is quite picky.  Not only does the CPU have to advertise the

 * "est" flag in the cpuid capability flags, we look for a specific

 * CPU model and stepping, and we need to have the exact model name in

 * our voltage tables.  That is, be paranoid about not releasing

 * someone's valuable magic smoke.

 */

static int __init centrino_init(void)

{

	struct cpuinfo_x86 *cpu = cpu_data;

	if (!cpu_has(cpu, X86_FEATURE_EST))

		return -ENODEV;

	return cpufreq_register_driver(&centrino_driver);

}

static void __exit centrino_exit(void)

{

	cpufreq_unregister_driver(&centrino_driver);

}

MODULE_AUTHOR ("Jeremy Fitzhardinge <jeremy@goop.org>");

MODULE_DESCRIPTION ("Enhanced SpeedStep driver for Intel Pentium M processors.");

MODULE_LICENSE ("GPL");

late_initcall(centrino_init);

module_exit(centrino_exit);

----------

## rschwarze

prime 95 is also available for linux.

with gentoo just type "emerge gimps"

then start it with "prime"

the rest is as easy as in windows (but its textmode only).

with any other distri, just search for gimps or prime95 in the package manager.

thanks for your speedstep-centrino.c

i think because you don't delete the other entries your file should work for all dothan and for the 1.6 and 1.87 sonoma. so, i hope it will be helpful for lots of other persons.

----------

## Matt.Shure

Are there any other programs out there? I didn't manage to get Prime95 to work, it says 

```
./mprime: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
```

despite the fact that libstdc is installed! (mprime in home directory, I didn't find any installation instructions)

----------

## rschwarze

sorry, i don't know how to install it, because with gentoo everything is so easy.

i don't think there are very much programs for this testings for linux, because normally only overclocker need them and oveclocker usually use windows.

can't you install it via the suse packetmanager?

----------

## Matt.Shure

No, the Suse packet manager finds nothing for "gimps" or "prime"  :Sad: 

----------

## schorsche

rschwarze, 

Do I just need to copy your speedstep-centrino.c - file with all the entries for different CPU's or

do I have to cancel all the other for different cpu's out?

I'm using a Dothan 1500 CPU, recompiled the kernel as you sain (disabling the ACPI-Option) 

but it's not working. 

```

/* Intel Pentium M processor 710 / 1.40GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1400[] =

{

        OP( 600, 700, 700, 700, 700),

        OP( 800, 770, 770, 770, 769),

        OP(1000, 840, 840, 840, 840),

        OP(1200, 910, 910, 910, 910),

        OP(1400, 980, 980, 980, 980),

        { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 715 / 1.50GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

        OP( 600, 700, 700, 700, 700),

        OP( 800, 1068, 1068, 1068, 1052),

        OP(1000, 1148, 1148, 1132, 1116),

        OP(1200, 1228, 1212, 1212, 1180),

        OP(1500, 1340, 1324, 1308, 1276),

        { .frequency = CPUFREQ_TABLE_END }

};

```

cpuinfo shows

```

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.50GHz

stepping        : 8

cpu MHz         : 599.642

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov                                                                  pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2

bogomips        : 1189.47

```

Thanks very much

----------

## rschwarze

Yes, you can use my speedstep-centrino.c file. you don't have to change anything than your voltages.

why do you know it is not working?

what is the output of cpufreq-info?

and while compiling the new kernel, do you see the line where he compiles the speedstep-centrino.c?

have you read this whole thread? there might me many useful hints  :Wink: 

----------

## dkulp

If you have one of the newer Dothans that run at 133Mhz front side bus instead of 100Mhz, more work needs to be done.   A coupld of the calculations in the speedstep-centrino file asume it's a 100Mhz bus and thus various tools will show a wrong frequency or frequencies would be set wrong, etc...

For my 2.13Ghz Dothan, I've done:

```

/* Define a new OP that figures out the appropriate multiplier for a 133Mhz bus */

#define OP133(mhz, mva, mvb, mvc, mvd)               \

   {                        \

      .frequency = (mhz) * 1000,            \

      .index = (((mhz)/133) << 8) | ((mvc - 700) / 16)          \

   }

static struct cpufreq_frequency_table dothan_2128[] =

{

    OP133(2128, 1132, 1132, 1132, 1132),

    OP133(1867, 1132, 1132, 1132, 1132),

    OP133(1600, 1116, 1116, 1116, 1116),

    OP133(1333, 1116, 1116, 1116, 1116),

    OP133(1067, 1084, 1084, 1084, 1084),

    OP133( 800, 750, 750, 750, 750),

    { .frequency = CPUFREQ_TABLE_END }

};

......

    DOTHAN(&cpu_ids[CPU_DOTHAN_C0], 2128, "2.13"),

......

```

Then in extract_clock, you need to do:

```

    if ((centrino_cpu[cpu] == &cpu_ids[CPU_BANIAS]) ||

       (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_A1]) ||

       (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_B0])) {

        msr = (msr >> 8) & 0xff;

        return msr * 100000;

    } else if (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_C0]) {

        /* this is wrong.  CPU_DOTHAN_C0 can be on a 100Mhz bus or a 133Mhz bus.

            Is there a way to find out what the bus speed is?   If so, use it.  For me,

            I know my computer is 133, so hardcode it for now */

        msr = (msr >> 8) & 0xff;

        return msr * 133000;

    }

```

If you don't do that, then the frequencies get all messed up in the cpuinfo stuff.  

Note: the above voltages are undervolted.   The defaults from the ACPI table for the 2.13 Dothan are:

```

static struct cpufreq_frequency_table dothan_2128[] =

{

   OP(2128, 1356, 1356, 1356, 1356),

   OP(1867, 1292, 1292, 1292, 1292),

   OP(1600, 1212, 1212, 1212, 1212),

   OP(1333, 1148, 1148, 1148, 1148),

   OP(1067, 1068, 1068, 1068, 1068),

   OP( 800, 988, 988, 988, 988),

   { .frequency = CPUFREQ_TABLE_END }

};

```

Enjoy!

Dan

----------

## schorsche

I recompiled using your .c - file with the adapted (i.e. set to 700 mV) - values for my Dothan 1500 MHz CPU. The recompiling process shows that the .c - file is being compiled. 

Nothing changes though since the cpu-fan switches itself on after I reboot into the new kernel, although I applyl a "powersave" to the scaling governor.

I know from Windows- Centrino Hardware Control that 700mV@600MHz don't get the fan to start, not even under

full load! In Linux it starts turning though, that's why I reckon it's not working. 

BDW, cpufreq is an unknown command on my system, whith tools do I need to emerge?

Thanks

----------

## knefas

 *schorsche wrote:*   

> BDW, cpufreq is an unknown command on my system, whith tools do I need to emerge?

 

sys-power/cpufrequtils   :Smile: 

----------

## schorsche

Ah I see what's the matter. "Powersave" steps it down to 8 but the multiplier should be 6. 

How can I achive this?

Could this be a potential problem:

```

#

# shared options

#

# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set

# CONFIG_X86_SPEEDSTEP_LIB is not set

```

Thanks

----------

## schorsche

rschwarze, 

cpufreq-info shows: 

```

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: acpi-cpufreq

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 600 MHz - 1.50 GHz

  available frequency steps: 1.50 GHz, 600 MHz

  available cpufreq governors: conservative, powersave, userspace, performance

  current policy: frequency should be within 600 MHz and 1.50 GHz.

                  The governor "powersave" may decide which speed to use

                  within this range.

  current CPU frequency is 600 MHz.

```

It seems that I can only change between 600Hz and 1.5 GHZ. 

Furthermore, cat /proc/cpuinfo shows my a stepping 8, does that correspond to a Sonoma CPU? On my Notebook there's a sticker which says Pentium M 715 processor,1.5 GHZ,  400MHz FSB - that's a Dothan isn't it?

----------

## rschwarze

yes, i think that's a dothan.

but the problem is:

your cpufreq-info shows that he is using "driver: acpi-cpufreq". that is wrong. it must be "driver: centrino".

so, i don't know what you are doing wrong, but the kernel uses acpi instead of the speedstep-centrino.c to get your frequency/voltage pairs.

do you config yout kernel with "make menuconfig"? do you follow the directions i had given before?

btw: which kernel are u using?

----------

## schorsche

Well that's weird. I'm using Kernel 2.6-12r4, so the latest ones. 

Yes, I'm configuring my kernel manually, I copy System.map and bzImage to

/boot and start into the new kernel. 

Why does cpu-info only show 2 possible steppings, that is 600 and 1500 MHz

but nothing in between?

That's my kernel-config:

```

# APM (Advanced Power Management) BIOS Support

#

CONFIG_APM=y

# CONFIG_APM_IGNORE_USER_SUSPEND is not set

CONFIG_APM_DO_ENABLE=y

CONFIG_APM_CPU_IDLE=y

CONFIG_APM_DISPLAY_BLANK=y

CONFIG_APM_RTC_IS_GMT=y

# CONFIG_APM_ALLOW_INTS is not set

# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#

# CPU Frequency scaling

#

CONFIG_CPU_FREQ=y

CONFIG_CPU_FREQ_TABLE=y

# CONFIG_CPU_FREQ_DEBUG is not set

CONFIG_CPU_FREQ_STAT=y

# CONFIG_CPU_FREQ_STAT_DETAILS is not set

# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set

CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y

CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=y

CONFIG_CPU_FREQ_GOV_USERSPACE=y

# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set

CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=y

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=y

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

# CONFIG_X86_SPEEDSTEP_ICH is not set

# CONFIG_X86_SPEEDSTEP_SMI is not set

# CONFIG_X86_P4_CLOCKMOD is not set

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

#
```

Hang on, I just realised the "CONFIG_X86_ACPI_CPUFREQ=y" option is set. That might be wrong. You mentioned all I have to unset is the "# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set "  option. 

I'll just recompile my kernel with ACPI_CPUFREQ unset

----------

## rschwarze

sorry, but i think its correct. here's mine. at the moment i'm using the "linux-2.6.12-suspend2-r6" kernel but it also works with "linux-2.6.12-gentoo-r10".

are you sure you have the speedstep-centrino at the right place in the kernel-source?

```

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=y

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=y

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

# CONFIG_X86_SPEEDSTEP_ICH is not set

# CONFIG_X86_SPEEDSTEP_SMI is not set

# CONFIG_X86_P4_CLOCKMOD is not set

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

#

# shared options

#

CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y

# CONFIG_X86_SPEEDSTEP_LIB is not set

```

----------

## schorsche

Hmmm, 

I recompiled the kernel with this opion unset:  

# CONFIG_X86_ACPI_CPUFREQ is not set

Upon compilation, the msgs I get now don't mention speedstep-centrino.c now, 

so I'll go with the old options. 

One possible thing could be that I don't copy the image sources into the right place, 

or they somehow don't get recognised by grub. 

I try to explain what I did: 

- swap the old c. - file with yours

- change the processor's voltage  (M 715) to 700 mV (only the 600 MHz- values). 

Recompile- kernel takes the speedstep - file into account!

Copy bzImage and System.map to boot - Sector

Restart the new kernel (well hopefully, I'm gonna check right now). 

Any ideas? 

BDW, in Windos (Centrino Hardware Control) I set the Multiplier to 6 and the Voltage to 700 mV @ 600 Mhz. the fan never turns on. In Linux it does, so apparently something dodgy here. So can it be anything with wrong setting in the c- File, e.g. wrong FSB- speed etc?

thanks

----------

## rschwarze

yeah, if cpufreq-info doesn't show te right steps and so on, the kernel is not using the speedstep-centrino file at all. i don't know why. maybe you really boot with the wrong kernel?

----------

## beatryder

I have been playing with some of this stuff,

And getting well, very strange results...

I can get my speeds down to 533Mhz, thats a 1x multiplier, but for some strange reason the fastest the performace governor will choose is 1.2Ghz

I have the 1.6Ghz Sonoma(Dothan I guess) cpu, 133Mhz FSB

----------

## rschwarze

if you have a sonoma cpu, you don't have a dothan cpu  :Wink: 

i think you should lookat the posting above which tells how to change the frontsidebus.

----------

## beatryder

Hmm, well, you are 1/2 right

Sonoma is the codename for the new PCI Express chipset, which I have, which runs the dothan CPU's.

Correct me if I am wrong?

----------

## rschwarze

ok, maybe.

but with a 133 frontsidebus you habe a sonoma or a sonoma-dothan or whatever  :Wink: 

but you have to make the frontsidebuschange in the speedstep centrino.

i thnk it would be nice, if someone can change the speedstep-centrino in that way that it works with every sonoma and dothan processor.

than you can post a link to it here. that would help several people i think.

----------

## beatryder

that is precisely what I am hoping for

----------

## schorsche

EUREKA!

Got it as well, no more annoying fan-noise!

BetterUnborn sent me his file and I adapted the values to my CPU. 

Have a nice one!

----------

## beatryder

could you post your working .c file?

----------

## schorsche

Here we go: 

```

/*

 * cpufreq driver for Enhanced SpeedStep, as found in Intel's Pentium

 * M (part of the Centrino chipset).

 *

 * Despite the "SpeedStep" in the name, this is almost entirely unlike

 * traditional SpeedStep.

 *

 * Modelled on speedstep.c

 *

 * Copyright (C) 2003 Jeremy Fitzhardinge <jeremy@goop.org>

 *

 * WARNING WARNING WARNING

 *

 * This driver manipulates the PERF_CTL MSR, which is only somewhat

 * documented.  While it seems to work on my laptop, it has not been

 * tested anywhere else, and it may not work for you, do strange

 * things or simply crash.

 */

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/init.h>

#include <linux/cpufreq.h>

#include <linux/config.h>

#include <linux/delay.h>

#include <linux/compiler.h>

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

#include <linux/acpi.h>

#include <acpi/processor.h>

#endif

#include <asm/msr.h>

#include <asm/processor.h>

#include <asm/cpufeature.h>

#include "speedstep-est-common.h"

#define PFX      "speedstep-centrino: "

#define MAINTAINER   "Jeremy Fitzhardinge <jeremy@goop.org>"

#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "speedstep-centrino", msg)

struct cpu_id

{

   __u8   x86;            /* CPU family */

   __u8   x86_model;   /* model */

   __u8   x86_mask;   /* stepping */

};

enum {

   CPU_BANIAS,

   CPU_DOTHAN_A1,

   CPU_DOTHAN_A2,

   CPU_DOTHAN_B0,

   CPU_DOTHAN_C0,

   CPU_MP4HT_D0,

};

static const struct cpu_id cpu_ids[] = {

   [CPU_BANIAS]   = { 6,  9, 5 },

   [CPU_DOTHAN_A1]   = { 6, 13, 1 },

   [CPU_DOTHAN_A2]   = { 6, 13, 2 },

   [CPU_DOTHAN_B0]   = { 6, 13, 6 },

   [CPU_DOTHAN_C0] = { 6, 13, 8 },

   [CPU_MP4HT_D0]   = {15,  3, 4 },

};

#define N_IDS   (sizeof(cpu_ids)/sizeof(cpu_ids[0]))

struct cpu_model

{

   const struct cpu_id *cpu_id;

   const char   *model_name;

   unsigned   max_freq; /* max clock in kHz */

   struct cpufreq_frequency_table *op_points; /* clock/voltage pairs */

};

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x);

/* Operating points for current CPU */

static struct cpu_model *centrino_model[NR_CPUS];

static const struct cpu_id *centrino_cpu[NR_CPUS];

static struct cpufreq_driver centrino_driver;

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE

/* Computes the correct form for IA32_PERF_CTL MSR for a particular

   frequency/voltage operating point; frequency in MHz, volts in mV.

   This is stored as "index" in the structure. */

#define OP(mhz, mv)                     \

   {                        \

      .frequency = (mhz) * 1000,            \

      .index = (((mhz)/100) << 8) | ((mv - 700) / 16)      \

   }

/*

 * These voltage tables were derived from the Intel Pentium M

 * datasheet, document 25261202.pdf, Table 5.  I have verified they

 * are consistent with my IBM ThinkPad X31, which has a 1.3GHz Pentium

 * M.

 */

/* Ultra Low Voltage Intel Pentium M processor 900MHz (Banias) */

static struct cpufreq_frequency_table banias_900[] =

{

   OP(600,  844),

   OP(800,  988),

   OP(900, 1004),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Ultra Low Voltage Intel Pentium M processor 1000MHz (Banias) */

static struct cpufreq_frequency_table banias_1000[] =

{

   OP(600,   844),

   OP(800,   972),

   OP(900,   988),

   OP(1000, 1004),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.10GHz (Banias) */

static struct cpufreq_frequency_table banias_1100[] =

{

   OP( 600,  956),

   OP( 800, 1020),

   OP( 900, 1100),

   OP(1000, 1164),

   OP(1100, 1180),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Low Voltage Intel Pentium M processor 1.20GHz (Banias) */

static struct cpufreq_frequency_table banias_1200[] =

{

   OP( 600,  956),

   OP( 800, 1004),

   OP( 900, 1020),

   OP(1000, 1100),

   OP(1100, 1164),

   OP(1200, 1180),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.30GHz (Banias) */

static struct cpufreq_frequency_table banias_1300[] =

{

   OP( 600,  956),

   OP( 800, 1260),

   OP(1000, 1292),

   OP(1200, 1356),

   OP(1300, 1388),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.40GHz (Banias) */

static struct cpufreq_frequency_table banias_1400[] =

{

   OP( 600,  956),

   OP( 800, 1180),

   OP(1000, 1308),

   OP(1200, 1436),

   OP(1400, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.50GHz (Banias) */

static struct cpufreq_frequency_table banias_1500[] =

{

   OP( 600,  956),

   OP( 800, 1116),

   OP(1000, 1228),

   OP(1200, 1356),

   OP(1400, 1452),

   OP(1500, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.60GHz (Banias) */

static struct cpufreq_frequency_table banias_1600[] =

{

   OP( 600,  956),

   OP( 800, 1036),

   OP(1000, 1164),

   OP(1200, 1276),

   OP(1400, 1420),

   OP(1600, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

/* Intel Pentium M processor 1.70GHz (Banias) */

static struct cpufreq_frequency_table banias_1700[] =

{

   OP( 600,  956),

   OP( 800, 1004),

   OP(1000, 1116),

   OP(1200, 1228),

   OP(1400, 1308),

   OP(1700, 1484),

   { .frequency = CPUFREQ_TABLE_END }

};

#undef OP

/* Dothan processor datasheet 30218903.pdf defines 4 voltages for each

frequency (VID#A through VID#D) - this macro allows us to define all

of these but we only use the VID#C voltages at compile time - this may

need some work if we want to select the voltage profile at runtime. */

#define OP(mhz, mva, mvb, mvc, mvd) \

{ \

.frequency = (mhz) * 1000, \

.index = (((mhz)/100) << 8) | ((mvc - 700) / 16) \

}

/* Intel Pentium M processor 730 / 1.60GHz (Dothan) */

static struct cpufreq_frequency_table dothan_1500[] =

{

 OP( 600,  700,  700,  700,  700), 

 OP( 800, 1068, 1068, 1068, 1052),

 OP(1000, 1148, 1148, 1132, 1116),

 OP(1200, 1228, 1212, 1212, 1180),

 OP(1500, 1340, 1324, 1308, 1276),

 { .frequency = CPUFREQ_TABLE_END } 

};

#undef OP

#define _BANIAS(cpuid, max, name)   \

{   .cpu_id      = cpuid,   \

   .model_name   = "Intel(R) Pentium(R) M processor " name "MHz", \

   .max_freq   = (max)*1000,   \

   .op_points   = banias_##max,   \

}

#define BANIAS(max)   _BANIAS(&cpu_ids[CPU_BANIAS], max, #max)

#define DOTHAN(cpuid, max, name) \

{ .cpu_id = cpuid, \

.model_name = "Intel(R) Pentium(R) M processor " name "GHz", \

.max_freq = (max)*1000, \

.op_points = dothan_1500, \

}

/* CPU models, their operating frequency range, and freq/voltage

   operating points */

static struct cpu_model models[] =

{

   _BANIAS(&cpu_ids[CPU_BANIAS], 900, " 900"),

   BANIAS(1000),

   BANIAS(1100),

   BANIAS(1200),

   BANIAS(1300),

   BANIAS(1400),

   BANIAS(1500),

   BANIAS(1600),

   BANIAS(1700),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1500,"1.50"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1499,"1.50"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1498,"1.50"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1497,"1.50"),

   DOTHAN(&cpu_ids[CPU_DOTHAN_C0],1496,"1.50"),

   /* NULL model_name is a wildcard */

   { &cpu_ids[CPU_DOTHAN_A1], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_A2], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_B0], NULL, 0, NULL },

   { &cpu_ids[CPU_DOTHAN_C0], NULL, 0, NULL },

   { &cpu_ids[CPU_MP4HT_D0], NULL, 0, NULL },

   { NULL, }

};

#undef _BANIAS

#undef BANIAS

#undef DOTHAN

static int centrino_cpu_init_table(struct cpufreq_policy *policy)

{

   struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

   struct cpu_model *model;

   for(model = models; model->cpu_id != NULL; model++)

      if (centrino_verify_cpu_id(cpu, model->cpu_id) &&

          (model->model_name == NULL ||

           strcmp(cpu->x86_model_id, model->model_name) == 0))

         break;

   if (model->cpu_id == NULL) {

      /* No match at all */

      dprintk(KERN_INFO PFX "no support for CPU model \"%s\": "

             "send /proc/cpuinfo to " MAINTAINER "\n",

             cpu->x86_model_id);

      return -ENOENT;

   }

   if (model->op_points == NULL) {

      /* Matched a non-match */

      dprintk(KERN_INFO PFX "no table support for CPU model \"%s\": \n",

             cpu->x86_model_id);

#ifndef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

      dprintk(KERN_INFO PFX "try compiling with CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI enabled\n");

#endif

      return -ENOENT;

   }

   centrino_model[policy->cpu] = model;

   dprintk("found \"%s\": max frequency: %dkHz\n",

          model->model_name, model->max_freq);

   return 0;

}

#else

static inline int centrino_cpu_init_table(struct cpufreq_policy *policy) { return -ENODEV; }

#endif /* CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE */

static int centrino_verify_cpu_id(const struct cpuinfo_x86 *c, const struct cpu_id *x)

{

   if ((c->x86 == x->x86) &&

       (c->x86_model == x->x86_model) &&

       (c->x86_mask == x->x86_mask))

      return 1;

   return 0;

}

/* To be called only after centrino_model is initialized */

static unsigned extract_clock(unsigned msr, unsigned int cpu, int failsafe)

{

   int i;

   /*

    * Extract clock in kHz from PERF_CTL value

    * for centrino, as some DSDTs are buggy.

    * Ideally, this can be done using the acpi_data structure.

    */

   if ((centrino_cpu[cpu] == &cpu_ids[CPU_BANIAS]) ||

       (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_A1]) ||

       (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_A2]) ||

       (centrino_cpu[cpu] == &cpu_ids[CPU_DOTHAN_B0])) {

      msr = (msr >> 8) & 0xff;

      return msr * 100000;

   }

   if ((!centrino_model[cpu]) || (!centrino_model[cpu]->op_points))

      return 0;

   msr &= 0xffff;

   for (i=0;centrino_model[cpu]->op_points[i].frequency != CPUFREQ_TABLE_END; i++) {

      if (msr == centrino_model[cpu]->op_points[i].index)

         return centrino_model[cpu]->op_points[i].frequency;

   }

   if (failsafe)

      return centrino_model[cpu]->op_points[i-1].frequency;

   else

      return 0;

}

/* Return the current CPU frequency in kHz */

static unsigned int get_cur_freq(unsigned int cpu)

{

   unsigned l, h;

   unsigned clock_freq;

   cpumask_t saved_mask;

   saved_mask = current->cpus_allowed;

   set_cpus_allowed(current, cpumask_of_cpu(cpu));

   if (smp_processor_id() != cpu)

      return 0;

   rdmsr(MSR_IA32_PERF_STATUS, l, h);

   clock_freq = extract_clock(l, cpu, 0);

   if (unlikely(clock_freq == 0)) {

      /*

       * On some CPUs, we can see transient MSR values (which are

       * not present in _PSS), while CPU is doing some automatic

       * P-state transition (like TM2). Get the last freq set 

       * in PERF_CTL.

       */

      rdmsr(MSR_IA32_PERF_CTL, l, h);

      clock_freq = extract_clock(l, cpu, 1);

   }

   set_cpus_allowed(current, saved_mask);

   return clock_freq;

}

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

static struct acpi_processor_performance p;

/*

 * centrino_cpu_init_acpi - register with ACPI P-States library

 *

 * Register with the ACPI P-States library (part of drivers/acpi/processor.c)

 * in order to determine correct frequency and voltage pairings by reading

 * the _PSS of the ACPI DSDT or SSDT tables.

 */

static int centrino_cpu_init_acpi(struct cpufreq_policy *policy)

{

   union acpi_object      arg0 = {ACPI_TYPE_BUFFER};

   u32            arg0_buf[3];

   struct acpi_object_list      arg_list = {1, &arg0};

   unsigned long         cur_freq;

   int            result = 0, i;

   unsigned int         cpu = policy->cpu;

   /* _PDC settings */

   arg0.buffer.length = 12;

   arg0.buffer.pointer = (u8 *) arg0_buf;

   arg0_buf[0] = ACPI_PDC_REVISION_ID;

   arg0_buf[1] = 1;

   arg0_buf[2] = ACPI_PDC_EST_CAPABILITY_SMP | ACPI_PDC_EST_CAPABILITY_MSR;

   p.pdc = &arg_list;

   /* register with ACPI core */

   if (acpi_processor_register_performance(&p, cpu)) {

      dprintk(KERN_INFO PFX "obtaining ACPI data failed\n");

      return -EIO;

   }

   /* verify the acpi_data */

   if (p.state_count <= 1) {

      dprintk("No P-States\n");

      result = -ENODEV;

      goto err_unreg;

   }

   if ((p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) ||

       (p.status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE)) {

      dprintk("Invalid control/status registers (%x - %x)\n",

         p.control_register.space_id, p.status_register.space_id);

      result = -EIO;

      goto err_unreg;

   }

   for (i=0; i<p.state_count; i++) {

      if (p.states[i].control != p.states[i].status) {

         dprintk("Different control (%x) and status values (%x)\n",

            p.states[i].control, p.states[i].status);

         result = -EINVAL;

         goto err_unreg;

      }

      if (!p.states[i].core_frequency) {

         dprintk("Zero core frequency for state %u\n", i);

         result = -EINVAL;

         goto err_unreg;

      }

      if (p.states[i].core_frequency > p.states[0].core_frequency) {

         dprintk("P%u has larger frequency (%u) than P0 (%u), skipping\n", i,

            p.states[i].core_frequency, p.states[0].core_frequency);

         p.states[i].core_frequency = 0;

         continue;

      }

   }

   centrino_model[cpu] = kmalloc(sizeof(struct cpu_model), GFP_KERNEL);

   if (!centrino_model[cpu]) {

      result = -ENOMEM;

      goto err_unreg;

   }

   memset(centrino_model[cpu], 0, sizeof(struct cpu_model));

   centrino_model[cpu]->model_name=NULL;

   centrino_model[cpu]->max_freq = p.states[0].core_frequency * 1000;

   centrino_model[cpu]->op_points =  kmalloc(sizeof(struct cpufreq_frequency_table) *

                    (p.state_count + 1), GFP_KERNEL);

        if (!centrino_model[cpu]->op_points) {

                result = -ENOMEM;

                goto err_kfree;

        }

        for (i=0; i<p.state_count; i++) {

      centrino_model[cpu]->op_points[i].index = p.states[i].control;

      centrino_model[cpu]->op_points[i].frequency = p.states[i].core_frequency * 1000;

      dprintk("adding state %i with frequency %u and control value %04x\n", 

         i, centrino_model[cpu]->op_points[i].frequency, centrino_model[cpu]->op_points[i].index);

   }

   centrino_model[cpu]->op_points[p.state_count].frequency = CPUFREQ_TABLE_END;

   cur_freq = get_cur_freq(cpu);

   for (i=0; i<p.state_count; i++) {

      if (!p.states[i].core_frequency) {

         dprintk("skipping state %u\n", i);

         centrino_model[cpu]->op_points[i].frequency = CPUFREQ_ENTRY_INVALID;

         continue;

      }

      

      if (extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0) !=

          (centrino_model[cpu]->op_points[i].frequency)) {

         dprintk("Invalid encoded frequency (%u vs. %u)\n",

            extract_clock(centrino_model[cpu]->op_points[i].index, cpu, 0),

            centrino_model[cpu]->op_points[i].frequency);

         result = -EINVAL;

         goto err_kfree_all;

      }

      if (cur_freq == centrino_model[cpu]->op_points[i].frequency)

         p.state = i;

   }

   /* notify BIOS that we exist */

   acpi_processor_notify_smm(THIS_MODULE);

   return 0;

 err_kfree_all:

   kfree(centrino_model[cpu]->op_points);

 err_kfree:

   kfree(centrino_model[cpu]);

 err_unreg:

   acpi_processor_unregister_performance(&p, cpu);

   dprintk(KERN_INFO PFX "invalid ACPI data\n");

   return (result);

}

#else

static inline int centrino_cpu_init_acpi(struct cpufreq_policy *policy) { return -ENODEV; }

#endif

static int centrino_cpu_init(struct cpufreq_policy *policy)

{

   struct cpuinfo_x86 *cpu = &cpu_data[policy->cpu];

   unsigned freq;

   unsigned l, h;

   int ret;

   int i;

   /* Only Intel makes Enhanced Speedstep-capable CPUs */

   if (cpu->x86_vendor != X86_VENDOR_INTEL || !cpu_has(cpu, X86_FEATURE_EST))

      return -ENODEV;

   for (i = 0; i < N_IDS; i++)

      if (centrino_verify_cpu_id(cpu, &cpu_ids[i]))

         break;

   if (i != N_IDS)

      centrino_cpu[policy->cpu] = &cpu_ids[i];

   if (is_const_loops_cpu(policy->cpu)) {

      centrino_driver.flags |= CPUFREQ_CONST_LOOPS;

   }

   if (centrino_cpu_init_acpi(policy)) {

      if (policy->cpu != 0)

         return -ENODEV;

      if (!centrino_cpu[policy->cpu]) {

         dprintk(KERN_INFO PFX "found unsupported CPU with "

         "Enhanced SpeedStep: send /proc/cpuinfo to "

         MAINTAINER "\n");

         return -ENODEV;

      }

      if (centrino_cpu_init_table(policy)) {

         return -ENODEV;

      }

   }

   /* Check to see if Enhanced SpeedStep is enabled, and try to

      enable it if not. */

   rdmsr(MSR_IA32_MISC_ENABLE, l, h);

   if (!(l & (1<<16))) {

      l |= (1<<16);

      dprintk("trying to enable Enhanced SpeedStep (%x)\n", l);

      wrmsr(MSR_IA32_MISC_ENABLE, l, h);

      /* check to see if it stuck */

      rdmsr(MSR_IA32_MISC_ENABLE, l, h);

      if (!(l & (1<<16))) {

         printk(KERN_INFO PFX "couldn't enable Enhanced SpeedStep\n");

         return -ENODEV;

      }

   }

   freq = get_cur_freq(policy->cpu);

   policy->governor = CPUFREQ_DEFAULT_GOVERNOR;

   policy->cpuinfo.transition_latency = 10000; /* 10uS transition latency */

   policy->cur = freq;

   dprintk("centrino_cpu_init: cur=%dkHz\n", policy->cur);

   ret = cpufreq_frequency_table_cpuinfo(policy, centrino_model[policy->cpu]->op_points);

   if (ret)

      return (ret);

   cpufreq_frequency_table_get_attr(centrino_model[policy->cpu]->op_points, policy->cpu);

   return 0;

}

static int centrino_cpu_exit(struct cpufreq_policy *policy)

{

   unsigned int cpu = policy->cpu;

   if (!centrino_model[cpu])

      return -ENODEV;

   cpufreq_frequency_table_put_attr(cpu);

#ifdef CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI

   if (!centrino_model[cpu]->model_name) {

      dprintk("unregistering and freeing ACPI data\n");

      acpi_processor_unregister_performance(&p, cpu);

      kfree(centrino_model[cpu]->op_points);

      kfree(centrino_model[cpu]);

   }

#endif

   centrino_model[cpu] = NULL;

   return 0;

}

/**

 * centrino_verify - verifies a new CPUFreq policy

 * @policy: new policy

 *

 * Limit must be within this model's frequency range at least one

 * border included.

 */

static int centrino_verify (struct cpufreq_policy *policy)

{

   return cpufreq_frequency_table_verify(policy, centrino_model[policy->cpu]->op_points);

}

/**

 * centrino_setpolicy - set a new CPUFreq policy

 * @policy: new policy

 * @target_freq: the target frequency

 * @relation: how that frequency relates to achieved frequency (CPUFREQ_RELATION_L or CPUFREQ_RELATION_H)

 *

 * Sets a new CPUFreq policy.

 */

static int centrino_target (struct cpufreq_policy *policy,

             unsigned int target_freq,

             unsigned int relation)

{

   unsigned int    newstate = 0;

   unsigned int   msr, oldmsr, h, cpu = policy->cpu;

   struct cpufreq_freqs   freqs;

   cpumask_t      saved_mask;

   int         retval;

   if (centrino_model[cpu] == NULL)

      return -ENODEV;

   /*

    * Support for SMP systems.

    * Make sure we are running on the CPU that wants to change frequency

    */

   saved_mask = current->cpus_allowed;

   set_cpus_allowed(current, policy->cpus);

   if (!cpu_isset(smp_processor_id(), policy->cpus)) {

      dprintk("couldn't limit to CPUs in this domain\n");

      return(-EAGAIN);

   }

   if (cpufreq_frequency_table_target(policy, centrino_model[cpu]->op_points, target_freq,

                  relation, &newstate)) {

      retval = -EINVAL;

      goto migrate_end;

   }

   msr = centrino_model[cpu]->op_points[newstate].index;

   rdmsr(MSR_IA32_PERF_CTL, oldmsr, h);

   if (msr == (oldmsr & 0xffff)) {

      retval = 0;

      dprintk("no change needed - msr was and needs to be %x\n", oldmsr);

      goto migrate_end;

   }

   freqs.cpu = cpu;

   freqs.old = extract_clock(oldmsr, cpu, 0);

   freqs.new = extract_clock(msr, cpu, 0);

   dprintk("target=%dkHz old=%d new=%d msr=%04x\n",

      target_freq, freqs.old, freqs.new, msr);

   cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);

   /* all but 16 LSB are "reserved", so treat them with

      care */

   oldmsr &= ~0xffff;

   msr &= 0xffff;

   oldmsr |= msr;

   wrmsr(MSR_IA32_PERF_CTL, oldmsr, h);

   cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);

   retval = 0;

migrate_end:

   set_cpus_allowed(current, saved_mask);

   return (retval);

}

static struct freq_attr* centrino_attr[] = {

   &cpufreq_freq_attr_scaling_available_freqs,

   NULL,

};

static struct cpufreq_driver centrino_driver = {

   .name      = "centrino", /* should be speedstep-centrino,

                but there's a 16 char limit */

   .init      = centrino_cpu_init,

   .exit      = centrino_cpu_exit,

   .verify      = centrino_verify,

   .target      = centrino_target,

   .get      = get_cur_freq,

   .attr           = centrino_attr,

   .owner      = THIS_MODULE,

};

/**

 * centrino_init - initializes the Enhanced SpeedStep CPUFreq driver

 *

 * Initializes the Enhanced SpeedStep support. Returns -ENODEV on

 * unsupported devices, -ENOENT if there's no voltage table for this

 * particular CPU model, -EINVAL on problems during initiatization,

 * and zero on success.

 *

 * This is quite picky.  Not only does the CPU have to advertise the

 * "est" flag in the cpuid capability flags, we look for a specific

 * CPU model and stepping, and we need to have the exact model name in

 * our voltage tables.  That is, be paranoid about not releasing

 * someone's valuable magic smoke.

 */

static int __init centrino_init(void)

{

   struct cpuinfo_x86 *cpu = cpu_data;

   if (!cpu_has(cpu, X86_FEATURE_EST))

      return -ENODEV;

   return cpufreq_register_driver(&centrino_driver);

}

static void __exit centrino_exit(void)

{

   cpufreq_unregister_driver(&centrino_driver);

}

MODULE_AUTHOR ("Jeremy Fitzhardinge <jeremy@goop.org>");

MODULE_DESCRIPTION ("Enhanced SpeedStep driver for Intel Pentium M processors.");

MODULE_LICENSE ("GPL");

late_initcall(centrino_init);

module_exit(centrino_exit);

```

----------

## jlinkels

dkulp,

It makes a lot of sense what you say. However, I am surprised about the lack of replies to your post, acknowledging or denying what you say. I have a 133 MHz Sonoma myself, and I am worried about the power consumption as well.

I am trying to find out whether or not it is applicable what you say.

The value for "index" calculated in the OP macro is written to the IA32_PERF_CTL register. If you divide by 100 instead of 133, this value is too high. I am wondering whether the processor itself knows it runs at 133 and compensates for this value automatically.

Where did you find the values which have to be written to IA32_PERF_CTL? I have checked the Intel System Programmers manual (253668), but I could not find an explanation. Just the description of the register.

Also, a more general question. Intel stated frequency/voltage pairs in their datasheets for 100 MHz processors. The numbers of datasheets are 252665, 252612, 302029, 302189. The only datasheet I found about the 533 FSB processor was 305262. Unlike the datasheet for the Pentium M, freq/voltage pairs are lacking. Did anyone find those freq/volt pairs for the 533 FSB processors? 

jlinkels

----------

## dkulp

jlinkels,

For my 2.13Ghz Dothan, I kind of cheated.   I modified the speedstep-centrino.c file to printout the table queried from ACPI.  Basically, stuck a bunch of printk(KERN_WARN "...."); type things in centrino_cpu_init_acpi.    I then compiled the kernel with the "use acpi tables" thing enabled, and rebooted.   That got me the base table to start from.     Once you have the Hex values from the table, it was easy to figure out that the multipliers need to be from a 133Mhz base instead of the 100Mhz.  

The Dothan chips, when presented with a multiplier that is too high pretty much just set themselves to their highest setting.   Thus, that wasn't much of an issue.  The problem was, I couldn't get it to go to 800Mhz as the 800Mhz entry had a much higher multiplier.   Also, cpufreqinfo (and cat /proc/cpuinfo) ended up returning wacky results (at one point, it said it was running at 2.7Ghz, there was now way).  It all came down to the hard coded 100Mhz values.   

In anycase, I didn't look at any of the Intel docs.   I just queried the ACPI table to give me the basic starting point numbers, then went from there.  (Basically, grep 100 * and adjusted the 100's to 133's when it made sense).

Enjoy!

Dan

----------

## beatryder

has anyone attempted to contact Linus or Andrew about this?  Theses new cpus should be supported.

----------

## dgaffuri

Guys,

why don't you post changes to speedstep_centrino.c as patches instead of posting the whole source?

----------

## lsm

Is there any extra mileage from an undervolting hack on the latest mobile cpu processors?

Like the Intel Pentium M 760 2.0GHz 533MHz FSB, 2MB Cache?

That latest VAIO FS's sport the M 760/780, with a 533MHz front-side bus.

Out of the box with the ACPI derived tables turned "on" in the kernel, you get:

>cpufreq-info

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 800 MHz - 2.00 GHz

  available frequency steps: 2.00 GHz, 1.60 GHz, 1.33 GHz, 1.07 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, userspace, performance

  current policy: frequency should be within 800 MHz and 2.00 GHz.

                  The governor "ondemand" may decide which speed to use

                  within this range.

  current CPU frequency is 800 MHz (asserted by call to hardware).

Is an undervolting hack feasible (or dare I say, advisable) here?  How would you construct the table entries if you go this route in the kernel:

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y 

Thanks.

----------

## beatryder

This is what I have been wondering lately, as I have a 730 (1.6Ghz 533 FSB), and i have gotten, very strange results.

----------

## jlinkels

I added the tables for my processor (Dothan_C0, a.k.a. Sonoma) to the speedstep-centrino.c file, and re-compiled the kernel. Still have some side problems, but the most important is that the speedstep-centrino file IS used. I do see the correct info with cpufreq-info.

However, once I know that my speedstep-centrino.c file is good and actually used, I would like to experiment with different undervolting values. I know how to create those tables in speedstep-centrino.c, but is there a way to call a certain frequency/voltage pair from the outside? (user space).

e.g. can I have in my speedstep-centrino.c something like this:

```

static struct cpufreq_frequency_table dothan_1867[] =

{

        OP( 800, 760, 760, 760, 760),

        OP( 800, 800, 800, 800, 800),

        OP( 800, 880, 880, 880, 880),

        OP(1333, 1010, 1010, 1010, 1010),

        OP(1867, 1120, 1120, 1120, 1120),

        { .frequency = CPUFREQ_TABLE_END }

};

```

and somehow tweak the voltage?

Or should I enter the values in the table and recompile the kernel every time and try to see what is happening? That would be a tedious approach.

As I understand, minimum voltages may vary from one processor to the other, so using someone else's value might not be of much use. 

If someone believes differently, do you have a freq/volt table for a Sonoma 1.86 with 533 FSB?

jlinkels

----------

## bdz

I have the same concern as you. As I only have Linux on my laptop I cannot play with a user friendly windoz GUI to find the best values for my CPU. And compiling a new kernel and rebooting for each value I want to try is not something I want to do.

Maybe it is possible to try your idea of a frequency table with multiple entries for the same frequency and use the userspace governor to select a voltage value. But I guess that the frequencies must not be exactly identical. Otherwise the governor will always pick the same one.

Maybe using frequencies like 800, 801, 802, etc... would do the trick.

I'm currently trying another solution: modify the kernel source code to create a file in /sys/devices/system/cpu/cpu0/cpufreq/  that will contain custom voltage settings. And then have the speedstep-centrino driver using the values in this file to set the CPU voltage.

This way it would be possile to change the voltage from userspace without rebooting.

However I don't know anything about kernel hacking. So maybe it will take me more time to do this than to try every possible voltage settings  with the "compile your kernel and reboot" technique. But it will be more fun.

About the freq/volt pairs for the 533 FSB processors. Here are the default values retreived from ACPI on my CPU (1.6 GHz, 533 MHz FSB):

```
speedstep-centrino: adding state 6 with frequency 1596000 and control value 0c29

speedstep-centrino: adding state 7 with frequency 1330000 and control value 0a22

speedstep-centrino: adding state 8 with frequency 1064000 and control value 081a

speedstep-centrino: adding state 9 with frequency 798000 and control value 0612
```

So if you decode the hex values it looks like 133 is the correct value to use:

```
0c29: 12*133 = 1596 MHz, 41*16+700 = 1356 mV

0a22: 10*133 = 1330 MHz, 34*16+700 = 1244 mV

081a: 8*133  = 1064 MHz, 26*16+700 = 1116 mV

0612: 6*133  = 798  MHz, 18*16+700 = 988  mV
```

----------

## beatryder

how did you get that information?

----------

## bdz

I activated the cpufreq debug log in my kernel config and added the kernel parameter that enables these log in my grub.conf.

I'm not in front of my laptop right now and I don't remenber the exact names of these things.

But the kernel config item is near the other cpufreq items. And the kernel boot param is described in the help of the kernel config item. I used a value of 2 for this param.

Then after rebooting a "dmesg grep -i centrino" will show this information

----------

## dgaffuri

 *bdz wrote:*   

> I'm currently trying another solution: modify the kernel source code to create a file in /sys/devices/system/cpu/cpu0/cpufreq/  that will contain custom voltage settings. And then have the speedstep-centrino driver using the values in this file to set the CPU voltage.
> 
> This way it would be possile to change the voltage from userspace without rebooting.
> 
> However I don't know anything about kernel hacking. So maybe it will take me more time to do this than to try every possible voltage settings  with the "compile your kernel and reboot" technique. But it will be more fun.

 

Take a look at LKML archives. At the beginning of august there was someone who proposed a similar thing and posted the patches, search for PowerOP. I don't know if it's planned to go in mainstream.

----------

## bdz

Thank you for the information. I will have a look a this patch.

----------

## jlinkels

Some update:

I have changed the minimum speed setting to 533 MHz (4x bus clock) by putting this table in speedstep-centrino.c:

```

static struct cpufreq_frequency_table dothan_1867[] =

{

        OP( 533, 750, 750, 750, 750),

        OP( 800, 750, 750, 750, 750),

        OP(1067, 1084, 1084, 1084, 1084),

        OP(1333, 1116, 1116, 1116, 1116),

        OP(1600, 1116, 1116, 1116, 1116),

        OP(1867, 1132, 1132, 1132, 1132),

        { .frequency = CPUFREQ_TABLE_END }

};

```

I booted with the boot parameter cpufreq.debug=7. 

```

root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# cat  scaling_governor

userspace

```

I set the frequency to 533 MHz manually:

```

root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# echo "533000" > scaling_setspeed

```

After I did that again, the output of kern.log showed:

```

Oct 12 22:10:46 jlinkels_lt kernel: userspace: cpufreq_set for cpu 0, freq 533000 kHz

Oct 12 22:10:46 jlinkels_lt kernel: cpufreq-core: target for CPU 0: 533000 kHz, relation 0

Oct 12 22:10:46 jlinkels_lt kernel: freq-table: request for target 533000 kHz (relation: 0) for cpu 0

Oct 12 22:10:46 jlinkels_lt kernel: freq-table: target is 0 (533000 kHz, 1027)

Oct 12 22:10:46 jlinkels_lt kernel: speedstep-centrino: no change needed - msr was and needs to be 403

```

This looks very much like the cpu is running on 533 MHz with a core voltage of 750 mV. In any case, the IA32_PERF_CTL register returns 0403, which means that it really contains 0403.

04: 4 x 133 Mhz = 533 MHz

03: 16*3 + 700 mV = 748 mV

Could that be right? The reason that I am so doubtful is that this gives *exactly* the same output as if the processor is running on 800 MHz / 988 mV!!

```

root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# acpi -V

     Battery 1: charged, 98%

     Thermal 1: active[3], 40.0 degrees C

     Thermal 2: ok, 52.0 degrees C

     Thermal 3: ok, 28.0 degrees C

  AC Adapter 1: on-line

```

Could there be an additional piece of intelligence in the CPU which makes the CPU doing different things from the  IA32_PERF_CTL register?? Is there any way I can find out whether the CPU is running at 533 MHz?

As for the "on the fly" changing of the core voltage:

The correct way to do such things seems to be to communicate thru a file in the /sys/devices/system directory or so. The module would use a call to sysctl() to read or write from this file. I didn't need it so far (my CPU seems to run fine on 750 mV, if it really is doing so!).

I found the information here, but it requires careful studying to see what is going on.

Please comment

jlinkels

----------

## bdz

 *jlinkels wrote:*   

> 
> 
> Could that be right? The reason that I am so doubtful is that this gives *exactly* the same output as if the processor is running on 800 MHz / 988 mV!!
> 
> ...
> ...

 

Running a small CPU benchmark tool at 800 MHz and at 533 MHz will tell you if the CPU is actually using the specified frequency. I'm thinking to something like the BogoMips that is displayed at boot time. There exist a standalone program that can be used to compute this value. But any benchmark using only CPU will do it.

 *jlinkels wrote:*   

> 
> 
> I found the information here, but it requires careful studying to see what is going on.
> 
> 

 

I have carefully read this patch and I did not found anything wrong.

This is more or less the same kind of code that what I came up to. A little bit more sofisticated than mine to be honest. But I like simple things, so I will continue trying my own patch.

----------

## jlinkels

Some more update:

So to see, the my system is not running on 533 MHz. This is the output of /proc/cpuinfo:

```

jlinkels@jlinkels_lt:~# cat /proc/cpuinfo

[...]

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.86GHz

stepping        : 8

cpu MHz         : 532.048

cache size      : 2048 KB

[...]

bogomips        : 1050.91

```

Yes, that looks like 533 MHz. However when I run "mhz" from the lmbench benchmark suite, it indicated that the CPU was running on 798 Mhz. Now that could have been the quantum effect (as soon as you try to observe a particle, it state is altered) since the governor might have tried to increase the CPU frequency. This actually happened when I run "mhz" a few times in a quick fashion. The CPU frequency was pushed upwards. And came down again.

However, without running "mhz", and with the output of /proc/cpuinfo as above, I cat-ed /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq which showed:

```

root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# cat cpuinfo_cur_freq

798000

```

and to my surprise when I asked for /proc/cpuinfo again, it showed:

```

root@jlinkels_lt:/sys/devices/system/cpu/cpu0/cpufreq# cat /proc/cpuinfo

[...]

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.86GHz

stepping        : 8

cpu MHz         : 798.073

cache size      : 2048 KB

[...]

bogomips        : 1576.37

```

After this the CPU frequency would not go down anymore. This is logical, as speedstep-centrino asks for the current value of the IA32_PERF_CTL register and finds 0x0403. This is the same value as the speedstep-centrino wants to write there, so it draws the conclusion that nothing has to be written.

Surprisingly, when I do not cat cpufreq_cur_frequency in between, the governor nicely scales the frequency up and down until /proc/cpuinfo shows 533 Mhz again.

This behavior (showing a low frequency value in the beginning, and then locking at a certain minimum) is in line with other reports in this thread. My conclusion so far is:

- The CPU never actually scales down to 533 MHz. (or 400 MHz on a 400 MHz system), being 1x bus frequency

- For some time /proc/cpuinfo is not synchronized with cpuinfo_cur_frequency 

- There seems to be a mechanism which has to sync what the kernel thinks the CPU frequency is and the actual frequency. By trying to put an impossible value in the CPU control register, these value get out of sync.

Too bad...

Now since speedstep-centrino does write the value for voltage = 748 mV into the CPU, I am wondering whether this voltage is actually used, or that the entire write to IA32_PERF_CTL is ignored. Which would be very bad, because that means that still to high a value for the core voltage is used. I have my doubts whether that voltage is used. First, acpi -V shows the same temperature values as before (when I used the ACPI tables) and the fan keeps running and secondly, even with 748 mV at 800 MHz the computer remained as stable as a rock.

The only thing which I will still do is removing the 533 MHz from the speedstep-centrino table and see whether this some influence on the temperature on 800 MHz. 800 MHz is a valid P-setting, and I expect the requested core voltage to be used.

If anyone else has other experiences, or has obtained new results, please post here.

jlinkels

----------

## jlinkels

The plot thickens....

I have been running this configuration for a week now, and frequencies always were according to my last post. I have ksystemguard always running to see something unusual. Without changing anything, this morning /proc/cpuinfo showed:

```

jlinkels@jlinkels_lt:~$ cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.86GHz

stepping        : 8

cpu MHz         : 228.008

cache size      : 2048 KB

[...]

bogomips        : 449.38

and:

jlinkels@jlinkels_lt:~$ /usr/lib/lmbench/mhz

791 MHz, 1.26 nanosec clock

```

Which means the CPU still runs at 800 MHz

I could understand why /proc/cpufreq yielded 533 MHz, that is the lowest value in speedstep-centrino. But where 228 MHz comes from   :Question:   :Question:   :Question:   :Question:   :Question: 

(Yeah, I know it is 533/2   :Smile:  )

jlinkels

----------

## bdz

Some results from my tests:

Using my sysfs file patch I've been able to change the voltage of my CPU. I'm surprised by the very low values I can use. So even if the CPU doesn't crash with these values I'm not sure that it would be very stable in the long term if I keep them that low.

I also found that using the CPU temperature is not a very good way to know if the CPU uses the voltage I set, at leat for the low frequencies.

Looking at the current drown from the battery is more accurate.

Here is a summary of the measures I have done with the default and lowest voltage.

```
+-------+-------+------+--------+--------+--------+--------+--------+--------+--------+--------+

|   F   | Vacpi | Vmin | T1acpi | T1min  | T2acpi | T2min  | I1acpi | I1min  | I2acpi | I2min  |

| (MHz) | (mV)  | (mV) |  (°C)  |  (°C)  |  (°C)  |  (°C)  |  (mA)  |  (mA)  |  (mA)  |  (mA)  |

+-------+-------+------+--------+--------+--------+--------+--------+--------+--------+--------+

| 798   | 988   | 700  | 37/40  | 37/40  | 42/43  | 39/39  |  980   |  865   |  1220  |  1010  |

| 1064  | 1116  | 748  | 40/41  | 37/40  | 47/47  | 41/41  |  1110  |  880   |  1430  |  1070  |

| 1330  | 1244  | 828  | 43/44  | 37/40  | 53/53  | 42/42  |  1250  |  905   |  1730  |  1145  |

| 1596  | 1356  | 924  | 47/48  | 38/38  | 60/61  | 45/45  |  1420  |  950   |  2120  |  1250  |

+-------+-------+------+--------+--------+--------+--------+--------+--------+--------+--------+
```

Here is the meaning of the colum headers:

Vacpi:  Default voltage set by ACPI

Vmin:   Min voltage I'm able to set before the CPU freeze

T1acpi: Temperature at Vacpi and 0% CPU

T1min:  Temperature at Vmin  and 0% CPU

T2acpi: Temperature at Vacpi and 100% CPU

T2min:  Temperature at Vmin  and 100% CPU

I1acpi: Current at Vacpi and 0% CPU

I1min:  Current at Vmin  and 0% CPU

I2acpi: Current at Vacpi and 100% CPU

I2min:  Current at Vmin  and 100% CPU

I have not tested the min voltages during a very long time (no more than a few hours). So I'm not sure that the CPU is very stable at these settings. 

Actually I suspect that at least the values for 1.6 and 1.3 GHz are too low because I've seen some strange things in glxgears display that let me think that the CPU sometimes computes wrong values.

I'm currently searching for a better way than glxgears to check the correct behavior of the CPU.

----------

## Skystorm

 *bdz wrote:*   

> I'm currently searching for a better way than glxgears to check the correct behavior of the CPU.

 

You might want to try mprime, the equivalent of Prime95 from the Windows world. As far as I've read it's contained in the sci-mathematics/gimps package.

I haven't looked into undervolting under Linux, but for Windows Prime95's torture test mode is the quasi standard for overclocking/undervolting stability testing. It worked perfectly for me, undervolting my Centrino based laptop in my dual-boot Windows.

----------

## jlinkels

bdz,

Those are quite an impressive test results you showed. Great work. Where do you get the temperatures and currents from? Are they somewhere available in the /sys directory? Or did you probe for them somewhere deep in the hardware?

Do you intend to share your patch? I have a Sonoma 1.86 and I would like to try the same. (But avoid reinventing the wheel  :Smile:  )

Given these results, and the higher temperature at full load and high CPU frequency, it might finally become true that computers explode when they are overloaded. (Like in old SF movies)

jlinkels

----------

## bdz

I get temperature and current from "acpi -V" and "cat /proc/acpi/battery/BAT1/state". So it is not very accurate results.

I can share my patch. But it would need some polishing. And the one you put a link to is not very different than mine and is more user friendly.

----------

## jlinkels

bdz,

Thanks for the pointer. I never run the machine long enough on a battery to find this. The battery is exhausted before I can open a console in X. (Well, not literally)

What laptop do you have actually? I have a HP/Compaq NC6230.

I don't understand the high power consumption of this machine.

When I have switched off the backlight (pressing the small lid switch just under the screen DOES switch off the backlight, doesn´t it??) and wireless, at 800 MHz I still draw a current of 1250 mA. This increases to only 1420 mA when I switch the CPU to 1867 MHz. (Or I should say, the decrease is not sufficient?)

Just to be sure, I removed the 533 MHz setting from speedstep-centrino, leaving only "correct" states in. According to kern.log, a value of 0603 is written to IA32_PERF_CTL. If I run a small benchmark, CPU speed is showed correctly.

Can the CPU be defective or so??

Where the heck does the power go?

I still have to install the x.org server. The Radeon driver used here can throttle the speed of the graphic chip. Furthermore I might have to create the sysctl interface and do the same what you did and set the voltages manually to see if that has any influence.

Fot the time being I am not very happy with a battery life of 2 hours   :Sad: 

jlinkels

----------

## bdz

 *jlinkels wrote:*   

> bdz,
> 
> What laptop do you have actually? I have a HP/Compaq NC6230.jlinkels

 

I have a MSI S260

 *jlinkels wrote:*   

> When I have switched off the backlight (pressing the small lid switch just under the screen DOES switch off the backlight, doesn´t it??) and wireless, at 800 MHz I still draw a current of 1250 mA. This increases to only 1420 mA when I switch the CPU to 1867 MHz. (Or I should say, the decrease is not sufficient?)
> 
> ...
> 
> Can the CPU be defective or so??
> ...

 

You have a difference of 170 mA between 800MHz and 1867MHz. This is a very small difference compared to what I've seen on my laptop at default ACPI voltage (440 mA) but not compared to what I have with reduced voltages (85 mA)

So if you have reduced both 800MHz and 1867MHz voltages maybe there is nothing wrong with your CPU and it is another part of your computer that draw a lot of current.

Maybe you should measure the current with the original voltages to check that.

 *jlinkels wrote:*   

> 
> 
> Where the heck does the power go?
> 
> 

 

Very good question.

AFAIK the big power consumers are (in random order) screen backlight, CPU, hard drive, video card and chipset.

And the other parts that can use some current are CD/DVD drive, ethernet card, WiFi card, Fan, and any PCMCIA or USB device.

My laptop uses the video card integrated in the i915 chipset. Maybe it explains why it uses less power than your laptop. (but it surely has very poor 3D performances compared to your Radeon card)

And the screen is smaller also : 12 inch 1280x800.

 *jlinkels wrote:*   

> 
> 
> Fot the time being I am not very happy with a battery life of 2 hours  
> 
> 

 

Same thing for me. Even if my laptop does not use a lot of current it has a very small battery of 2200 mAh only. so my battery life is also around 2H.

That's why I'm very interested by this undervolting thing. But from my results it will give me something like 15 minutes increase in battery life. Not so much  :Sad: 

When I will have finished with undervolting tests I will give a try to laptop-mode to reduce the power used by the hard drive. And maybe try this CPU throtling thing.

But first I have to write some script that collect the measures and generates reports automatically because doing this manually starts becoming painful.

I will also try to share my sysfs patch. I have almost finished to clean up all the dirty parts. (I don't know where to host it though)

----------

## jlinkels

Yeah, that makes sense to put a 2200 mAh battery in a laptop which draws 1500 mA in normal operation, doesn't it?   :Shocked: 

About throttling, do you mean clock modulation? That is a weird thing. According to Intel it is mainly used for thermal management. For me thermal = power, so I would expect power saving here. After all, if yo have an 800 MHz clock, and you stop it 75% of the time, you only have 200 e6 clock cycles per second, isn't it?

That seems to be dead wrong!

First, it is claimed that "when reducing the number of clock cycles, a given task takes longer, hence the total power consumption during performing that task is more". Take a look at this thread.

Secondly, throttling is quite easy from userspace. See this how-to. I tried it yesterday once I learned from you how to measure the battery current. I set the CPU to 25% duty cycle. Current consumption went up from 1600 mA to 1800 mA!

Great, while the PC is doing nothing more than waiting for some keystrokes!

There is one other thing which might be interesting (item #478 on my to-do list). The Sonoma has two output signals which are used to switch the bus speed between 100 and 133 MHz (BSEL[0:1] I believe). These are OUTPUTS, en hence must be controlled from somewhere in side the processor. The Intel 915 chipset accordingly has 2 input pins for this purpose. These pins should be connected to each other. The P4 has a register to set the bus speed. If the Sonoma has these two outputs, I expect it to have such a register as well. Unfortunately it is hopelessly undocumented. The register is not mentioned for the Sonoma, maybe it is the same register as in the P4, maybe not.

Isn't it weird that you have to do so much effort to let your processor run as slow as possible?

jlinkels

----------

## bdz

Thank you for the information and your test results on throttling. I was already suspecting that this was a sucking feature. You confirm my thought. 

About the BSEL[0:1] pins, my idea was that they are hard wired inside the CPU. Maybe they are programable in some way but I've never read anything about that.

Anyway, on my laptop it will be useless because there is a hardware switch on the mainborad to select 100 or 133 MHz CPU input clock frequency.

And yeah, I understand why they make overclocking the CPU difficult. But why doing the same for underclocking/undervolting it? Maybe to sell more ULV CPU...

----------

## bdz

I checked the CPU throttling. On my laptop it does not increase the current consumption. But it does not reduce it either.

About my kernel patch to change the voltage through a sysfs file: I have added a page with all the details on the Gentoo wiki: 

http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU

Feel free to enhance it if you like.

----------

## Martini

Hi

bdz, thank you for this patch. I will try this now. I have the same Notebook (MSI S260 ,1600Mhz).

I have modified the speedstep_centrino.c file by Hand. Voltage down to 0.85V runs stable at 800MHz.

It's a good idea to regulate the core voltage via sysfs, great.

But another: can your share your kernel config and eventually your suspend scripts? I have problems with suspend to mem. After a hour in sleep-mode (suspend to ram) the notebook don't wake up. But after 10 or 15 min of sleeping waking up works.

I'm not using a swsuspend2 patched kernel. gentoo-sources 2.6.13-r3.

Thank you

Martin

Edit: patching works but compiling shows this:   :Confused: 

```

LD      init/built-in.o

LD      vmlinux

arch/i386/kernel/built-in.o(.text+0xb597): In function `store_user_voltage':

: undefined reference to `strtoul'

make: *** [vmlinux] Fehler 1

```

BTW: have you patched your fan controller? This works fine. The fan blows only over 60 degrees C.

Infos are here: (sorry its german)

http://www.msi-forum.de/thread.php?postid=147997#post147997Last edited by Martini on Fri Oct 21, 2005 5:20 pm; edited 1 time in total

----------

## bdz

 *Martini wrote:*   

> Hi
> 
> bdz, thank you for this patch.

 

You're welcome  :Smile: 

 *Martini wrote:*   

> I have the same Notebook (MSI S260 ,1600Mhz).

 

That's great! What do you think about creating a thread dedicated to this laptop on the Gentoo forum?

A maybe a page on the wiki later on?

 *Martini wrote:*   

> But another: can your share your kernel config and eventually your suspend scripts? I have problems with suspend to mem. After a hour in sleep-mode (suspend to ram) the notebook don't wake up. But after 10 or 15 min of sleeping waking up works.
> 
> I'm not using a swsuspend2 patched kernel. gentoo-sources 2.6.13-r3.

 

This is a bit off-topic for this thread. These files are rather big. If you create a thread I will post in it. Or you can contact me by mp or Jabber and I will send them by e-mail

(My Jabber ID should be somewhere at the bottom of all my post)

----------

## Martini

Hi

Yes, you are right. It's offtopic. I've started a thread about MSI S260 here:

https://forums.gentoo.org/viewtopic-p-2815242.html#2815242

Thank you

Martin

----------

## bdz

 *Martini wrote:*   

> Edit: patching works but compiling shows this:  
> 
> ```
> 
> LD      init/built-in.o
> ...

 

Your error happens at link time not when compiling the modified speedstep-centrino.c file. (or maybe there are some other errors above this one?)

And you use exactly the same kernel version as me.

If this is the only error I guess that maybe you have not done a "make clean" before building your kernel.

You should try this way:

 - Backup your .config

 - "make clean"

 - Restore your .config from backup

 - "make oldconfig"

 - "make && make modules_install" 

 - then proceed as usual to install the new kernelEdit:

I assumed that you don't use genkernel tell me if I'm wrong

I have added the script I use to measure temperature and current on the wiki page

----------

## Martini

Hi bdz

I have tested with:

make clean -> compiling --> same error

make mrproper -> restore old config -> compiling --> same error

deleted kernelsource -> emerge gentoo-sources -> patching -> restore old config -> compiling --> same error

I don't see other errors before. That's strange.   :Shocked: 

I never used genkernel.

I will testing it further tonight at home. A little bit stress here at work.   :Sad: 

Thank you

----------

## bdz

I will try to reapply my patch on clean kernel sources and compile with your .config

As you have modified it by hand, can you give me your speedstep-centrino.c file so that I can compare with mine?

----------

## Martini

Hi bdz

 *bdz wrote:*   

> I will try to reapply my patch on clean kernel sources and compile with your .config
> 
> As you have modified it by hand, can you give me your speedstep-centrino.c file so that I can compare with mine?

 

Thats great, thank you!

My speedstep_centrino.c is here

edit:

Found it! I have deactivated X86_SPEEDSTEP_CENTRINO_ACPI in my kernel config for my hand modified speedstep_centrino.c file. Now the linker error goes away.   :Wink: 

Testing now different voltage/freq combinations.   :Very Happy: 

Thanks, bdz!

----------

## bdz

Well I was about to answer this:

 *Quote:*   

> I tried to compile with your .config and that I've had this:
> 
> ```
> arch/i386/kernel/built-in.o(.text+0xb597): In function `store_user_voltage':
> 
> ...

 

But then I saw your edit. So it is OK for you now.   :Very Happy: 

But you wrote:

 *Martini wrote:*   

>  I have deactivated X86_SPEEDSTEP_CENTRINO_ACPI in my kernel config

 

and it is already deactivated in your .config file I downloaded from your site:

```
$ grep X86_SPEEDSTEP_CENTRINO_ACPI config.2.6.13.martini

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set
```

Did you meant "activated" or did you updated you .config before I downloaded it?

Anyway,

If anybody knows what I should add to have strtoul linked into the kernel please let me know. I'm too n00b in kernel hacking   :Embarassed: 

Edit:

 *Martini wrote:*   

> My speedstep_centrino.c is here

 

It's not the good file. My patch is not in there

----------

## Martini

Hi

Yes, the config you have downloaded is the old one from yesterday. Now i have compared your

config with my one in acpi-related things. I've modified it after your download.

Sorry for this mistake.   :Confused: 

 *Quote:*   

> I'm too n00b in kernel hacking 

 

Thats not true.   :Wink:  I'm impressed! 

BTW: the script from the wiki-page works here at the moment, thanks for it.

but i don't understand the "I= ... mv" what shows this exactly?

Thanks for your help

Martin

edit:

 *Quote:*   

> Martini hat folgendes geschrieben:
> 
> My speedstep_centrino.c is here
> 
> It's not the good file. My patch is not in there

 

Oh yes, this one is without your patch. I've modified by hand for a while with infos from this thread. I'm used it

for testing with voltage combinations.

I'm also sorry for this other mistake.   :Embarassed: 

I need holiday....

----------

## bdz

Oups!   :Embarassed:   it not mV but mA. It was too late when I wrote that (something like 1 or 2 AM)

I will correct the wiki page...

Edit:

It's done the wiki page is fixed.

As you now should have guessed it, these mA values are the current drawned from the battery. I use them to estimate how much power is used by the CPU.  Well you can not know the absolute value because it is the current drawn by all the components of the PC. But it can give a good relative measure of CPU power usage at different voltage/frequency/load

This of course needs to have A/C disconnected. Or all you will see it the rate at which the battery is charging, or 0 if it is fully charged.Last edited by bdz on Fri Oct 21, 2005 8:06 pm; edited 5 times in total

----------

## Martini

 *bdz wrote:*   

> Oups!    it not mV but mA. It was too late when I wrote that (something like 1 or 2 AM)
> 
> I will corect the wiki page...

 

... then i understand this.   :Very Happy: 

thx

----------

## bdz

 *Martini wrote:*   

> Yes, the config you have downloaded is the old one from yesterday. Now i have compared your
> 
> config with my one in acpi-related things. I've modified it after your download.
> 
> Sorry for this mistake. 

 

So you mean you now have X86_SPEEDSTEP_CENTRINO_ACPI that is enabled? Or is it also time for me to take some huge hollydays?   :Wink: 

----------

## Martini

 *Quote:*   

> So you mean you now have X86_SPEEDSTEP_CENTRINO_ACPI that is enabled?

 

Yes. Now it is enabled and i can make my kernel.

```

cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1084,1084,1084,1084,1084,1084,1084,988,908,860

```

```

2005/10/21 22:19:31  T = 47.0/48.0 °C  Avg(T) = 49.45193 °C    I = 944/944 mV  Avg(I) = 943.635 mV

2005/10/21 22:19:42  T = 47.0/48.0 °C  Avg(T) = 49.43389 °C    I = 943/945 mV  Avg(I) = 943.750 mV

2005/10/21 22:19:52  T = 47.0/48.0 °C  Avg(T) = 49.41799 °C    I = 944/946 mV  Avg(I) = 944.126 mV

2005/10/21 22:20:02  T = 47.0/48.0 °C  Avg(T) = 49.39925 °C    I = 943/944 mV  Avg(I) = 943.933 mV

2005/10/21 22:20:13  T = 47.0/48.0 °C  Avg(T) = 49.38268 °C    I = 943/971 mV  Avg(I) = 945.724 mV

```

```

martin-nb martin # cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.60GHz

stepping        : 8

cpu MHz         : 798.351

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2

bogomips        : 1598.74

```

edit:

after a while:

 :Smile:  but i dont know how stable is ist. 

```

martin-nb martin # echo "1084,1084,1084,1084,1084,1084,1000,900,850,800" > /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

martin-nb martin # cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1084,1084,1084,1084,1084,1084,988,892,844,796

```

```

2005/10/21 22:41:27  T = 47.0/47.0 °C  Avg(T) = 48.00907 °C    I = 945/954 mV  Avg(I) = 950.538 mV

2005/10/21 22:41:38  T = 47.0/47.0 °C  Avg(T) = 47.99998 °C    I = 945/947 mV  Avg(I) = 948.873 mV

2005/10/21 22:41:48  T = 47.0/47.0 °C  Avg(T) = 47.99098 °C    I = 946/947 mV  Avg(I) = 947.913 mV

2005/10/21 22:41:58  T = 47.0/47.0 °C  Avg(T) = 47.98206 °C    I = 946/946 mV  Avg(I) = 947.203 mV

2005/10/21 22:42:09  T = 47.0/47.0 °C  Avg(T) = 47.97321 °C    I = 944/946 mV  Avg(I) = 946.496 mV

2005/10/21 22:42:19  T = 47.0/47.0 °C  Avg(T) = 47.96444 °C    I = 943/947 mV  Avg(I) = 945.974 mV

2005/10/21 22:42:29  T = 47.0/47.0 °C  Avg(T) = 47.95575 °C    I = 944/947 mV  Avg(I) = 946.024 mV

```

----------

## dgaffuri

 *bdz wrote:*   

> 
> 
> ```
> arch/i386/kernel/built-in.o(.text+0xb597): In function `store_user_voltage':
> 
> ...

 

I think the problem is here

```
./include/acpi/platform/aclinux.h:#define strtoul simple_strtoul
```

this is included in speedstep_centrino.c only if X86_SPEEDSTEP_CENTRINO_ACPI is set. You should use

```
simple_strtoul
```

in your patch.

----------

## bdz

OK, thank you very much! I will try this... during the week-end.

----------

## dgaffuri

 *bdz wrote:*   

> OK, thank you very much! I will try this... during the week-end.

 

The weekend is already here   :Very Happy: 

BTW, I'm interested in this thread because I'm successfully using undervolting in Windows with my Toshiba Tecra M2 notebook. I will try you patch as soon as I can (now my root fs is messed up) and I'll post results here.

Thank you for your work.

----------

## bdz

[quote="Martini"] *Quote:*   

> after a while:
> 
>  but i dont know how stable is ist. 
> 
> ```
> ...

 

Hey! looks like it is working pretty nice!    :Very Happy: 

I forgot to talk about my tests with mprime.

But first I must thank the guy who has mentioned it in the previous page of this thread.

Thank you very much Skystorm!!! 

This tool is great to check CPU stabilty. It has detected problems for some settings in a few seconds where cpuburn was running with no error during hours   :Razz: 

Martini I strongly recommend you to use it.

My initial settings were these ones:

```
924,924,924,924,924,924,924,828,748,700
```

That is the min voltages I can set before my CPU freeze.

But after checking with mprime I had to increase to this:

```
956,956,956,956,956,956,956,860,764,700
```

Because it was clear that my CPU was computing wrong values at 1.6, 1.3 and 1 GHz.

----------

## bdz

 *dgaffuri wrote:*   

>  *bdz wrote:*   OK, thank you very much! I will try this... during the week-end. 
> 
> The weekend is already here  

 

Yeah I know   :Smile:  . But I think I will go to sleep before I can rebuild the kernel, test it during enough time to be confident in the new patch version and update the wiki page  :Wink: 

Well, actually I have already replaced strtoul by simple_strtoul and checked that it builds without eror when X86_SPEEDSTEP_CENTRINO_ACPI is not set.

Thank you again for your help   :Very Happy: 

I will update the wiki page and the files on my web site tomorrow or sunday after having performed some regression tests. (You can never trust what you do after mid night   :Twisted Evil:   )

Edit:

 *dgaffuri wrote:*   

> BTW, I'm interested in this thread because I'm successfully using undervolting in Windows with my Toshiba Tecra M2 notebook. I will try you patch as soon as I can (now my root fs is messed up) and I'll post results here.

 

A second beta tester! Cool!   :Very Happy: 

----------

## Martini

Good morning   :Smile: 

Bdz, yes.. now this works nice. I know the first 6 values i've used are nonsense.   :Smile: 

This was the first fast test before i put myself into deep-sleep-mode. Suspend to bed!   :Laughing: 

 *Quote:*   

> Martini I strongly recommend you to use it. 
> 
> My initial settings were these ones: 
> 
> Code: 
> ...

 

I will testing it over the weekend. But first i will reflash the fan controller with the original firmware.

The book becomes to warm completely without fan under 60C. I have never tested with undervolting before.

I think this works good with undervolting in combination with the original firmware.

Thanks bdz and dgaffuri

Martin

----------

## Skystorm

 *bdz wrote:*   

> But first I must thank the guy who has mentioned it in the previous page of this thread.
> 
> Thank you very much Skystorm!!! 

 

You are most welcome!    :Smile: 

 *bdz wrote:*   

> 
> 
> This tool is great to check CPU stabilty. It has detected problems for some settings in a few seconds where cpuburn was running with no error during hours  
> 
> Martini I strongly recommend you to use it.
> ...

 

Same for me (only done undervolting under Windows so far), it seemed stable at lower voltages but some minutes of Prime95 (equivalent of mprime) torture mode produced errors, so I had to increase the voltages a little.

Haven't gotten around to try this under Linux, but I hope eventually I will...   :Wink: 

----------

## bdz

After having tested it over the week-end I think the new patch version is ok. I have updated it on the wiki page

----------

## bdz

I have added the procedure and the script I have used to find the minimum voltages that my CPU can acheive on the wiki page

----------

## Martini

Hello undervolting heroes   :Very Happy: 

 *bdz wrote:*   

> I have added the procedure and the script I have used to find the minimum voltages that my CPU can acheive on the wiki page

 

Wow, thats great, bdz. I will test it as soon as possible. I've tested with mprime but only at 800MHz@700mv only.

This works without errors over 2 hours.

Thanx

greets

Martin

edit

just one question:

Since your patch works with X86_SPEEDSTEP_CENTRINO_ACPI (right ?), must i switch this on or off in my kernel.

I'm a little bit confused about this. It works without this.

Thanx

----------

## bdz

Same thing for me. 800 MHz @ 700 mV -> mprime has run one full night with no error. 

However for the other frequencies I had to raise a little bit the voltage from the min.

I will add a second table with my safe voltages on the wiki page when I will have some free time to write the next chapter. (Or maybe someone else wants to write it?)

About X86_SPEEDSTEP_CENTRINO_ACPI: The patch doesn't care if you use the ACPI table or the builtin tables. As long as the speedstep-centrino driver has successfully initialized the frequency table structure it's fine.

----------

## Martini

 *Quote:*   

> About X86_SPEEDSTEP_CENTRINO_ACPI: The patch doesn't care if you use the ACPI table or the builtin tables. As long as the speedstep-centrino driver has successfully initialized the frequency table structure it's fine.

 

Understand, thx for the enlightenment.   :Smile: 

 *Quote:*   

> I will add a second table with my safe voltages on the wiki page when I will have some free time to write the next chapter. (Or maybe someone else wants to write it?) 

 

Thats helpfull.

I would help with pleasure, but you point about you speak and i'm only a beta tester.   :Embarassed:  Sorry

uahh... crappy english. I hope this understand everyone.   :Confused: 

Thx

Martin

----------

## bdz

 *Martini wrote:*   

> 
> 
> I would help with pleasure, but you point about you speak and i'm only a beta tester.   Sorry
> 
> 

 

Not sure I understand that correctly.

But I think I was also not very clear myself:

I would like that the wiki page contain sample voltages of several people, not only me.

And it's a wiki page. So the spirit is: anybody is welcome to modify it and add its contribution.

At the moment it contains only things from me. So the text is like "this is what I have done".

But it would be very nice if other guys would add add some stuff in it and that it becomes something like "this is what we have done" or something like a howto, not only my personal experience.

bdzLast edited by bdz on Wed Oct 26, 2005 9:44 pm; edited 1 time in total

----------

## Martini

Arrghh..   :Evil or Very Mad: 

I'm sorry. I totally misunderstood that you have wrote. Now it's clear.

Please forget my previous posting.

Sorry

Martin

----------

## bdz

No problemo  :Wink: 

----------

## rschwarze

Thx for all your work!

I have a few questions:

Does your patch also work for my Pentium M 1.4 Dothan?

The Link for the speedstep-centrino.c on the wiki is probably wrong. I only can get the patch there.

----------

## bdz

I don't have a Pentium M 1.4 Dothan to test the patch on it but I think it should work. The only way to be sure is that you try it yourself  :Wink: 

The link on the wiki page was wrong. I have fixed it. 

Thank you for the information.

----------

## dgaffuri

Fiinally I did it. I've tortured test with mprime my Toshiba Tecra M2 (Pentium-M 750 2 Ghz) for 36 hours at all freqs. I've published safe voltages on the wiki. I tested this same voltages in Windows XP with prime95 in August, and from then I run with this voltages (controlled by CHC) 5 days out of 7.

In my Linux tests I got 10 degrees less at 600 and 2000 Mhz, with fan needed only at 1400 instead of 800. Battery charge after a 50 minutes test is 20% more. And I confirm that the wiki patch applies correctly to a 2.6.14 kernel.

If someone is interested in details I will post them here.

----------

## rschwarze

i dont know what i did wrong.

i used the speedstep-centrino.c from the wiki and recompiled the kernel.

now i have the old (bad) voltages back (so far so good   :Confused:  ) but i cant find the /sys/devices/system/cpu/cpu0/cpufreq/voltage_table.

is there anything else i have to change? maybe something in the kernel-config?

----------

## bdz

There should be nothing else to do. 

Obviously you need to have the "Intel Enhanced SpeedStep" option in the kernel. 

And I think that "Use ACPI tables to decode valid frequency/voltage pairs" or "Built-in tables for Banias CPUs" need to be enabled (at least one of these 2 options or both enabled)  But I guess you already have this correctly configured.

Are you sure that your kenel is compiled with the patched file? Can you try to run the command below and check that you have the same output to be sure?

```
$ grep "freq_attr" /usr/src/linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c

static struct freq_attr centrino_freq_attr_voltage_table =

static struct freq_attr* centrino_attr[] = {

        &cpufreq_freq_attr_scaling_available_freqs,

        &centrino_freq_attr_voltage_table,
```

----------

## rschwarze

now i have use_acpi_tables activated, but it still don't work.  :Sad: 

i'm using "linux-2.6.13-reiser4-r5" kernel source and with my own speedstep-centrino.c everything works fine.

any other suggestions or things i can try?

```

# ls /sys/devices/system/cpu/cpu0/cpufreq

affected_cpus     scaling_available_frequencies  scaling_governor

cpuinfo_max_freq  scaling_available_governors    scaling_max_freq

cpuinfo_min_freq  scaling_cur_freq               scaling_min_freq

ondemand          scaling_driver                 stats

```

```

# grep "freq_attr" /usr/src/linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 

static struct freq_attr centrino_freq_attr_voltage_table = 

static struct freq_attr* centrino_attr[] = {

        &cpufreq_freq_attr_scaling_available_freqs,

        &centrino_freq_attr_voltage_table,

```

----------

## bdz

 *rschwarze wrote:*   

> 
> 
> i'm using "linux-2.6.13-reiser4-r5" kernel source and with my own speedstep-centrino.c everything works fine.
> 
> 

 

Is the speedstep-centrino.c file of this kernel the same a in the gentoo-sources-2.6.13 kernel? If they are not exactly the same you should patch your kernel with the diff file instead of using my speedstep-centrino.c.

 *rschwarze wrote:*   

> 
> 
> any other suggestions or things i can try?
> 
> 

 You can try to

```

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

```

To check that the centrino driver is used.

And maybe activate the cpufreq debug log and look in dmesg for error messages.

Edit:

To activate cpufreq debug log you need to enable the kernel config:

```
-> Power management options (ACPI, APM)

  -> CPU Frequency scaling

    -> CPU Frequency scaling (CPU_FREQ [=y])

      -> Enable CPUfreq debugging 
```

And add the boot parameter "cpufreq.debug=7" to your grub.conf

Then right after booting run this:

```
dmesg | grep -i centrino
```

----------

## rschwarze

i have never used the original speedstep-centrino.c. since 5 month i'm using the speedstp-centrino.c with tuned voltages as described earlier in this thread.

```
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

centrino

```

i will try the debugging now

thx for the fast answers!

edit: now with the debugging, the scaling driver has changed to cpufreq??

the errormessage:

```
dmesg | grep -i centrino

cpufreq-core: trying to register driver centrino

speedstep-centrino: Invalid control/status registers (1 - 1)

speedstep-centrino: <6>speedstep-centrino: invalid ACPI data

speedstep-centrino: <6>speedstep-centrino: no table support for CPU model "Intel(R) Pentium(R) M processor 1.40GHz": 

cpufreq-core: no CPU initialized for driver centrino

```

can i somehow combine my speedstep-centrino with the frequencies for my cpu with your patch?

----------

## bdz

 *rschwarze wrote:*   

> can i somehow combine my speedstep-centrino with the frequencies for my cpu with your patch?

 

Yes I think this is possible. 

Adding your frequency table to my speedstep-centrino.c file or adding my modifications to your file should work. If you want to manually add my patch to your file just follow the instructions in chapter 3.3 of the wiki page. It's only a matter of 2 copy and paste.

----------

## rschwarze

Finally it works! thx very much for your help!

With my old speedstep-centrino.c

with the changes you explain in the howto

without "use_acpi_tables" (because my fucking acpi doesnt know my cpu  :Wink: )

One more question: Do you have the "echo ..." stuff in your local.start or how did you do this? I think that would be a useful hint in the howto.

edit: my actual table of stable voltages (Pentium M 710):

0600: .700

0800: .700

1000: .780

1100: .812

1200: .860

1400: .940

----------

## bdz

@rschwarze:

Glad to know it's finally working for you. thank you for the feedback.

And yes, to set the voltages at boot time I have added the "echo ..." to my "/etc/conf.d/local.start". I agree with you that this would be a usefull information to add in the howto. But I do not have a lot of time to update it right now.

@dgaffuri:

Thank you very much for your feedback and for the voltages you have added to the wiki page.

How did you found these voltages? Did you tried to quickly decrease the voltage until the CPU freeze. And then slowly increasing the voltage while checking with mprime.

Or did you used a safer method like slowly decreasing the voltages while checking with mprime? If it is the 2nd case I would be interested to know how long it took you and if it allowed you to find your safe voltages without crashing your system.

----------

## dgaffuri

I found these voltages some month ago on windows, using Centrino Hardware Control. Of course with your patch and mprime this may be done in linux too. I used the second method, running at decreasing voltages for each frequency until I got an error from prime95 torture test.

The starting voltages were a mix from the VID#D specifications from Intel (my ACPI reports the VID#A values to kernel) and the results published by other people with similar CPUs in various forums. This is the table I used, first four columns are from Intel specs, the last is the final tested frequency (the one I put in the Wiki). I don't remember the exact voltages that I started from, but I knew for example that 700 mV at 600 MHz was an achievable target, so I probably started to test from 0.800 instead of 0.988.

```

Freq   VID#A   VID#B   VID#C   VID#D   Tested

2000   1.340   1.324   1.308   1.276   1.196

1800   1.292   1.276   1.276   1.244   1.084

1600   1.244   1.228   1.228   1.196   1.004

1400   1.196   1.180   1.180   1.164   0.924

1200   1.148   1.132   1.132   1.116   0.844

1000   1.100   1.084   1.084   1.084   0.764

 800   1.052   1.036   1.036   1.036   0.700

 600   0.988   0.988   0.988   0.988   0.700

```

I first run prime95 for 15 minutes at each frequency/voltage pair, decreasing voltage by 0.48 until I got an error, and then increasing by 0.16 until no error appeared. So for 2.0 GHz I could have run at 1.276, 1.228, 1.180, getting an error here, and at 1.196 with no errors. These took about one day.

Then I run a second test for a couple of hours at each frequency. I got about 3 or 4 errors in total, so I had to test for about 24 hours. This took me other two days.

Finally I ran a longer test with 2.00 GHz and 800 MHz (note that voltage at 800 is the same that at 600), about 8 hours each, and tested the other ones (except 600) for 3 or 4 hour again. This took other 2 days.

It was a lot ot time, but except for the first day you only have to check and change frequency every some hour. I've never had a crash during these tests.

Some day ago I applied your patch, set voltages to my values and ran a 36 hours mprime torture test. During this I used a modified version of your script (posted below) to print temp and battery consumption while switching frequency every 5 minutes. I then run the same test with standard voltages and compared the results, that were good in my opinion:

```

Time       Freq   Volt   Battery Temp                 Discharge (mW)

                         (mWh)   Min    Max    Avg    Min     Max     Avg

                           

19:12:18   2000   1340   44571   64.1   75.5   74.3   35326   36190   35739.6

19:18:17   1800   1292   41029   57.8   70.5   68.3   31924   34117   32527.9

19:24:16   1600   1244   37648   56.6   66.0   62.9   28814   31093   29236.7

19:30:16   1400   1196   34711   55.5   65.5   57.6   26384   27723   26839.3

19:36:16   1200   1148   31849   55.4   65.1   60.0   24397   26114   24800.4

19:42:20   1000   1100   29322   54.0   65.1   61.0   22647   23533   22818.4

19:48:28    800   1052   26870   54.0   65.0   61.4   20833   21826   21101

19:54:40    600    988   24570   59.6   62.4   61.3   19364   20293   19654.1

20:00:58         22334                  

                           

16:22:36   2000   1196   44571   58.1   67.4   66.5   25218   30099   29544.2

16:28:34   1800   1084   41601   50.8   65.1   59.1   25660   28436   26022.7

16:34:34   1600   1004   39106   55.0   65.2   60.4   23047   24386   23455

16:40:34   1400    924   36698   55.0   65.1   60.8   21049   22550   21441

16:46:36   1200    844   34581   56.4   62.1   60.2   19450   20466   19848.5

16:52:39   1000    764   32508   55.8   60.1   57.8   18489   18835   18662.3

16:58:45    800    700   30553   52.0   55.6   53.7   17571   17982   17604.3

17:04:57    600    700   28674   50.9   52.4   51.7   16869   17571   17121.4

17:11:15         26838

```

If someone is interested here's the script (I've adapted for my laptop, fan under ACPI doesn't work and I used lm_sensors to get temps, but everything is in the functions at the beginning).

```
#!/bin/bash

# Configuration

declare -ai frequencies=(2000 1800 1600 1400 1200 1000  800  600)

declare -ai minVoltages=(1196 1084 1004  924  844  764  700  700)

declare -ai stdVoltages=(1340 1292 1244 1196 1148 1100 1052  988)

SamplingPeriod=1   # interval between samples

DisplayPeriod=300   # interval between display

ChangePeriod=300   # interval between frequency changes

ChangeDelay=30      # allow battery drain stabilization at freq change

fanString=("off" "on")   # decode numeric (0/1) fan state

TempUnit="°C"

CurrUnit="mW"

# Functions

getVoltages() {

    echo $(cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table \

            | cut --delimiter="," \

             --output-delimiter=" " \

        --fields=1-${#frequencies[*]} \

          )

}

setVoltages() {

    echo $(echo $* \

            | cut --delimiter=" " --output-delimiter="," --fields=1- \

          ) >/sys/devices/system/cpu/cpu0/cpufreq/voltage_table

    echo "Voltages set to $(getVoltages)"

}

getTemperature() {

    echo $(sensors | grep 'CPU Temp') | cut -f3 -d" " | cut -c2-

}

getCurrent() {

    echo $(grep 'present rate:' /proc/acpi/battery/BAT1/state) \

        | cut -f3 -d" "

}

getFrequency() {

    echo "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq) / 1000" \

        | bc

}

setFrequency() {

    local -ai voltages=($(getVoltages))

    cpufreq-set -f $((${frequencies[$1]}*1000))

    echo

    echo -n "$(getDate) Frequency: $(getFrequency) MHz (${voltages[$1]} mV)  "

}

getFan() {

    echo $(grep 'running' /proc/acpi/toshiba/fan) | cut -f2 -d" "

}

getBattery() {

    echo $(grep 'remaining capacity:' /proc/acpi/battery/BAT1/state) \

        | cut -f3 -d" "

}

getDate() {

    echo $(date "+%H:%M:%S")

}

display() {

    echo

    echo -n "$(getDate)" \

       "$TMin/$TMax/$TAvg $TempUnit $IMin/$IMax/$IAvg $CurrUnit  "

}

displayFan() {

    echo -n "$(getDate) Fan ${fanString[$Fan]} at $(getTemperature) $TempUnit  "

}

displayBattery() {

    echo -n "Battery: $(getBattery) ${CurrUnit}h  "

}

# Display configuration

echo "Sampling period:         $SamplingPeriod s"

echo "Display period:          $DisplayPeriod s"

echo "Change Frequency period: $ChangePeriod s"

# Reset voltages on exit

trap "setVoltages $(getVoltages) >&2" EXIT 

# Set and display voltages

setVoltages ${stdVoltages[*]}

# Get and display fan status

Fan=$(getFan); displayFan

# Main loop

#while $(ps -C mprime >/dev/null)

#do

    for freqIndex in ${!frequencies[*]}

    do

        # Variables initialization

        TMin=100

        TMax=0

        IMin=100000

        IMax=0

        TSum=0

        ISum=0

        PCount=0

        SCount=0

        # Set frequency

   setFrequency $freqIndex

   displayBattery

        # Display loop

        LastChange=0

        LastDisplay=0

        while $(ps -C mprime >/dev/null) && [ $LastChange -lt $ChangePeriod ]

        do

            # Check for fan

            NFan=$(getFan)

            if [ $NFan -ne $Fan ]; then

         Fan=$NFan

         displayFan

            fi

            # Wait until next sampling period

            sleep $SamplingPeriod

            PCount=$(($PCount+1))

            if [ $PCount -le $ChangeDelay ]; then

           if [ $(($PCount%10)) -eq 1 ]; then

             echo -n '*' >&2

           fi

                continue;

            fi

            SCount=$(($SCount+1))

            if [ $(($SCount%10)) -eq 1 ]; then

              echo -n '.' >&2

            fi

            LastDisplay=$(($LastDisplay+$SamplingPeriod))

            LastChange=$(($LastChange+$SamplingPeriod))

            # Get temperature

            T=$(getTemperature)

            TSum=`echo "$TSum + $T" | bc`

            TAvg=`echo "scale=1; $TSum / $SCount" | bc`

            # Get current

            I=$(getCurrent)

            ISum=`echo "$ISum + $I" | bc`

            IAvg=`echo "scale=1; $ISum / $SCount" | bc`

            # Compute min/max values

            TMax=`echo "a=$T; b=$TMax; if (a > b) a else b" | bc`

            TMin=`echo "a=$T; b=$TMin; if (a < b) a else b" | bc`

            IMax=`echo "a=$I; b=$IMax; if (a > b) a else b" | bc`

            IMin=`echo "a=$I; b=$IMin; if (a < b) a else b" | bc`

            # Display if required

            if [ $LastDisplay -ge $DisplayPeriod \

               -o $LastChange -ge $ChangePeriod ]; then

                LastDisplay=0

                display

                #TMax=$T

                #TMin=$T

                #IMin=$I

                #IMax=$I

            fi

        done

    done

#done

echo; echo -n "$(getDate) done  "; displayBattery; echo
```

bdz, thanks for your patch and the Wiki   :Smile: 

----------

## bdz

Your're welcome.

Thank you for the information on your procedure to find voltages.

----------

## pumpkin0

I'm trying to find the optimal settings for my laptop (IBM R51, PM 725). But something is fishy: 

After changing running a load test (like bziping a file from ramdisk or prime95) the discharge rate never retourns to the previous rate. Example:

i set the CPU to 600MHz @ 700mV => 9.7W. I bzip a file on a ramdisk (=>11.4 W due to high load). Afterwards the rate goes down to 9.2 W without any changes to voltage, network, screen,...

Anybody observing a similar effect ?

It cannot be the HD, as it is turned off at startup (seeking 100% slience => running of ramdisk). Network / wireless are down too. The fan is not running. I have nothing on USB. It does not depend on the remaining charge.

Thanks

----------

## bdz

 *pumpkin0 wrote:*   

> i set the CPU to 600MHz @ 700mV => 9.7W. I bzip a file on a ramdisk (=>11.4 W due to high load). Afterwards the rate goes down to 9.2 W without any changes to voltage, network, screen,...
> 
> 

 

How do you measure these "W" values?

----------

## pumpkin0

Like everybody else:

wathc -n 2 "cat /proc/acpi/battery/BAT0/state | grep rate"

I have to wait for 20-30 secondes for the value to become stable.

OK, it's marked in mW (for milli Watt), but W (for watt) is a more familiar term for me.

----------

## rschwarze

Hi pumpkin0,

it would be great, if you could explain how you do that thing with the ramdisk and the harddrive shutdown. or is there a nice howto out there?

thx!

----------

## pumpkin0

Hi rschwarze,

This is kind of offtopic, so if any mods want to move me ...   :Wink: 

I didn't find any Howto on this and i don't think there will ever be THE Howto on this. As base i used debian (now that's offtopic). I removed everything i didn't need for day-to-day work (KDE, /usr/share/locale/japanese & Co, /usr/src, /var/cache/...). The rest still didn't fit into the RAM, so i had to trick a bit. I used:

- squashfs

- unionfs

- ramfs

- 1 GB RAM

- and a hand-crafted initrd-init and umount-scripts

Usually noone writes to /usr, /lib /sbin, /opt & co (except installers).  So these can be readonly. Squashfs is a compressed, readonly fs, that came in handy (Dont use cramfs, it will fail. cloop is also complex...). I created squashfs images for /usr, /opt, /bin, /sbin, /opt and /var. (total: +-460 MB).

At startup the kernel loads a initrd-image and launches a script called /sbin/init (or so...). That script has to be modified a bit. It creates a ramfs, mounts the HD-based root-partition into it. The ramfs will later be the /, the real HD-based root will be called /HD. The script creates directories for /usr /sbin..., then copies the squashfs-images to the ramfs-dir. It mounts all the images (except var) on the ramfs.

/var is special. It has to be r/w. i mount the image under /var.squashfs and create a dir called /var.rw. These 2 are combined with a unionfs to a r/w /var.

I copy my home-dir, /root, /dev and /etc to the ramfs (devfs didn't work for me). After that it's save to switch to the newly created / and continue booting as usual (including running hdparm -S 5 to cause a spindown after 25 sec of inactivity)

The shutdown-scripts (inside the unmount-script) copy the home and /etc back to the disc. If the batt ever fails or i crash the system: bad luck, everything since last shutdown is lost. I don't save /var (i would have to recreate the squashfs.image everytime.... ). If i want to install something i just reboot w/o initrd, install, then recreate all images (the script takes 20 min, the HD is so slloowwww). I have +- 400 MB RAM left after startup. Enough for websurfing / light work. Not enough for kernel-recompiles or any other serious work.

The runtime is +1 hour compared to the first test (now just under 4 hours). I also tuned 

- the centrino-settings using cpufreqd, 

- the frequency for my gfx-card (radeon 7500 => use rovclock, it rocks)

- the powersavemode for the WLAN-card (iwconfig eth1 power something...)

And now i'm about to change the voltages for the CPU. Used on the desk the fan does not run. Even high loads for 20-30 sec does not trigger it. Out of the box it ran all the time at a low speed. Now i want more. I want it to stay off while i use the laptop on it's normal surface: the lap.

If anybody wants the scripts or needs more info: send a pm with your email.

600MHz @ 700mV is stable so far, the CPU is at 38°C (laptop on desk) after reading my mail, slashdot, some comics and writing this. I think using it on lap w/o fan for 1-2 hours may be possible.

And now to the topic: any ideas why my discharges rates are so "unpredictable" ? I need exact numbers if i want to fine-tune this system any more. Waiting for the batt to run flat is not an option, i lose /home each time...

Thanks

----------

## bdz

 *pumpkin0 wrote:*   

> Like everybody else:
> 
> wathc -n 2 "cat /proc/acpi/battery/BAT0/state | grep rate"
> 
> I have to wait for 20-30 secondes for the value to become stable.
> ...

 

This is also what I do, but I do not have a value in mW but in mV:

```
$ cat /proc/acpi/battery/BAT1/state

present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            794 mA

remaining capacity:      1854 mAh

present voltage:         16052 mV

```

My guess is that your rate is current * voltage. And the problem is that the battery voltage decreases as the battery discharges.

----------

## dgaffuri

Some battery report capacity in mAh and some in mW, like mine does.

----------

## bdz

@dgaffuri : Do you really mean capacity or discharge rate?. pumpkin0 is talking about discharge rate. This I can understand that it can be in mW instead of mA.  But for the capacity it is a weird unit to express it. There is no time in mW.

Just for my personal information I would like to see your complete /proc/acpi/battery/BAT1/state and /proc/acpi/battery/BAT1/info content. Can you post it here?

@pumpkin0: Can you also post your /proc/acpi/battery/BAT1/state and /proc/acpi/battery/BAT1/info content?

----------

## dgaffuri

Sorry, of course you're right. I meant mWh for capacity and mW for (dis)charge rate.

```
~ # cat /proc/acpi/battery/BAT1/state

present:                 yes

capacity state:          ok

charging state:          charging

present rate:            19126 mW

remaining capacity:      42692 mWh

present voltage:         11370 mV

~ # cat /proc/acpi/battery/BAT1/info

present:                 yes

design capacity:         47520 mWh

last full capacity:      44571 mWh

battery technology:      rechargeable

design voltage:          10800 mV

design capacity warning: 896 mWh

design capacity low:     0 mWh

capacity granularity 1:  10 mWh

capacity granularity 2:  10 mWh

model number:            G71C0003V610

serial number:           0000000506

battery type:            Li-ION

OEM info:

```

----------

## pumpkin0

```
ram@soak:~$ cat  /proc/acpi/battery/BAT0/state 

present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            8315 mW

remaining capacity:      42520 mWh

present voltage:         12301 mV

ram@soak:~$ cat  /proc/acpi/battery/BAT0/info  

present:                 yes

design capacity:         47520 mWh

last full capacity:      42560 mWh

battery technology:      rechargeable

design voltage:          10800 mV

design capacity warning: 2128 mWh

design capacity low:     200 mWh

capacity granularity 1:  1 mWh

capacity granularity 2:  1 mWh

model number:            IBM-08K8193

serial number:             246

battery type:            LION

OEM info:                SANYO

ram@soak:~$ uname -a

Linux soak 2.6.11 #2 Tue Nov 8 20:47:52 CET 2005 i686 GNU/Linux

```

the "present rate" is not really stable, it woobles all the time.

@ bdz: shouldn't watt = volt * amp stay more or less stable for any given load ? If the voltage goes down, the amp should go up...

----------

## rschwarze

```

 ~ $ cat  /proc/acpi/battery/BAT0/state

present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            923 mA

remaining capacity:      4009 mAh

present voltage:         16555 mV

 ~ $ cat  /proc/acpi/battery/BAT0/info

present:                 yes

design capacity:         4400 mAh

last full capacity:      4032 mAh

battery technology:      rechargeable

design voltage:          14800 mV

design capacity warning: 440 mAh

design capacity low:     220 mAh

capacity granularity 1:  1 mAh

capacity granularity 2:  1 mAh

model number:            0

serial number:           4455

battery type:            LION

OEM info:                SANYO

```

----------

## bdz

 *pumpkin0 wrote:*   

> @ bdz: shouldn't watt = volt * amp stay more or less stable for any given load ? If the voltage goes down, the amp should go up...

 

Well, yes and no.

I'm sorry my English is not good enough to quickly write a good explanation   :Embarassed: 

A first rough explanation is the following:

Lets write "watt = volt * amp " like this: P = U * I

This is where I say "yes". I agree with that.

For "If the voltage goes down, the amp should go up" it is better to say it the other way round: "If the amp goes up then the volt goes down".

It is not that it is really wrong. It is only a mater of point of view.  

The formula for the relation between voltage and current is the following: 

U = E - R * I

where E is the battery voltage when it is disconnected and R is the internal resistance of the battery. This is a very simplistic model. because R is not constant. There are several parameters that produce variation on this value. The more important being battery capacity (charge) and battery temperature.

I could try to give a better explanation in the next days if I find some time but it will all boil down to say that what is constant for a given load is more the current than the power. 

So if you want better data for your tests you should try to measure the current. I'v seen that there is the "present voltage" in your /proc/acpi/battery/BAT0/state. Maybe you can try to compute "present rate" / "present voltage". 

It will give you a measurement that should not be influenced by the "present capacity" of the battery. It will still "woobles" but you will have less variations than with the power.

By te way,  here are my batery state and info files:

```
b12@quasar ~ $ cat /proc/acpi/battery/BAT1/state

present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            1314 mA

remaining capacity:      1085 mAh

present voltage:         14849 mV

b12@quasar ~ $ cat /proc/acpi/battery/BAT1/info

present:                 yes

design capacity:         2200 mAh

last full capacity:      1962 mAh

battery technology:      rechargeable

design voltage:          14400 mV

design capacity warning: 0 mAh

design capacity low:     0 mAh

capacity granularity 1:  1 mAh

capacity granularity 2:  1 mAh

model number:            MS-1012

serial number:

battery type:            LION

OEM info:
```

And here is a log of some values at 2 points in time with an almost identical computer load.

If you compute the power (I*V) difference between the first line and the last one and that you compare it to the current (I) difference you wil have an illustration of the poor explanation I have given above about the battery present capacity influence.

(remember that battery capacity is only one of the parameter hat add "noise" to the measure) 

```

2005/11/11 00:04:04  T = 39.0 °C  I = 921 mA  V = 16460 mV  C = 1962 mAh  F = 798000 MHz

2005/11/11 00:04:06  T = 39.0 °C  I = 921 mA  V = 16460 mV  C = 1962 mAh  F = 798000 MHz

2005/11/11 00:04:07  T = 39.0 °C  I = 921 mA  V = 16460 mV  C = 1962 mAh  F = 798000 MHz

2005/11/11 00:04:09  T = 39.0 °C  I = 921 mA  V = 16407 mV  C = 1962 mAh  F = 798000 MHz

2005/11/11 00:04:10  T = 39.0 °C  I = 921 mA  V = 16407 mV  C = 1962 mAh  F = 798000 MHz

...

2005/11/11 01:28:51  T = 38.0 °C  I = 930 mA  V = 14216 mV  C = 148 mAh  F = 798000 MHz

2005/11/11 01:28:53  T = 38.0 °C  I = 930 mA  V = 14216 mV  C = 148 mAh  F = 798000 MHz

2005/11/11 01:28:54  T = 38.0 °C  I = 926 mA  V = 14216 mV  C = 148 mAh  F = 798000 MHz

2005/11/11 01:28:55  T = 38.0 °C  I = 926 mA  V = 14216 mV  C = 148 mAh  F = 798000 MHz

2005/11/11 01:28:57  T = 38.0 °C  I = 926 mA  V = 14216 mV  C = 147 mAh  F = 798000 MHz

```

Last edited by bdz on Sat Nov 12, 2005 1:22 am; edited 1 time in total

----------

## pumpkin0

Thx a lot for these infos, i think i understand the problem now. I will use mA and test a bit this weekend.

----------

## bdz

Hello dear undervolting fellows!

I have made several uptades to the Pentium M Undervolting HowTo on gentoo wiki site:

```
- The sysfs patch is compatible with kernel 2.6.15-gentoo

- Updated the procedure to patch the kernel using the diff file and 

  updated the link to the patch on my web site.

- Removed the procedure to patch the kernel by overwriting 

  the speedstep-centrino.c fle

- Removed the procedures to patch the kernels by manually editing 

  the peedstep-centrino.c file

- Modified the sample voltages tables to make them more readable

  and more easy to edit.

- Modified the sample voltages tables to have one table 

  per Pentium M family

- Restored the contribution of pumpkin0 to the safe voltage table

  that was erroneously removed while reverting "spam robot" 

  vandalism of the gentoo wiki  :? 

- Restored the init script contribution made by Hothead. It was 

  reverted because he accidentally deleted all the rest of the howto while 

  adding his init script. I guess that it was also though that is was robot 

  vandalism :P . 

  I have also made some minor modifications to Hothead's original script.

- Improvements of the page layout (mainly wikified notes and 

  warnings using wiki templates)
```

And I would also like to thank the people who have added their contribution to this howto. 

Namely ailas, AnMaster, BP, dgaffuri, DogMatica, elm, Éric, Hothead, pumpkin0, and rschwarze for the ones that I have identified.

Thank you very much to all of you!

Can you please have a look at the new HowTo version to check that I have not made any mistakes on your voltages while reorganizing the tables?

Note to  dgaffuri:

You have labeled your CPU "Pentium M 750". But from the frequencies where you have put your voltages I guess that it is actually a Pentium M 755 (2.0 GHz core frequency and 400 MHz FSB frequency). Am I correct?

Note to  Éric:

I'm not sure about your CPU model and its max frequency.  :Embarassed:  Please see the note in the HowTo.

One last thing:

If someone wants to volunteer to write a procedure to find min safe voltages using a tool like mprime it would be very great. I would realy like to see this kind of stuff in the howto but I do not have the time to do it myself. Actually I think that I may not be able to add anything else to the howto in the future except for updates to the patch if it happens that it is incompatible with a new kernel release. I'm far too much busy with my work and my personal life at this time   :Embarassed: 

----------

## rschwarze

Very nice work! Thank you!

I'm not sure if that is a problem for anybody but me, but I can't use your kernel patch. My acpi or anything else does not correct report the frequencies of my processor. He always try to use frequencies up to 1.6. So I have to use the old version of the speedstep-centrino.c (with your patch manually added to the end of the file), where I can put the informations about my processor into the file.

I have not tested it, but probably in the original file with your patch applied, there is no place to define a dothan processor, am I right?

But, as I have said, its probably only a problem for me. in the howto DogMatica posted infos about the same processor than mine. maybe he read this and can tell me if he has the same problems or not.

----------

## bdz

You're welcome!

I'm using ACPI tables for my CPU but I don't think there is any incompatibility between my patch and custom tables like you use. There is nothing ACPI specific in my patch.

My first idea is that if you make a diff beween the original speedstep-centrino.c and your custom file (without my patch) you will have 2 patches that could be applied successively to the kernel tree.

Well maybe it will require some adjustments somewhere in one or both patch.

My second idea is to enhance my patch to also have a sysfs interface to change the frequencies, not only the voltages. I've been thinking to this for some time. I never went through this because ACPI is working for me. But it is an intersting thing to study. It may require a little more work than the 2 patches solution but I think that other people will be interested by this. You're not the only one that can't use ACPI tables or default builtin tables of the kernel.

If you want you can send me your speedstep-centrino.c file and we can work together on one of these 2 ideas. 

BDz

Edit:

By the way, what kind of Pentium M is the 710? I did not found it in the the list of processors numbers on Intel web site   :Confused: 

Edit 2:

OK, google gave me the answer: Intel Quietly Adds Another 'Dothan' Chip into Lineup.Last edited by bdz on Fri Jan 13, 2006 7:13 pm; edited 1 time in total

----------

## dgaffuri

Hi, and thanks to you for all your work

 *bdz wrote:*   

> Note to  dgaffuri:
> 
> You have labeled your CPU "Pentium M 750". But from the frequencies where you have put your voltages I guess that it is actually a Pentium M 755 (2.0 GHz core frequency and 400 MHz FSB frequency). Am I correct?

 

No, the 750 have a 533 MHz FSB, I've a 755 (400 MHz).

----------

## bdz

OK, thank you for the confirmation. So now the HowTo is correct about your CPU model.   :Smile: 

Just a wild question to anyone who read this: 

How many of you would be interested by a sysfs interface to change the number of entries in the frequency table and the frequency value of each entry? I mean a full dynamic configuration of all the parameters of the frequency/voltage setpoints array, not only the voltages values as with my current patch version.

BDz

----------

## Phlogiston

A general question about undervolting: It's not a good idea or nearly impossible to use undervolting togethre with a cpu freq scaling governor such as the conservative?

----------

## dgaffuri

 *Phlogiston wrote:*   

> A general question about undervolting: It's not a good idea or nearly impossible to use undervolting togethre with a cpu freq scaling governor such as the conservative?

 

Why? I use it with ondemand without any problem. Undervolting only changes the voltage fed to the CPU for each frequency, not the frequencies themselves.

----------

## Phlogiston

 *dgaffuri wrote:*   

>  *Phlogiston wrote:*   A general question about undervolting: It's not a good idea or nearly impossible to use undervolting togethre with a cpu freq scaling governor such as the conservative? 
> 
> Why? I use it with ondemand without any problem. Undervolting only changes the voltage fed to the CPU for each frequency, not the frequencies themselves.

 

Hmm so a script is changing the voltage everytime the cpu speed is changed? Because we have different voltages for each frequency I think.

----------

## rschwarze

cpufreq already changes the voltages of your pemtium m.

with the standard settings, the voltages for a standard pentium m are between 980 and 1340 mv and cufreq changes them when it changes the frequency.

with our undervolting patch, we are able to see this voltages and to change them to much lower voltages, myvoltages are now between 700 and 970.

if you like to try it out, just go to http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU and follow the instructions. before any voltage is changed, you are able to have a look at the voltages your system is currently using. then you can deside if you want to change them.

Greetz, Roman

----------

## dgaffuri

 *Phlogiston wrote:*   

> Hmm so a script is changing the voltage everytime the cpu speed is changed? Because we have different voltages for each frequency I think.

 

It's not a script.  At each frequency change (coming from a governor or from an explicit user action) the unpatched speedstep_centrino kernel module feeds the processor with voltage/frequency pairs, as required by Intel specification. Roughly, voltage for each frequencies are took from hard-coded tables derived from specs for older CPUs (Banias) and from ACPI calls for newer ones (Dothan). These voltages are in general higher than required, mainly to account for fluctuations in chips quality. The patched speetdstep_centrino allows you to change the voltage values to lower ones writing into a sysfs entry.

Hope I've been clear enough.

----------

## Phlogiston

 *dgaffuri wrote:*   

>  *Phlogiston wrote:*   Hmm so a script is changing the voltage everytime the cpu speed is changed? Because we have different voltages for each frequency I think. 
> 
> It's not a script.  At each frequency change (coming from a governor or from an explicit user action) the unpatched speedstep_centrino kernel module feeds the processor with voltage/frequency pairs, as required by Intel specification. Roughly, voltage for each frequencies are took from hard-coded tables derived from specs for older CPUs (Banias) and from ACPI calls for newer ones (Dothan). These voltages are in general higher than required, mainly to account for fluctuations in chips quality. The patched speetdstep_centrino allows you to change the voltage values to lower ones writing into a sysfs entry.
> 
> Hope I've been clear enough.

 

Yes you cleared it out. But I'm no really motivated to play around with those values. Too hackish I think.

----------

## dgaffuri

 *Phlogiston wrote:*   

> Yes you cleared it out. But I'm no really motivated to play around with those values. Too hackish I think.

 

Little hackish, yes, but my CPU temps are 10 degrees lower, both under Linux and Windows, and the fan is almost always off. And I never got a crash (in both systems) in 8 months. I'm very glad with it, but I'm not trying to convince you, of course it's your choice (and you need a lot of time to test your voltage settings).

----------

## Phlogiston

 *dgaffuri wrote:*   

>  *Phlogiston wrote:*   Yes you cleared it out. But I'm no really motivated to play around with those values. Too hackish I think. 
> 
> Little hackish, yes, but my CPU temps are 10 degrees lower, both under Linux and Windows, and the fan is almost always off. And I never got a crash (in both systems) in 8 months. I'm very glad with it, but I'm not trying to convince you, of course it's your choice (and you need a lot of time to test your voltage settings).

 

Yes that time thing is what I dislike? Does anyone has a T43 with an 

model name      : Intel(R) Pentium(R) M processor 1.86GHz

and is using undervolt?

 :Cool: 

----------

## bdz

 *Phlogiston wrote:*   

> Yes that time thing is what I dislike? Does anyone has a T43 with an 
> 
> model name      : Intel(R) Pentium(R) M processor 1.86GHz
> 
> and is using undervolt?

 

Have a look here for someone that apparently has undervolted his Thinkpad T43 with 1.86 GH Pentium M: http://thinkwiki.org/wiki/Pentium_M_undervolting_and_underclocking

But even if you have reference voltages that somebody else is using on the same laport and CPU model you will have to spend a quite long time testing to be sure that the voltages are safe on your laptop.

----------

## rschwarze

if you test each voltage/frequency pair for at least one two hours or so with gimps, you are on the safe side. should not be to difficult to write a script that does that over night. so it will not cost you too much time.

and some settings are pretty easy: i have never seen someone who couldn't use 700mv at the lowest frequency, so you can at least try that out. that gives you lots of power saving in idle mode  :Wink: 

From my point of view, it is totally worth the effort. my notebook was really hot and loud before and now its cool and quiet. And that's very imprtant for me, cause i don't like the noise of a fan when i just surf the internet.

So long,

Roman

----------

## Phlogiston

Ok guys. I felt boring and started undervolting   :Cool:   First I used the values from the wiki: 

```
 Pentium-M Dothan     1.86     1068,972,876,780,700
```

But then my T43 just crashed very strangly... [at 800MHZ] So I increased the value by 50mV and tested again and it seems to be quite stable. I also increased all the other values by 50mV and tested wiht gimps. No problems so far. And wow: Together with the fan control script my machine is now really quite! Thats awesome!

Thanks to everyone involved in that stuff and/or motivating me to try that out.

Phlogiston

PS: These are the values I'm using now:

```

CUSTOM_VTABLE="1118,1022,926,830,750"

```

----------

## bdz

Great!

It's always good to hear a new succes story with the patch.  :Smile: 

One smal remark about your voltages. If you look at the actual values that are used you wil see that they are not exactly what you have set

You should see something like this:

```
# cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1116,1020,924,828,748

```

This is because the voltages can only be adjusted by steps of 16 mv, starting at 700 mv.

By the way, I have added your voltages in the HowTo on the wiki: http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU#Safe_voltages

Can you please check that I have not made any mistake on your CPU information?

Feel free to modify your voltages on the wiki page if one day you decide to change the values you are using on your laptop.

bdz

----------

## Phlogiston

 *bdz wrote:*   

> Great!
> 
> It's always good to hear a new succes story with the patch. 
> 
> 

 

So does this mean you wrote that patch?   :Cool: 

 *Quote:*   

> 
> 
> One smal remark about your voltages. If you look at the actual values that are used you wil see that they are not exactly what you have set
> 
> You should see something like this:
> ...

 

Yes that true, that's also what the scripts says.

Here are all the values:

```

 * Current table:     1116,1020,924,828,748

 * Configured table:  1118,1022,926,830,750

 * Applied table:     1116,1020,924,828,748 

```

 *Quote:*   

> 
> 
> This is because the voltages can only be adjusted by steps of 16 mv, starting at 700 mv.
> 
> 

 

Thanks for claryfiying, I thouht something like that but didn't know exaclty.

 *Quote:*   

> 
> 
> By the way, I have added your voltages in the HowTo on the wiki: http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU#Safe_voltages
> 
> Can you please check that I have not made any mistake on your CPU information?
> ...

 

Ok great... Yes I just increased the values so these are not the lowest ones... Probably I'll try to decrease the one for 800MHZ a bit more. Because thats where I need to save the most power when I am on the way.

----------

## rschwarze

Like I said! everybody loves undervolting  :Wink: 

you said something about a script which controls your fan. how are you doing that? it's probably only working with supportet fans?

thx for an answer  :Smile: 

cu, roman

----------

## bdz

Phlogiston:

Yes that's me that started writing this patch and the howto. But some parts are strongly inspired by some previous work of some other guys.

And now Roman (rschwarze) has joined me to work on the next version of the patch.

Also several people have added their contribution to the howto.

(If anybody else wants to join the team you're welcome. Just let us know)

----------

## Phlogiston

 *rschwarze wrote:*   

> Like I said! everybody loves undervolting 
> 
> you said something about a script which controls your fan. how are you doing that? it's probably only working with supportet fans?
> 
> thx for an answer 
> ...

 

Yes but I think it only works on Thinkpad Laptops, do you have such a beauty?

Link: http://www.thinkwiki.org/wiki/ACPI_fan_control_script

----------

## Phlogiston

 *bdz wrote:*   

> Phlogiston:
> 
> Yes that's me that started writing this patch and the howto. But some parts are strongly inspired by some previous work of some other guys.
> 
> And now Roman (rschwarze) has joined me to work on the next version of the patch.
> ...

 

Ohh, ok... So a big THANK to you! And of course everyone else involved in it. Hey I just reduced the voltages by 30mV and lowest is now at 716. And thats ok, no problems so far...

----------

## bdz

 *Phlogiston wrote:*   

> 
> 
> Ohh, ok... So a big THANK to you! And of course everyone else involved in it. Hey I just reduced the voltages by 30mV and lowest is now at 716. And thats ok, no problems so far...

 

You're welcome   :Very Happy: 

If your laptop crashed at 700 mv you should let gimps running in torture test mode for one hour or more at 716 mv to be sure you don't have any problem with this voltage.

And you can increase to 732 mv even if gimps does not detect any problem if you want to be safe. It should not make a big difference in power consumption.

Edit:

When using gimps/mprime to check voltage stability be carefull to use the userspace cpufreq governor to set the CPU frequency to the one you want to test.

----------

## soulwarrior

I am too running this patch successfully   :Very Happy: 

It's a Intel Pentium M 740 with the following values for the voltage table:

"956,956,956,956,956,956,956,828,732,700"

Greetings,

soulwarrior

----------

## bdz

Thank you very much for your voltages soulwarrior. I have added them to the howto.

----------

## Phlogiston

 *bdz wrote:*   

> 
> 
> Edit:
> 
> When using gimps/mprime to check voltage stability be carefull to use the userspace cpufreq governor to set the CPU frequency to the one you want to test.

 

I know I know... and if you are using conservative... the frequence won't be increased because it runs at nice value   :Wink:  Thats why I reniced it to -18 or so to test it really hard   :Cool: 

----------

## bdz

Yes I forgot about nice.

But if you want to test indermediate frequencies you will need to use userspace grovernor   :Wink: 

----------

## Phlogiston

 *bdz wrote:*   

> Yes I forgot about nice.
> 
> But if you want to test indermediate frequencies you will need to use userspace grovernor  

 

Of course! I know, I know   :Cool: 

Have a good night   :Wink: 

Bonne nuit   :Smile: 

----------

## mbar

this is fcvking awesome!

My P-M 1,5 GHz undervolted from 1484 mV to 1212 mV (at 1500 MHz) and its temperature dropped from 85-88 C to 63-68 C   :Shocked:   I no longer hear full speed fan noise  :Smile: 

----------

## zhark

 *soulwarrior wrote:*   

> I am too running this patch successfully  
> 
> It's a Intel Pentium M 740 with the following values for the voltage table:
> 
> "956,956,956,956,956,956,956,828,732,700"
> ...

 

I've also got the Pentium M 740 (1.73GHz):

Cpu Family: 6, Model: 13, Stepping 8, cpu MHz: 1729.341

I've enabled intel enhanced speedstep and cpu freq debugging in kernel, and i get this error message:

speedstep-centrino: Invalid control/status registers (1 - 1)

speedstep-centrino: <6>speedstep-centrino: invalid ACPI data

speedstep-centrino: <6>speedstep-centrino: found unsupported CPU with

Enhanced SpeedStep: send /proc/cpuinfo to Jeremy Fitzhardinge <jeremy@goop.org>

cpufreq-core: initialization failed

cpufreq-core: no CPU initialized for driver centrino

cpufreq-core: unregistering CPU 0

PS: This happens regardless of me applying the undervolt patch (in the howto) to speedstep-centrino.c

EDIT: Got it working!! Manually edited the original speedstep-centrino.c - Mine also does 533MHz!

See it here: http://zhark.bjorli.com/speedstep-centrino.c-zharkbb (This file is based on the 2.6.16-rc4 vanilla kernel)

(This file is modified to support Pentium M 740 1.73GHz, but can easily be altered to support others)

EDIT: Updated voltages after verification with mprime

Here are my voltages:

533MHz:700 800MHz:748 1733MHz: 956

-zhark

----------

## EASYdoor

damn,...i can't get this speedstep centrino code working, nomatter which options i try to inlcude/exclude to the kernel i always get acpi drivers loaded into the kernel, so i cannot manually control my centrino,...anyone else found a solution for this problem?

```

cpufreq-info

cpufrequtils 0.4: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  no or unknown cpufreq driver is active on this CP

```

trying to load as a module,...

```

FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.16-rc3-nitro1/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device

```

And nomather wich kernel i run, same problem...

And I'm running Intel Pentium M 750 (2 Ghz), Acer TravelMate 8006

```

processor   : 0

vendor_id   : GenuineIntel

cpu family   : 6

model      : 13

model name   : Intel(R) Pentium(R) M processor 2.00GHz

stepping   : 6

cpu MHz      : 598.289

cache size   : 2048 KB

fdiv_bug   : no

hlt_bug      : no

f00f_bug   : no

coma_bug   : no

fpu      : yes

fpu_exception   : yes

cpuid level   : 2

wp      : yes

flags      : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2

bogomips   : 1196.65

```

dmesg:

```
* cpufreqd requires the kernel to be configured with CONFIG_CPU_FREQ
```

----------

## bdz

As far as I know the centrino cpu-freq driver does not work correctly when compiled as a module. It has to be built into the kernel.

Here is how I have the CPU frequency scaling part of my kernel configured:

```

Linux Kernel v2.6.15-gentoo-r6 Configuration

 ──────────────────────────────────────────────────────────────────────────────

  ┌───────────────────────── CPU Frequency scaling ─────────────────────────┐

  │  Arrow keys navigate the menu.  <Enter> selects submenus --->.          │

  │  Highlighted letters are hotkeys.  Pressing <Y> includes, <N> excludes, │

  │  <M> modularizes features.  Press <Esc><Esc> to exit, <?> for Help, </> │

  │  for Search.  Legend: [*] built-in  [ ] excluded  <M> module  < >       │

  │ ┌─────────────────────────────────────────────────────────────────────┐ │

  │ │[*] CPU Frequency scaling                                            │ │

  │ │[*]   Enable CPUfreq debugging                                       │ │

  │ │<*>   CPU frequency translation statistics                           │ │

  │ │[*]     CPU frequency translation statistics details                 │ │

  │ │      Default CPUFreq governor (performance)  --->                   │ │

  │ │---   'performance' governor                                         │ │

  │ │<*>   'powersave' governor                                           │ │

  │ │<*>   'userspace' governor for userspace frequency scaling           │ │

  │ │<*>   'ondemand' cpufreq policy governor                             │ │

  │ │<*>   'conservative' cpufreq governor                                │ │

  │ │---   CPUFreq processor drivers                                      │ │

  │ │< >   ACPI Processor P-States driver                                 │ │

  │ │< >   AMD Mobile K6-2/K6-3 PowerNow!                                 │ │

  │ │< >   AMD Mobile Athlon/Duron PowerNow!                              │ │

  │ │< >   AMD Opteron/Athlon64 PowerNow!                                 │ │

  │ │< >   Cyrix MediaGX/NatSemi Geode Suspend Modulation                 │ │

  │ │<*>   Intel Enhanced SpeedStep                                       │ │

  │ │[*]     Use ACPI tables to decode valid frequency/voltage pairs      │ │

  │ │[*]     Built-in tables for Banias CPUs                              │ │

  │ │< >   Intel Speedstep on ICH-M chipsets (ioport interface)           │ │

  │ │< >   Intel SpeedStep on 440BX/ZX/MX chipsets (SMI interface)        │ │

  │ │< >   Intel Pentium 4 clock modulation                               │ │

  │ │< >   nVidia nForce2 FSB changing                                    │ │

  │ │< >   Transmeta LongRun                                              │ │

  │ │< >   VIA Cyrix III Longhaul                                         │ │

  │ │---   shared options                                                 │ │

  │ │[ ]   /proc/acpi/processor/../performance interface (deprecated) (NEW│ │

  │ └─────────────────────────────────────────────────────────────────────┘ │

  ├─────────────────────────────────────────────────────────────────────────┤

  │                    <Select>    < Exit >    < Help >                     │

  └─────────────────────────────────────────────────────────────────────────┘

```

----------

## EASYdoor

finnaly got it working...extra 40 min of battery life with:

```

scaling_voltages

600000 700

rovclock -c 60 -m 60

cool'n quiet ;) sweet  

```

if anyone needs a modiyfied speedstep-centrino.c for Dothan 2.0 let me know

----------

## Elmo234

I just started coding a program that is used as a daemon and undervolts the athlon64 and centrino (Pentium-M and Celeron-M) cpu's.

I write the new vid's using /dev/cpu/*/msr

You can have a look at it here:

http://tuxamito.com.es/cpupw/

by the way... does anybody know how could I find if a Pentium-M (centrino) is using a 100 (400) or a 133 (533) Mhz bus?

Thanks

----------

## Muffe

Is there any way I can set the voltage below 700 mV? I have an Pentium-M 740 1,73 GHz, and have applied the patch as described in the WIKI, and is now able to set the voltage at 800 MHz down to 700 mV. Because I want to tune it as far down as possible, I tried to set it to 695 mV, but I was not able to do that.

Why does this lower limit exist? Is it any way I can bypass it or remove it? Thanks.

----------

## mbar

It's an MSR register limitation. You cannot do anything about it.

----------

## Keruskerfuerst

 *Muffe wrote:*   

> Is there any way I can set the voltage below 700 mV? I have an Pentium-M 740 1,73 GHz, and have applied the patch as described in the WIKI, and is now able to set the voltage at 800 MHz down to 700 mV. Because I want to tune it as far down as possible, I tried to set it to 695 mV, but I was not able to do that.
> 
> Why does this lower limit exist? Is it any way I can bypass it or remove it? Thanks.

 

There is also a technical limitation.

Depends on the endowment.

This results in a level, where the transistors do switch from "low" to "high" and vice versa.

----------

## rschwarze

Hey guys!

We have done a new version of the undervolting patch. We now call it "Linux PHC" and it is hosted on sourceforge.

The Project Website is: http://linux-phc.sourceforge.net

If you like, please try out the new version and report any problems or other feedback into this thread.

Thank you very much,

Roman

----------

## jwj

Hi rschwarze,

Thanks for your phc patch. I applied it to linux-2.6.16-ck2:

```

bash # echo "1862000:1036,1862000:1036,1862000:1036,1862000:1036,1862000:1036,1862000:1036,1596000:956,1330000:876,1064000:780,798000:700" > /sys/devices/system/cpu/cpu0/cpufreq/op_points_table

```

```

bash # cat /sys/devices/system/cpu/cpu0/cpufreq/op_points_table

1862000:1036,1862000:1356,1862000:1356,1862000:1356,1862000:1356,1862000:1356,1596000:956,1330000:876,1064000:780,798000:700

```

Only the first 1862000 entry seems to be changed, dont know, if this is a problem, but it seems my fan is running more than with the bdz patch.

----------

## rschwarze

you may also want to check the values in /sys/devices/system/cpu/cpu0/cpufreq/voltage_table, because that interface is still available.

Can you tell me if the entrys in the voltage_table look different then with the old patch?

Thank you for testing!

----------

## jwj

with the phc patch:

```

bash # cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1036,1356,1356,1356,1356,1356,956,876,780,700

bash # echo "1036,1036,1036,1036,1036,1036,956,876,780,700" > /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

bash # cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1036,1036,1036,1036,1036,1036,956,876,780,700

bash # cat /sys/devices/system/cpu/cpu0/cpufreq/op_points_table

1862000:1036,1862000:1036,1862000:1036,1862000:1036,1862000:1036,1862000:1036,1596000:956,1330000:876,1064000:780,798000:700

```

So it seems, that after setting the values in voltage_table they also show up correct in op_points_table.

Output of bdz patched 2.6.15 kernel:

```

bash # echo "1036,1036,1036,1036,1036,1036,940,876,780,700" > /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

bash # cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table

1036,1036,1036,1036,1036,1036,940,876,780,700

```

Hope this helps.

----------

## rschwarze

Yes, thats what i thought...

I don't have this problem with my notebook, because i don't have multiple op-points:

```
bash $ cat /sys/devices/system/cpu/cpu0/cpufreq/op_points_table

600000:700,800000:716,1000000:780,1200000:860,1400000:956

```

```
bash $ cat /sys/devices/system/cpu/cpu0/cpufreq/voltage_table  

700,716,780,860,956

```

bdz will have a look at it, as soon as he has time. I hope we can solve this soon.

Thanks again for your feedback!

----------

## bdz

 *jwj wrote:*   

> Hi rschwarze,
> 
> Thanks for your phc patch. I applied it to linux-2.6.16-ck2:
> 
> ```
> ...

 

Hi jwj!

I have reproduced your problem on my laptop where I also have these duplicated operating points when using ACPI table. I did not noticed the problem before because I'm usualy using built-in table.

I have made the correction in the patch and tested it on my laptop. Unfortunalty Sourceforge is currently down so I can't upload the new release right now. I will keep you informed as soon as I'm able do do it.

Edit:

Sourceforge is back up. I have uploaded the new release (0.2.2) : 

https://sourceforge.net/project/showfiles.php?group_id=161063

----------

## jwj

Thank you very much bdz, the 0.2.2 release fixes the problem here.

-jwj

----------

## Egalus

Hi,

first of all thank you for your great work. I lack the c-knowledge to contribute in any other matter than testing and making comments.

At the moment I am using the old version of the patch (not the linux-phc one) with kernel 2.6.15 with a pinmodded 1.7GHz P-M which now is running at 2.26GHz max-speed.

With this old patch every tool reports the cpu to be running at the desired 533 FSB.

As the 2.6.16 kernel is out and the changelog claims that some work regarding powerrsaving is done (and 2.6.15 while idling still consumes about 10% more juce than winxp) I want to change over to this new kernel.

I use a vanilla 2.6.16.1 kernel and the 0.2.2 linux-phc patch for 2.6.16 with the default settings suggested in the Patching.txt file.

So far so good, I get the needed devices in /sys/ , but somehow all programms that show cpu-speed now show a 600-1700 Mhz P-M on a 400 MHz FSB.

This leads to some questions:

a) is the cpu now running at 400 or 533 fsb (as the mod is a hardware mod I would be surprised if it's running at 400)

b) how do I find out at which speed the cpu really is running

c) if this is just a coincidence of the builtin tables for dothan for detecting the correct voltages and by that translating the 1.7 P-M (which is pinmodded to be a 2.26 P-M) back to a normal 1.7 P-M is going to be changed in future releases?

And one comment on the naming of the tables.

Banias and Dothan really are processors,

but Sonoma actually is a chipset and you surely mean 533 FSB Dothans with the name.

There is already so much confusion about celeron, banias, dothans, I guess naming this table "sonoma" might add to confusion.

Regards,

Norbert

----------

## brihall

I have a laptop with a Pentium-III mobile CPU (_not_ centrino!). Speedstep (normal, not enhanced) is enabled and working fine, giving me two frequencies, 800 and 1200 Mhz. Anyone have a patch or tips on how to undervolt a P3-M CPU with speedstep?

00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)

00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 04)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 03)

00:1f.0 ISA bridge: Intel Corporation 82801BAM ISA Bridge (LPC) (rev 03)

00:1f.1 IDE interface: Intel Corporation 82801BAM IDE U100 (rev 03)

00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 03)

processor	: 0

vendor_id	: GenuineIntel

cpu family	: 6

model		: 11

model name	: Intel(R) Pentium(R) III Mobile CPU      1200MHz

stepping	: 1

cpu MHz		: 798.000

cache size	: 512 KB

fdiv_bug	: no

hlt_bug		: no

f00f_bug	: no

coma_bug	: no

fpu		: yes

fpu_exception	: yes

cpuid level	: 2

wp		: yes

flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse

bogomips	: 1596.39

----------

## rschwarze

@egalus:

recently, someone wrote me that he used the patch for an overclocked dothan in the following way. its just a workaround, but maybe you wanna try it:

I have a Dothan 735 (1.7Ghz with 100Mhz bus) overclocked to

2.2Ghz by changing the fsb to 133Mhz. A pristine 2.6.16 kernel

will correctly display "2267000" as the first frequency in

/sys/.../cpufreq/scaling_available_frequencies but after

applying the PHC patch it displays 170000 (the cpu still

runs at 2.2Ghz).

I had a look at speedstep-centrino.c and if I removed these

lines (line 570 - 575):

       if ((centrino_model[cpu]) && (centrino_model[cpu]->base_freq != 0))

       {

               msr = (msr >>  :Cool:  & 0xff;

               return msr * centrino_model[cpu]->base_freq;

       }

/sys/.../cpufreq/scaling_available_frequencies will again show

"2267000" as the first frequency.

----------

## Gremo

hi,

i'm a new gentoo user, i would learn how to modify my speedstep-centrino.c.

i'm currently using centrino driver:

```

# cpufreq-info

cpufrequtils 0.4: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 800 MHz - 1.60 GHz

  available frequency steps: 1.60 GHz, 1.33 GHz, 1.07 GHz, 800 MHz

  available cpufreq governors: conservative, ondemand, powersave, performance

  current policy: frequency should be within 800 MHz and 1.60 GHz.

                  The governor "ondemand" may decide which speed to use

                  within this range.

  current CPU frequency is 800 MHz (asserted by call to hardware).

```

How to get minimum frequency of 533mhz?it is possible to go under?

which speedstep-centrino.c i have to modify? /usr/src/linux-2.6.16-gentoo-r1/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c ?

To apply settings, i have to recompile and reboot?

----------

## rschwarze

1. Dowload the linux-phc patch from http://linux-phc.sourceforge.net/

2. Apply the patch according to the documentation provided with the patch

3. use "make menuconfig" to configure your kernel and configure the patch to use "build in tables" for your processor

4. Make any changes to the speedstep-centrino.c file in the kernel directory that you like (to use undervolting, you dont have to change anything)

5. save your .config

6. "make clean"

7. restore yout .config

8. "make && make modules_install"

9. copy the kernel to /boot and change your grub or lilo settings accordingly

----------

## Gremo

 *rschwarze wrote:*   

> 1. Dowload the linux-phc patch from http://linux-phc.sourceforge.net/
> 
> 4. Make any changes to the speedstep-centrino.c file in the kernel directory that you like (to use undervolting, you dont have to change anything)
> 
> 

 

well, i really don't know which section i have to modify in order to get 533mhz and to get lower vids...

thanks alot!

----------

## Gremo

got it!   :Very Happy: 

```

static struct cpufreq_frequency_table sonoma_1596[] =

{

   OPEX( 533, 133,  700,  700,  700,  700),  /* 533mhz  */

   OPEX( 798, 133,  988,  988,  988,  988),

   OPEX(1064, 133, 1116, 1111, 1084, 1079),

   OPEX(1330, 133, 1244, 1233, 1180, 1169),

   OPEX(1596, 133, 1356, 1356, 1260, 1260),

   { .frequency = CPUFREQ_TABLE_END }

};

```

however i can't go under 0.7v as voltage...may be i have to modify something else?

----------

## rschwarze

no, its not possible to run below 700mv. its a hardware limitation.

however, are you sure its running at 533? you can write whatever you want into the speedstep-centino.c and cpufreq will show it as a possible frequency. to be sure, you should use some benchmark to see that its really running slower at that frequency. for example you can just use the benchmark of mprime.

good to now that everything else works just fine for you!

----------

## Gremo

 *rschwarze wrote:*   

> no, its not possible to run below 700mv. its a hardware limitation.
> 
> however, are you sure its running at 533? you can write whatever you want into the speedstep-centino.c and cpufreq will show it as a possible frequency. to be sure, you should use some benchmark to see that its really running slower at that frequency. for example you can just use the benchmark of mprime.
> 
> good to now that everything else works just fine for you!

 

not sure at all...running kpowersave or cpuinfo (i suppose they use cpufrequtils or something in /proc) give me that value...

what should i do running mprime?

In your opition i can run more cool at 533mhz@0.7 vs 800@0.7?or it is just the same because of the same voltage?

----------

## rschwarze

the frequency has some small effect on the power consumption and the heat but not as much as the voltage. heat and powerconsumption are in a quadratic correlation with the voltage. but for some people, 700mv dont work at 800, but it works at 533.

to benchmark with mprime: just run mprime (emerge gimps first, if you havent done so already) and choose "benchmark". then do this once with 533 and once with 800. (you can choose the frequency with cpufreq-set).

mprime from gimps is very useful anyway, because you should use the cpu stresstest to find out the safe voltage/frequency pairs for your cpu.

----------

## Gremo

 *rschwarze wrote:*   

> the frequency has some small effect on the power consumption and the heat but not as much as the voltage. heat and powerconsumption are in a quadratic correlation with the voltage. but for some people, 700mv dont work at 800, but it works at 533.
> 
> to benchmark with mprime: just run mprime (emerge gimps first, if you havent done so already) and choose "benchmark". then do this once with 533 and once with 800. (you can choose the frequency with cpufreq-set).
> 
> mprime from gimps is very useful anyway, because you should use the cpu stresstest to find out the safe voltage/frequency pairs for your cpu.

 

ok thanks for helping!

i was testing on windows (prime 95  :Wink:  ) for about 4 hourse 800mhz@0.7 and all went fine, i'm happy to know i haven't to boot on windows  :Smile: 

----------

## rschwarze

@ all the people with an overclocked pentium-m:

linux-phc reads the frontsidebus from the acpi, and the acpi gives the original, not overclocked, fsb. Therefore, your frequencies are reported incorrectly. Nonetheless, the undervolting should work fine, because it is done via the multiplicator only.

That means: The frequencies are reported wrong, but the multiplicator and the voltages are correct. So you can use the patch to change the voltages for your cpu.

At the moment, we don't have a good solution for reading the correct FSB. We are working on it, but because we don't have an overclocked pentium-m we need your help.

It would be great, if everyone who has an overclocked pentium-m could send us some debug informations:

1. enable the CPUfreq debugging info in your kernel config

2. add the kernel boot parameter "cpufreq.debug=3" to you grub/lilo

Then send us the following informations (fabrice-bellamy at users.sourceforge.net, rschwarze at users.sourceforge.net ):

- the output of the dmesg command

- the file /var/log/dmesg

- the content of /proc/cpuinfo

thank you very much,

roman

----------

## Egalus

Sorry that I didn't answer in the last days (alsmost 2 weeks).

My laptops harddrive suffered from defective sectors - only a few, but those were "nicely" spread over my linux partitions and because of easter and a really really "fast brainer" at dell support it took them almost two weeks to get a replacement hdd to me.

But as a "bonus" the "fast brainer" fully broke her word , cause instead of having some days time to check out the new hdd and copy over everything I can rescue from the old to the new hdd she issued a so called R3 return with UPS, which means that UPS came the first of three times to retrieve the old hdd 4 hours after they delivered the replacement, so I had 2 days and some hours max for everything - thx dell.

As I need to reinstall linux again and reconfigure everything and after that catch up with other work that I don't do at the moment I won't post the desired files for my undervolted, pinmodded p-m for at least another week.

----------

## rschwarze

thanks to some others here on the forum, we already got some debug info.

so, if you like, you can wait until we release the new version of the patch with some improvements of the patch.

in the new version we have a better detection of the FSB reported from the ACPI, but that only helps if your acpi reports the correct values. if your acpi reports the old values, we have no way to detect that.

So, in the new version of the patch we include a "measurefreq" utility, so that one can test at which frequency the cpu is actually running and, to get the correct values from cpufreq-info, we include an interface to manualy change the reportet FSB. With that, one is able to change the FSB to 133 and so all the reportet frequencies should be correct after that.

If bdz agrees with me, we will put the new version on this forum very soon.

thanks for all your effort in helping with the testing,

roman

edit:

here is todays snapshot of the upcoming version of linux-phc: http://www.math.uni-bielefeld.de/~schwarze/linux-phc-0.2.3.alpha-04-19-2006-kernel-2.6.16.tar.gz

THIS COMES WITH ABSOLUTELY NO WARANTY!

This new version is only useful for those of you, which have a problem with a wrongly detected FSB.

for some of you, this patch will already solve the problem with a wrong detected FSB.

For the others, there is the new interface /sys/devices/system/cpu/cpu0/cpufreq/FSB_base_frequency

you can get info about the current detected FSB with 

```
cat /sys/devices/system/cpu/cpu0/cpufreq/FSB_base_frequency
```

and you can change it to 133mhz with the command:

```
echo 133000 > /sys/devices/system/cpu/cpu0/cpufreq/FSB_base_frequency
```

Remember: this will not actually change the FSB! The FSB is hardcoded on the cpu. With this interface you can just adjust the detected FSB to the correct value, to get proper information about the current frequency.

As always, we appreciate your comments about this  :Smile: 

----------

## Egalus

 *rschwarze wrote:*   

> 
> 
> For the others, there is the new interface /sys/devices/system/cpu/cpu0/cpufreq/FSB_base_frequency
> 
> you can get info about the current detected FSB with 
> ...

 

I am back in business faster than expected  :Wink: 

During the reinstall I chose to use kernel 2.6.16 and tried phc 0.2.2 and 0.2.3alpha from the post above mine.

With the 0.2.2 my pinmodded p-m was (as expected) reported as running with 600-1700 mhz.

After that I unpatched 0.2.2 and patched with the 0.2.3alpha, recompiled the kernel and tada, without doing anything else the cpu is now reported as 800-2260 and the new FSB.... interface also states to run at 133 mhz.

Conclusions:

a) 0.2.3alpha solves the "wrong fsb detected for pinmodded p-m for me"

b) a big thx to the developers, this patch is the last thing needed to totally change from win to linux on my laptop  :Wink: 

Just for reference, I am using a Dell Inspiron 6000 laptop.

Btw, is there any plan to get this patch into the vanilla kernel tree?

----------

## rschwarze

Thats great! thank you very much for testing it!

now i think we can release 0.2.3 very soon  :Smile: 

about the vanilla kernel: thats not my decision and im really not sure the kernel guys like undervolting... on the plus side for us: some people with a crappy acpi really need our included frequency/voltage pairs. so, our patch also improves compatibility  :Smile: 

in the meanwhile, people just have to use the patch or ask their preferred kernel sources to include linux-phc  :Wink: 

edit: We plan to release the version 0.2.3 on sunday. So, if someone here likes to beta-test it, here it is:

http://www.math.uni-bielefeld.de/~schwarze/linux-phc-0.2.3-kernel-2.6.15.tar.gz

http://www.math.uni-bielefeld.de/~schwarze/linux-phc-0.2.3-kernel-2.6.16.tar.gz

If you find any problems or just typos or if everything works just fine for you, we would really appreciate your comments!

Btw: Now, the utility "measurefreq" is included in the release. With that you can measure the real frequency your CPU is running at at the moment.

----------

## Entropy42

FYI, with a few caveats, linux-pch also works on Yonah (Core Duo) chips.

Most of the caveats are root problems with cpufreq itself - it does NOT handle Core Duo chips well at all.  It detects that the two cores are on the same chip (see the affected_cpus value) but still presents independent controls for each CPU.  This is WRONG!  All frequency/voltage settings are locked for the entire chip (both cores), so having independent settings in cpufreq is nonsensical and often provides inconsistent results.  (Such as /proc/cpuinfo reporting differing values for each core even though that is physically impossible.)  linux-pch seems to be affected by this, and it's a crapshoot as to which voltage table will actually be read when a clock frequency change is made, so when adjusting oppoints, BOTH cores must be updated or unpredictable results may occur.  Note that this is a root problem with the cpufreq architecture - everything about cpufreq is broken in this manner.  I realized that I have been running my CPU at full speed under Linux ever since I got my Dell E1705 despite THINKING that I had put it in powersave mode, it turns out you have to put both cores in powersave mode for anything to happen.

I have also noticed that the voltage table is only read when a speed transition occurs.

Either way, I have dropped from 1.404 to 1.244 volts at 2.0 GHz (which saves half an ampere off of the battery, from 4.5A to 4.0A at full load) and 1.004 to .748 volts at minumum speed (1.0 GHz) and may likely be able to drop even more.  The voltage change at minimum speed had negligible effects on current draw though, so there is a chance that my minimum voltage settings have not actually taken hold.

----------

## Entropy42

 *Gremo wrote:*   

>  *rschwarze wrote:*   no, its not possible to run below 700mv. its a hardware limitation.
> 
> however, are you sure its running at 533? you can write whatever you want into the speedstep-centino.c and cpufreq will show it as a possible frequency. to be sure, you should use some benchmark to see that its really running slower at that frequency. for example you can just use the benchmark of mprime.
> 
> good to now that everything else works just fine for you! 
> ...

 

In theory, the difference will be on the order of 533/800, or around 62.5% of the dynamic power.

CPU power usage is typically a minimum static power which depends only on voltage, and then on dynamic power which is a linear function of frequency and a function of the square of the voltage.

That said, while moving from 800 to 533 (if possible) will use 62.5% of the dynamic power of 800@0.7 volts, that difference is likely negligible compared to the total system power consumption.  A few numbers from the battery monitoring script in the gentoo-wiki undervolting HOWTO from a Core Duo T2500 (2.0 GHz max)

Idle, 2.0 GHz, stock voltage (1.404 volts):  3.0-3.1 amperes (I don't remember exactly)

Idle, 1.0 GHz (minimum), stock voltage (1.004v):  2.7 amperes

Both cores loaded, 1.0 GHz, stock voltage:  3.15-3.2 amperes

Both cores loaded, 1.0 GHz, .748 volts:  Same as stock voltage.  Possibly the voltage change at minimum clock may not be working (see previous post)

Both cores loaded, 2.0 GHz, stock voltage:  4.5 amperes

Both cores loaded, 2.0 GHz, 1.244 volts:  4.05-4.1 amperes

These are all with the display at minimum brightness in a Dell Inspiron E1705.  Full brightness adds a half ampere to battery current draw.

I'm not posting temperatures as I do not trust temperature monitoring on my machine.  I frequently get readings of 17-20 Celsius when the temperature in my apartment is 20-22 Celsius.

----------

## rschwarze

Hi Entropy!

Thank you very much for your experience.

So, have you actually changed something in speedstep-centrino.c or is it just about the right usage together with the 2 cores?

would you expect any problems with a core solo?

and what about the FSB? is it correctly recognized by speedstep?

thank you,

roman

----------

## Egalus

 *Entropy42 wrote:*   

> FYI, with a few caveats, linux-pch also works on Yonah (Core Duo) chips.
> 
> Most of the caveats are root problems with cpufreq itself - it does NOT handle Core Duo chips well at all.  It detects that the two cores are on the same chip (see the affected_cpus value) but still presents independent controls for each CPU.  This is WRONG!  All frequency/voltage settings are locked for the entire chip (both cores), 

 

I am only 99% confident, but those 99% say that you are partly wrong here too.

AFAIK on core duo it's like:

- freq can be set for both cpus seperately

- voltage is fixed to the voltage of the core with the highet freq at the time

- powersavingstates can't be reached alone, both cores need to go to sleep at the same time.

----------

## rschwarze

maybe with some debug info from cpufreq we can get some insights about this?

----------

## Entropy42

 *rschwarze wrote:*   

> Hi Entropy!
> 
> Thank you very much for your experience.
> 
> So, have you actually changed something in speedstep-centrino.c or is it just about the right usage together with the 2 cores?
> ...

 

I haven't touched speedstep-centrino.c at all, although I have discovered that (I believe) the VID->voltage mapping is different for the Core Duo, at least from the looks of how RightMark RMClock works under Windows.  The oppoints table reports a default voltage of 1.004 volts at the minimum frequency and 1.404 volts at the maximum frequency.  RightMark reports .950 volts and 1.2?? (I don't remember exactly) respectively.  This corresponds to a base voltage of 712.5 mV and an increment of 12.5 mV instead of 700mV/16 mV as on previous CPUs.  Also, from what I've seen in the RightMark forums, any voltages below the default minimum starting voltage (e.g. 950 mV in the case of my machine) are locked out - attempting to set a voltage below the default at minimum speed will result in the default voltage being set.  This would explain why I saw no power consumption differences whatsoever when dropping the voltage at minimum frequency.  It's still possible to cool down the laptop quite a bit at maximum speed by dropping the voltage.

I'll post more details in a day or two, and attempt patching speedstep-centrino.c to be Core Duo-aware.

All of the above should apply to the Solo also.

I am positive that the cores cannot operate at differing frequencies, as power consumption at peak load does not change a single bit when one CPU is in powersave mode and the other is still in performance mode.  In addition, in such a situation, one process run on each CPU (for example, two instances of mprime) will run at the same speed.  I've also seen others indicate that the entire chip is indeed locked to run at the same frequency.  Given that L2 cache is almost always core speed cache, it would be EXTREMELY difficult to have the Core Duo's unified L2 cache unless the entire chip were always running at the same clock speed.

----------

## albright

How come the undervolting service needs logger? Is there 

a way to undervolt *without* running a system logger?

(I have my reasons  :Wink:  )

----------

## bdz

 *albright wrote:*   

> How come the undervolting service needs logger? Is there 
> 
> a way to undervolt *without* running a system logger?
> 
> (I have my reasons  )

 

I guess that by "the undevolting service" you refer to the undervolting init script in /etc/init.d, right? (It's not an actual service only a script that is executed at boot and shutdown time)

It needs the logger service because of the following line that sends an error message to the system log when the sysfs interface does not exists:

```
   logger "SysFs voltage_table not found. Can't modify CPU voltage table. (${VTABLE_PATH})"
```

If you have your reasons to not use any system logger you can comment/remove this line from the init script and do the same for this line:

```
  need logger
```

BDz

----------

## bdz

Entropy42:

About the 2 cores that can't work at different frequencies/voltages settings your are right. This is clearly described in Intel's datasheet. So the speedstep-centrino CPUFreq driver would definitely need some enhancements to correctly handle this.

I did not read the datasheet in detail but it seems also right that the base voltage and index values encoding have changed.

I currently don't have any Code Duo processor available to make some tests myself but maybe if you want to discuss about this by mail we can work-out some solutions to better handle this CPU in the speedstep CPUFreq driver. (but I'm thinking about buying a new laptop, so maybe in the near future I will have a core duo  :Wink:  )

----------

## bdz

 *Egalus wrote:*   

> 
> 
> I am back in business faster than expected 
> 
> During the reinstall I chose to use kernel 2.6.16 and tried phc 0.2.2 and 0.2.3alpha from the post above mine.
> ...

 

Thank you very much for the feed-back.

About getting the undervolting patch into the vanilla kernel I think it would be very nice. But I don't have any knowledge about the process to make this happen. And I'm affraid that it would require more free time to do this than I currently have  :Sad: 

----------

## albright

thanks v. much for the logger advice BDZ. I second the motion

to have the undervolting patch put into the official kernel (but

have no idea what that involves).

----------

## weedy

is any of this possible on a P4? this is the first core

```
processor       : 0

vendor_id       : GenuineIntel

cpu family      : 15

model           : 2

model name      : Intel(R) Pentium(R) 4 CPU 2.60GHz

stepping        : 9

cpu MHz         : 3121.412

cache size      : 512 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 1

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr

bogomips        : 6251.97

```

----------

## francescofavero

Hi everyone, I'm using this patch for some time and I'm really impressed.

If enyone is interested I've done an ebuild, I've named gentrinoo-sources-2.6.16-r6 and there are suspend2, latest gentoo patchset and DSDT ACPI in initrd patch. 

```
# Copyright 1999-2006 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

ETYPE="sources"

K_WANT_GENPATCHES="base extras"

K_GENPATCHES_VER="9"

LINUX_PHC_VER="0.2.3"

LINUX_PHC_TARGET="2.6.16"

LINUX_PHC_SRC="linux-phc-${LINUX_PHC_VER}-kernel-${LINUX_PHC_TARGET}"

LINUX_PHC_URI="http://puzzle.dl.sourceforge.net/sourceforge/linux-phc/${LINUX_PHC_SRC}.tar.gz"

ACPI_DSDT_VER="v0.8.1"

ACPI_DSDT_TARGET="2.6.16"

ACPI_DSDT_SRC="acpi-dsdt-initrd-${ACPI_DSDT_VER}-${ACPI_DSDT_TARGET}"

ACPI_DSDT_URI="http://gaugusch.at/acpi-dsdt-initrd-patches/${ACPI_DSDT_SRC}.patch"

inherit eutils kernel-2

detect_version

detect_arch

DESCRIPTION="Software Suspend2 + PHC Centrino, ACPI DSDT in initrd patch and Gentoo patchset sources"

HOMEPAGE="http://dev.gentoo.org/~dsd/genpatches http://www.suspend2.net http://linux-phc.sourceforge.net/ http://gaugusch.at/kernel.shtml"

SUSPEND2_VERSION="2.2.5"

SUSPEND2_TARGET="2.6.16.9"

SUSPEND2_SRC="suspend2-${SUSPEND2_VERSION}-for-${SUSPEND2_TARGET}"

SUSPEND2_URI="http://www.suspend2.net/downloads/all/${SUSPEND2_SRC}.tar.bz2"

UNIPATCH_LIST="${DISTDIR}/${SUSPEND2_SRC}.tar.bz2

${DISTDIR}/${LINUX_PHC_SRC}.tar.gz

${DISTDIR}/${ACPI_DSDT_SRC}.patch"

UNIPATCH_STRICTORDER="yes"

UNIPATCH_DOCS="${WORKDIR}/patches/${SUSPEND2_SRC}/Changelog.txt

${WORKDIR}/patches/${SUSPEND2_SRC}/ToDo"

SRC_URI="${KERNEL_URI} ${GENPATCHES_URI} ${ARCH_URI} ${SUSPEND2_URI} ${LINUX_PHC_URI} ${ACPI_DSDT_URI}"

KEYWORDS="~amd64 ~x86"

IUSE="ultra1"

RDEPEND="${RDEPEND}

      >=sys-apps/suspend2-userui-0.6.1

      >=sys-power/hibernate-script-1.12"

K_EXTRAEINFO="If there are issues with this kernel, please direct any

queries to the suspend2-users mailing list:

http://lists.suspend2.net/mailman/listinfo/suspend2-users/"

pkg_setup() {

   if use sparc; then

      # hme lockup hack on ultra1

      use ultra1 || UNIPATCH_EXCLUDE="${UNIPATCH_EXCLUDE} 1705_sparc-U1-hme-lockup.patch"

   fi

}

pkg_postinst() {

   postinst_sources

   echo

   if [ "${ARCH}" = "sparc" ]; then

      if [ x"`cat /proc/openprom/name 2>/dev/null`" \

          = x"'SUNW,Ultra-1'" ]; then

         einfo "For users with an Enterprise model Ultra 1 using the HME"

         einfo "network interface, please emerge the kernel using the"

         einfo "following command: USE=ultra1 emerge ${PN}"

      fi

   fi

}

```

Hope it's fine for someone.

Regards...

----------

## bdz

Hello undervolting fellows!

I've just uploaded a new release of the Linux PHC patch on the SourceForge site (https://sourceforge.net/project/showfiles.php?group_id=161063)

There are no new features or bug fix in the patch itself for this release. 

So it may not be of a lot of interest for you unless you want to patch a 2.6.17 kernel.

Here is a copy of the release notes with the details of what's new:

```
    0.2.4 - 2006/05/21

    Maintenance release

    You don't need to upgrade your kernel to this version of the patch if

    you are using version 0.2.3. There is no bug fix or new feature in the

    patch itself

     - Merged patches for all kernel versions in a single tar ball

     - Cosmetic changes in kernel config and speedstep-centrino.c code

     - Added patch for vanilla kernel 2.6.17

     - Added patch for Ubuntu Dapper kernel 2.6.15

       (Thanks to Bernhard Grün for the porting of the patch to Ubuntu)

     - Added init script for Ubuntu

       (Thanks to Chris Ballessay for the porting of the script to Ubuntu)

     - Added utility script to build debug reports

     - Updated readme and patching procedure

     - Added kernel versions compatibility list (draft)
```

----------

## chercen

 *Quote:*   

> 
> 
> This new version is only useful for those of you, which have a problem with a wrongly detected FSB.
> 
> for some of you, this patch will already solve the problem with a wrong detected FSB.
> ...

 

Hi,

FSB hardcoded: I am not a hardware expert, but Acer ePowerManagerment reduces frequency down to 610 Mhz, what is only possible if FSB is reduced to 100 MHz. There is a way to do it, at least for acer laptops.

I have sucessfully applied the patch on Ubuntu Dapper, laptop Acer 1692 (sonoma 740, 1.73 MHz, FSB 533 MHz). However the fan kicks on when I get to 48º, and that is really annoying. In windows it kicks when temp gets to 68º. Is there any way to solve this annoying noise??  :Smile:  Any help would be appreciated...

Regards

----------

## chercen

 *rschwarze wrote:*   

> @ all the people with an overclocked pentium-m:
> 
> linux-phc reads the frontsidebus from the acpi, and the acpi gives the original, not overclocked, fsb. Therefore, your frequencies are reported incorrectly. Nonetheless, the undervolting should work fine, because it is done via the multiplicator only.
> 
> That means: The frequencies are reported wrong, but the multiplicator and the voltages are correct. So you can use the patch to change the voltages for your cpu.
> ...

 

Hi,

Here you are some outputs that might help, sorry I do not know how to attach files  :Smile: 

(phc 0.2.4, kernel from ubuntu dapper recompiled to support undervolting: everything seems to work except the fan that is almost always on)

- FSB frequency 

cesar@portatil:$ cat /sys/devices/system/cpu/cpu0/cpufreq/FSB_base_frequency

Base FSB frequency computed from operating points table:

133308 kHz (1733000 / 13)

133300 kHz (1333000 / 10)

133375 kHz (1067000 /  :Cool: 

133333 kHz (800000 / 6)

- Voltages and frequencies

cesar@portatil:$ cat /sys/devices/system/cpu/cpu0/cpufreq/op_points_table

1733000:1052,1333000:844,1067000:764,800000:700

- FSB freq with measurefreq

cesar@portatil:/boot/grub$ measurefreq

Estimated CPU frequency: 798 MHz (+/- 0.00276818 MHz)

- output of cpufreq-info

cesar@portatil:$ cpufreq-info

cpufrequtils 0.4: cpufreq-info (C) Dominik Brodowski 2004

Report errors and bugs to linux@brodo.de, please.

analyzing CPU 0:

  driver: centrino

  CPUs which need to switch frequency at the same time: 0

  hardware limits: 800 MHz - 1.73 GHz

  available frequency steps: 1.73 GHz, 1.33 GHz, 1.07 GHz, 800 MHz

  available cpufreq governors: ondemand, userspace, powersave, performance

  current policy: frequency should be within 800 MHz and 1.73 GHz.

                  The governor "powersave" may decide which speed to use

                  within this range.

  current CPU frequency is 800 MHz.

- output of cat /proc/cpuinfo

cesar@portatil:/boot/grub$ cat /proc/cpuinfo

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.73GHz

stepping        : 8

cpu MHz         : 1729.481

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2

bogomips        : 1597.41

- output of dmesg:

cesar@portatil:/boot/grub$ dmesg

[4294667.296000] Linux version 2.6.15.7-ubuntu1.060606 (root@portatil) (gcc versión 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) #1 SMP PREEMPT Tue Jun 6 17:43:09 CEST 2006

[4294667.296000] BIOS-provided physical RAM map:

[4294667.296000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)

[4294667.296000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)

[4294667.296000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)

[4294667.296000]  BIOS-e820: 0000000000100000 - 000000003fe80000 (usable)

[4294667.296000]  BIOS-e820: 000000003fe80000 - 000000003fe89000 (ACPI data)

[4294667.296000]  BIOS-e820: 000000003fe89000 - 000000003ff00000 (ACPI NVS)

[4294667.296000]  BIOS-e820: 000000003ff00000 - 0000000040000000 (reserved)

[4294667.296000]  BIOS-e820: 00000000e0000000 - 00000000f0006000 (reserved)

[4294667.296000]  BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)

[4294667.296000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)

[4294667.296000]  BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)

[4294667.296000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)

[4294667.296000] 126MB HIGHMEM available.

[4294667.296000] 896MB LOWMEM available.

[4294667.296000] On node 0 totalpages: 261760

[4294667.296000]   DMA zone: 4096 pages, LIFO batch:0

[4294667.296000]   DMA32 zone: 0 pages, LIFO batch:0

[4294667.296000]   Normal zone: 225280 pages, LIFO batch:31

[4294667.296000]   HighMem zone: 32384 pages, LIFO batch:7

[4294667.296000] DMI present.

[4294667.296000] ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f6970

[4294667.296000] ACPI: RSDT (v001 PTLTD    RSDT   0x06040000  LTP 0x00000000) @ 0x3fe80fc1

[4294667.296000] ACPI: FADT (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3fe88e8a

[4294667.296000] ACPI: MADT (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3fe88efe

[4294667.296000] ACPI: HPET (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3fe88f64

[4294667.296000] ACPI: MCFG (v001 INTEL  ALVISO   0x06040000 LOHR 0x0000005f) @ 0x3fe88f9c

[4294667.296000] ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x3fe88fd8

[4294667.296000] ACPI: SSDT (v001  PmRef  Cpu0Ist 0x00003000 INTL 0x20030224) @ 0x3fe813f6

[4294667.296000] ACPI: SSDT (v001  PmRef  Cpu0Cst 0x00003001 INTL 0x20030224) @ 0x3fe8121e

[4294667.296000] ACPI: SSDT (v001  PmRef    CpuPm 0x00003000 INTL 0x20030224) @ 0x3fe81005

[4294667.296000] ACPI: DSDT (v001 INTEL  ALVISO   0x06040000 MSFT 0x0100000e) @ 0x00000000

[4294667.296000] ACPI: PM-Timer IO Port: 0x1008

[4294667.296000] ACPI: Local APIC address 0xfee00000

[4294667.296000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)

[4294667.296000] Processor #0 6:13 APIC version 20

[4294667.296000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])

[4294667.296000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])

[4294667.296000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23

[4294667.296000] ACPI: IOAPIC (id[0x02] address[0xfec20000] gsi_base[24])

[4294667.296000] IOAPIC[1]: Unable to change apic_id!

[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)

[4294667.296000] ACPI: IRQ0 used by override.

[4294667.296000] ACPI: IRQ2 used by override.

[4294667.296000] ACPI: IRQ9 used by override.

[4294667.296000] Enabling APIC mode:  Flat.  Using 1 I/O APICs

[4294667.296000] ACPI: HPET id: 0x8086a201 base: 0x0

[4294667.296000] Using ACPI (MADT) for SMP configuration information

[4294667.296000] Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)

[4294667.296000] Built 1 zonelists

[4294667.296000] Kernel command line: root=/dev/hda5 ro quiet splash cpufreq.debug=3

[4294667.296000] mapped APIC to ffffd000 (fee00000)

[4294667.296000] mapped IOAPIC to ffffc000 (fec00000)

[4294667.296000] Initializing CPU#0

[4294667.296000] PID hash table entries: 4096 (order: 12, 65536 bytes)

[4294667.296000] Detected 1729.481 MHz processor.

[4294667.296000] Using pmtmr for high-res timesource

[4294667.296000] Console: colour VGA+ 80x25

[4294667.683000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

[4294667.684000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

[4294667.713000] Memory: 1025752k/1047040k available (2104k kernel code, 20560k reserved, 595k data, 332k init, 129536k highmem)

[4294667.713000] Checking if this processor honours the WP bit even in supervisor mode... Ok.

[4294667.773000] Calibrating delay using timer specific routine.. 3460.40 BogoMIPS (lpj=1730202)

[4294667.773000] Security Framework v1.0.0 initialized

[4294667.773000] SELinux:  Disabled at boot.

[4294667.773000] Mount-cache hash table entries: 512

[4294667.773000] CPU: After generic identify, caps: afe9fbff 00100000 00000000 00000000 00000180 00000000 00000000

[4294667.773000] CPU: After vendor identify, caps: afe9fbff 00100000 00000000 00000000 00000180 00000000 00000000

[4294667.773000] CPU: L1 I cache: 32K, L1 D cache: 32K

[4294667.773000] CPU: L2 cache: 2048K

[4294667.773000] CPU: After all inits, caps: afe9fbff 00100000 00000000 00000040 00000180 00000000 00000000

[4294667.773000] mtrr: v2.0 (20020519)

[4294667.773000] Enabling fast FPU save and restore... done.

[4294667.773000] Enabling unmasked SIMD FPU exception support... done.

[4294667.773000] Checking 'hlt' instruction... OK.

[4294667.777000] SMP alternatives: switching to UP code

[4294667.777000] checking if image is initramfs... it is

[4294668.351000] Freeing initrd memory: 6767k freed

[4294668.356000] ACPI: Looking for DSDT ... not found!

[4294668.361000] CPU0: Intel(R) Pentium(R) M processor 1.73GHz stepping 08

[4294668.361000] Total of 1 processors activated (3460.40 BogoMIPS).

[4294668.361000] ENABLING IO-APIC IRQs

[4294668.361000] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1

[4294668.472000] Brought up 1 CPUs

[4294668.472000] NET: Registered protocol family 16

[4294668.472000] EISA bus registered

[4294668.472000] ACPI: bus type pci registered

[4294668.472000] PCI: PCI BIOS revision 2.10 entry at 0xfd7be, last bus=7

[4294668.472000] PCI: Using MMCONFIG

[4294668.472000] ACPI: Subsystem revision 20051216

[4294668.813000] ACPI: Interpreter enabled

[4294668.813000] ACPI: Using IOAPIC for interrupt routing

[4294668.813000] ACPI: PCI Root Bridge [PCI0] (0000:00)

[4294668.813000] PCI: Probing PCI hardware (bus 00)

[4294668.816000] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO

[4294668.816000] PCI quirk: region 1180-11bf claimed by ICH6 GPIO

[4294668.816000] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1

[4294668.816000] Boot video device is 0000:01:00.0

[4294668.817000] PCI: Transparent bridge - 0000:00:1e.0

[4294668.817000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]

[4294668.822000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEGP._PRT]

[4294668.822000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]

[4294668.822000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]

[4294668.823000] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]

[4294668.824000] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 12 14 15)

[4294668.824000] ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 11 12 14 15) *10

[4294668.824000] ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 12 14 15) *11

[4294668.825000] ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 *11 12 14 15)

[4294668.825000] ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12 14 15) *11

[4294668.825000] ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12 14 15) *0, disabled.

[4294668.825000] ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 7 10 12 14 15) *0, disabled.

[4294668.825000] ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *11 12 14 15)

[4294668.826000] ACPI: Embedded Controller [EC0] (gpe 29) interrupt mode.

[4294668.849000] Linux Plug and Play Support v0.97 (c) Adam Belay

[4294668.849000] pnp: PnP ACPI init

[4294668.851000] pnp: PnP ACPI: found 9 devices

[4294668.851000] PnPBIOS: Disabled by ACPI PNP

[4294668.851000] PCI: Using ACPI for IRQ routing

[4294668.851000] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report

[4294668.851000] PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0

[4294668.851000] PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0

[4294668.851000] PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0

[4294668.851000] PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1

[4294668.851000] PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1

[4294668.851000] PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1

[4294668.851000] PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2

[4294668.851000] PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2

[4294668.851000] PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2

[4294668.865000] PCI: Bridge: 0000:00:01.0

[4294668.865000]   IO window: 3000-3fff

[4294668.865000]   MEM window: c8100000-c81fffff

[4294668.865000]   PREFETCH window: d0000000-d7ffffff

[4294668.865000] PCI: Bridge: 0000:00:1c.0

[4294668.865000]   IO window: disabled.

[4294668.865000]   MEM window: disabled.

[4294668.865000]   PREFETCH window: disabled.

[4294668.865000] PCI: Bridge: 0000:00:1c.1

[4294668.865000]   IO window: disabled.

[4294668.865000]   MEM window: disabled.

[4294668.865000]   PREFETCH window: disabled.

[4294668.865000] PCI: Bridge: 0000:00:1c.2

[4294668.865000]   IO window: disabled.

[4294668.865000]   MEM window: disabled.

[4294668.865000]   PREFETCH window: disabled.

[4294668.865000] PCI: Bus 7, cardbus bridge: 0000:06:01.0

[4294668.865000]   IO window: 00004000-000040ff

[4294668.865000]   IO window: 00004400-000044ff

[4294668.865000]   PREFETCH window: 50000000-51ffffff

[4294668.865000]   MEM window: 52000000-53ffffff

[4294668.865000] PCI: Bridge: 0000:00:1e.0

[4294668.865000]   IO window: 4000-4fff

[4294668.865000]   MEM window: c8200000-c82fffff

[4294668.865000]   PREFETCH window: 50000000-51ffffff

[4294668.865000] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169

[4294668.865000] PCI: Setting latency timer of device 0000:00:01.0 to 64

[4294668.865000] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 177

[4294668.865000] PCI: Setting latency timer of device 0000:00:1c.0 to 64

[4294668.865000] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 169

[4294668.865000] PCI: Setting latency timer of device 0000:00:1c.1 to 64

[4294668.865000] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 185

[4294668.865000] PCI: Setting latency timer of device 0000:00:1c.2 to 64

[4294668.865000] PCI: Setting latency timer of device 0000:00:1e.0 to 64

[4294668.865000] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 18 (level, low) -> IRQ 185

[4294668.865000] Simple Boot Flag at 0x36 set to 0x1

[4294668.865000] audit: initializing netlink socket (disabled)

[4294668.865000] audit(1149630240.863:1): initialized

[4294668.865000] highmem bounce pool size: 64 pages

[4294668.865000] VFS: Disk quotas dquot_6.5.1

[4294668.865000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

[4294668.865000] Initializing Cryptographic API

[4294668.865000] io scheduler noop registered

[4294668.865000] io scheduler anticipatory registered

[4294668.865000] io scheduler deadline registered

[4294668.865000] io scheduler cfq registered

[4294668.866000] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169

[4294668.866000] PCI: Setting latency timer of device 0000:00:01.0 to 64

[4294668.866000] assign_interrupt_mode Found MSI capability

[4294668.866000] Allocate Port Service[pcie00]

[4294668.866000] Allocate Port Service[pcie03]

[4294668.866000] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 177

[4294668.866000] PCI: Setting latency timer of device 0000:00:1c.0 to 64

[4294668.866000] assign_interrupt_mode Found MSI capability

[4294668.866000] Allocate Port Service[pcie00]

[4294668.866000] Allocate Port Service[pcie02]

[4294668.866000] Allocate Port Service[pcie03]

[4294668.866000] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 169

[4294668.866000] PCI: Setting latency timer of device 0000:00:1c.1 to 64

[4294668.866000] assign_interrupt_mode Found MSI capability

[4294668.866000] Allocate Port Service[pcie00]

[4294668.866000] Allocate Port Service[pcie02]

[4294668.866000] Allocate Port Service[pcie03]

[4294668.866000] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 185

[4294668.866000] PCI: Setting latency timer of device 0000:00:1c.2 to 64

[4294668.866000] assign_interrupt_mode Found MSI capability

[4294668.866000] Allocate Port Service[pcie00]

[4294668.866000] Allocate Port Service[pcie02]

[4294668.866000] Allocate Port Service[pcie03]

[4294668.866000] isapnp: Scanning for PnP cards...

[4294669.224000] isapnp: No Plug & Play device found

[4294669.237000] Real Time Clock Driver v1.12

[4294669.237000] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12

[4294669.265000] serio: i8042 AUX port at 0x60,0x64 irq 12

[4294669.269000] serio: i8042 KBD port at 0x60,0x64 irq 1

[4294669.269000] Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled

[4294669.270000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A

[4294669.271000] ACPI: PCI Interrupt 0000:00:1e.3[B] -> GSI 20 (level, low) -> IRQ 233

[4294669.271000] ACPI: PCI interrupt for device 0000:00:1e.3 disabled

[4294669.271000] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize

[4294669.271000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2

[4294669.271000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

[4294669.272000] mice: PS/2 mouse device common for all mice

[4294669.277000] EISA: Probing bus 0 at eisa.0

[4294669.277000] Cannot allocate resource for EISA slot 1

[4294669.277000] Cannot allocate resource for EISA slot 2

[4294669.277000] Cannot allocate resource for EISA slot 3

[4294669.277000] Cannot allocate resource for EISA slot 4

[4294669.277000] EISA: Detected 0 cards.

[4294669.277000] NET: Registered protocol family 2

[4294669.339000] input: AT Translated Set 2 keyboard as /class/input/input0

[4294669.342000] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

[4294669.342000] TCP established hash table entries: 131072 (order: 8, 1572864 bytes)

[4294669.343000] TCP bind hash table entries: 65536 (order: 7, 786432 bytes)

[4294669.345000] TCP: Hash tables configured (established 131072 bind 65536)

[4294669.345000] TCP reno registered

[4294669.345000] TCP bic registered

[4294669.345000] NET: Registered protocol family 1

[4294669.345000] NET: Registered protocol family 8

[4294669.345000] NET: Registered protocol family 20

[4294669.345000] Using IPI No-Shortcut mode

[4294669.404000] ACPI wakeup devices:

[4294669.404000] RP01 RP02 RP04 USB1 USB2 USB3 USB4 USB7 LANC MODM

[4294669.404000] ACPI: (supports S0 S3 S4 S5)

[4294669.404000] Freeing unused kernel memory: 332k freed

[4294669.405000] input: AT Translated Set 2 keyboard as /class/input/input1

[4294669.407000] atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.

[4294669.410000] atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.

[4294669.450000] vga16fb: initializing

[4294669.450000] vga16fb: mapped to 0xc00a0000

[4294669.450000] fb0: VGA16 VGA frame buffer device

[4294670.577000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3])

[4294670.577000] ACPI: Processor [CPU0] (supports 8 throttling states)

[4294670.580000] ACPI: Thermal Zone [THRM] (60 C)

[4294671.044000] ICH6: IDE controller at PCI slot 0000:00:1f.1

[4294671.044000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 185

[4294671.044000] ICH6: chipset revision 4

[4294671.044000] ICH6: not 100% native mode: will probe irqs later

[4294671.044000]     ide0: BM-DMA at 0x18c0-0x18c7, BIOS settings: hda:DMA, hdb:DMA

[4294671.044000] Probing IDE interface ide0...

[4294671.467000] hda: IC25N080ATMR04-0, ATA DISK drive

[4294672.596000] hdb: MATSHITAUJ-845D, ATAPI CD/DVD-ROM drive

[4294672.675000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

[4294672.705000] hda: max request size: 1024KiB

[4294672.711000] hda: 156301488 sectors (80026 MB) w/7884KiB Cache, CHS=16383/255/63, UDMA(100)

[4294672.711000] hda: cache flushes supported

[4294672.711000]  hda: hda1 hda2 hda3 < hda5 hda6 > hda4

[4294672.786000] hdb: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)

[4294672.786000] Uniform CD-ROM driver Revision: 3.20

[4294673.389000] usbcore: registered new driver usbfs

[4294673.390000] usbcore: registered new driver hub

[4294673.391000] USB Universal Host Controller Interface driver v2.3

[4294673.392000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 50

[4294673.392000] PCI: Setting latency timer of device 0000:00:1d.0 to 64

[4294673.392000] uhci_hcd 0000:00:1d.0: UHCI Host Controller

[4294673.393000] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1

[4294673.393000] uhci_hcd 0000:00:1d.0: irq 50, io base 0x00001800

[4294673.394000] hub 1-0:1.0: USB hub found

[4294673.394000] hub 1-0:1.0: 2 ports detected

[4294673.457000] ieee1394: Initialized config rom entry `ip1394'

[4294673.515000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 58

[4294673.515000] PCI: Setting latency timer of device 0000:00:1d.1 to 64

[4294673.515000] uhci_hcd 0000:00:1d.1: UHCI Host Controller

[4294673.515000] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2

[4294673.515000] uhci_hcd 0000:00:1d.1: irq 58, io base 0x00001820

[4294673.515000] hub 2-0:1.0: USB hub found

[4294673.515000] hub 2-0:1.0: 2 ports detected

[4294673.623000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 185

[4294673.623000] PCI: Setting latency timer of device 0000:00:1d.2 to 64

[4294673.623000] uhci_hcd 0000:00:1d.2: UHCI Host Controller

[4294673.623000] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3

[4294673.623000] uhci_hcd 0000:00:1d.2: irq 185, io base 0x00001840

[4294673.624000] hub 3-0:1.0: USB hub found

[4294673.624000] hub 3-0:1.0: 2 ports detected

[4294673.751000] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 169

[4294673.751000] PCI: Setting latency timer of device 0000:00:1d.3 to 64

[4294673.751000] uhci_hcd 0000:00:1d.3: UHCI Host Controller

[4294673.751000] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4

[4294673.751000] uhci_hcd 0000:00:1d.3: irq 169, io base 0x00001860

[4294673.751000] hub 4-0:1.0: USB hub found

[4294673.751000] hub 4-0:1.0: 2 ports detected

[4294673.871000] usb 2-2: new low speed USB device using uhci_hcd and address 2

[4294673.873000] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 50

[4294673.873000] PCI: Setting latency timer of device 0000:00:1d.7 to 64

[4294673.873000] ehci_hcd 0000:00:1d.7: EHCI Host Controller

[4294673.873000] ehci_hcd 0000:00:1d.7: debug port 1

[4294673.873000] PCI: cache line size of 32 is not supported by device 0000:00:1d.7

[4294673.873000] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5

[4294673.873000] ehci_hcd 0000:00:1d.7: irq 50, io mem 0xc8000000

[4294673.877000] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004

[4294673.878000] hub 5-0:1.0: USB hub found

[4294673.878000] hub 5-0:1.0: 8 ports detected

[4294673.999000] ohci1394: $Rev: 1313 $ Ben Collins <bcollins@debian.org>

[4294673.999000] ACPI: PCI Interrupt 0000:06:01.2[A] -> GSI 18 (level, low) -> IRQ 185

[4294674.050000] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[185]  MMIO=[c8217000-c82177ff]  Max Packet=[2048]

[4294674.076000] Probing IDE interface ide1...

[4294674.412000] usb 2-2: new low speed USB device using uhci_hcd and address 3

[4294674.616000] usbcore: registered new driver hiddev

[4294674.637000] input: KYE NetScroll+ Traveler as /class/input/input2

[4294674.637000] input: USB HID v1.10 Mouse [KYE NetScroll+ Traveler] on usb-0000:00:1d.1-2

[4294674.637000] usbcore: registered new driver usbhid

[4294674.637000] drivers/usb/input/hid-core.c: v2.6:USB HID core driver

[4294674.896000] Attempting manual resume

[4294674.949000] EXT3-fs: mounted filesystem with ordered data mode.

[4294674.964000] kjournald starting.  Commit interval 5 seconds

[4294675.333000] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00c09f00004f8ad4]

[4294681.766000] ts: Compaq touchscreen protocol output

[4294682.634000] pci_hotplug: PCI Hot Plug PCI Core version: 0.5

[4294682.639000] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4

[4294682.885000] hw_random: RNG not detected

[4294682.891000] Linux agpgart interface v0.101 (c) Dave Jones

[4294682.909000] agpgart: Detected an Intel 915GM Chipset.

[4294682.927000] agpgart: AGP aperture is 256M @ 0x0

[4294683.401000] ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 17 (level, low) -> IRQ 177

[4294683.401000] PCI: Setting latency timer of device 0000:00:1e.2 to 64

[4294683.709000] intel8x0_measure_ac97_clock: measured 51289 usecs

[4294683.709000] intel8x0: clocking to 48000

[4294683.710000] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 18 (level, low) -> IRQ 185

[4294683.710000] Yenta: CardBus bridge found at 0000:06:01.0 [1025:0066]

[4294683.710000] Yenta: Enabling burst memory read transactions

[4294683.710000] Yenta: Using CSCINT to route CSC interrupts to PCI

[4294683.710000] Yenta: Routing CardBus interrupts to PCI

[4294683.710000] Yenta TI: socket 0000:06:01.0, mfunc 0x01c21b22, devctl 0x64

[4294683.740000] irda_init()

[4294683.740000] NET: Registered protocol family 23

[4294683.819000] nsc_ircc_pnp_probe() : Found cfg_base 0x000 ; firbase 0x2F8 ; irq 3 ; dma 1.

[4294683.819000] nsc-ircc, Found chip at base=0x000

[4294683.819000] nsc-ircc, driver loaded (Dag Brattli)

[4294683.819000] IrDA: Registered device irda0

[4294683.819000] nsc-ircc, Found dongle: Supports SIR Mode only

[4294683.819000] nsc-ircc, Found chip at base=0x164e

[4294683.819000] nsc-ircc, driver loaded (Dag Brattli)

[4294683.819000] nsc_ircc_open(), can't get iobase of 0x2f8

[4294683.879000] ieee80211_1_1_13_crypt: registered algorithm 'NULL'

[4294683.907000] ieee80211_1_1_13: 802.11 data/management/control stack, 1.1.13

[4294683.907000] ieee80211_1_1_13: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

[4294683.940000] Yenta: ISA IRQ mask 0x0cf0, PCI irq 185

[4294683.940000] Socket status: 30000006

[4294683.940000] Yenta: Raising subordinate bus# of parent bus (#06) from #07 to #08

[4294683.940000] pcmcia: parent PCI bridge I/O window: 0x4000 - 0x4fff

[4294683.940000] cs: IO port probe 0x4000-0x4fff: clean.

[4294683.940000] pcmcia: parent PCI bridge Memory window: 0xc8200000 - 0xc82fffff

[4294683.940000] pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x51ffffff

[4294683.974000] Synaptics Touchpad, model: 1, fw: 5.9, id: 0x126eb1, caps: 0xa04713/0x4000

[4294683.987000] tg3.c:v3.47 (Dec 28, 2005)

[4294683.988000] ACPI: PCI Interrupt 0000:06:08.0[A] -> GSI 16 (level, low) -> IRQ 169

[4294684.012000] input: SynPS/2 Synaptics TouchPad as /class/input/input3

[4294684.054000] eth0: Tigon3 [partno(BCM95705A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:c0:9f:96:0b:e0

[4294684.054000] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[0] TSOcap[1]

[4294684.054000] eth0: dma_rwctrl[763f0000]

[4294684.206000] ieee80211_crypt: registered algorithm 'NULL'

[4294684.233000] ieee80211: 802.11 data/management/control stack, git-1.1.7

[4294684.233000] ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>

[4294684.580000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.1.1

[4294684.580000] ipw2200: Copyright(c) 2003-2006 Intel Corporation

[4294684.580000] Warning: PCI driver ipw2200 has a struct device_driver shutdown method, please update!

[4294684.580000] ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 17 (level, low) -> IRQ 177

[4294684.580000] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection

[4294684.925000] ipw2200: Detected geography ZZM (11 802.11bg channels, 0 802.11a channels)

[4294684.947000] cs: IO port probe 0x100-0x3af: clean.

[4294684.948000] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7

[4294684.949000] cs: IO port probe 0x820-0x8ff: clean.

[4294684.949000] cs: IO port probe 0xc00-0xcf7: clean.

[4294684.950000] cs: IO port probe 0xa00-0xaff: clean.

[4294685.070000] ieee80211_crypt: registered algorithm 'WEP'

[4294685.414000] lp: driver loaded but no devices found

[4294685.522000] SCSI subsystem initialized

[4294685.534000] sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>

[4294685.534000] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)

[4294685.534000] ieee1394: sbp2: Try serialize_io=0 for better performance

[4294685.587000] eth1: NETDEV_TX_BUSY returned; driver should report queue full via ieee_device->is_queue_full.

[4294685.714000] Adding 1461904k swap on /dev/hda4.  Priority:-1 extents:1 across:1461904k

[4294686.941000] EXT3 FS on hda5, internal journal

[4294687.654000] md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27

[4294687.654000] md: bitmap version 4.39

[4294688.403000] device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com

[4294689.032000] cdrom: open failed.

[4294691.742000] NET: Registered protocol family 17

[4294696.022000] ACPI: AC Adapter [ACAD] (on-line)

[4294696.043000] ACPI: Battery Slot [BAT1] (battery present)

[4294696.044000] ACPI: Battery Slot [BAT2] (battery absent)

[4294696.292000] ACPI: Power Button (FF) [PWRF]

[4294696.292000] ACPI: Lid Switch [LID]

[4294696.292000] ACPI: Power Button (CM) [PWRB]

[4294696.292000] ACPI: Sleep Button (CM) [SLPB]

[4294696.379000] ibm_acpi: ec object not found

[4294696.573000] pcc_acpi: loading...

[4294696.766000] ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)

[4294699.921000] serial8250: too much work for irq3

[4294701.112000] cpufreq-core: trying to register driver centrino

[4294701.112000] cpufreq-core: adding CPU 0

[4294701.112000] speedstep-centrino: adding state 0 with frequency 1733000 and control value 0d29

[4294701.112000] speedstep-centrino: adding state 1 with frequency 1333000 and control value 0a20

[4294701.113000] speedstep-centrino: adding state 2 with frequency 1067000 and control value 0819

[4294701.113000] speedstep-centrino: adding state 3 with frequency 800000 and control value 0612

[4294701.113000] speedstep-centrino: centrino_cpu_init: cur=1733000kHz

[4294701.113000] freq-table: table entry 0: 1733000 kHz, 3369 index

[4294701.113000] freq-table: table entry 1: 1333000 kHz, 2592 index

[4294701.113000] freq-table: table entry 2: 1067000 kHz, 2073 index

[4294701.114000] freq-table: table entry 3: 800000 kHz, 1554 index

[4294701.114000] freq-table: setting show_table for cpu 0 to dfa99d80

[4294701.115000] cpufreq-core: setting new policy for CPU 0: 800000 - 1733000 kHz

[4294701.115000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.116000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.116000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.116000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.116000] cpufreq-core: new min and max freqs are 800000 - 1733000 kHz

[4294701.116000] cpufreq-core: governor switch

[4294701.116000] cpufreq-core: __cpufreq_governor for CPU 0, event 1

[4294701.116000] cpufreq-core: target for CPU 0: 1733000 kHz, relation 1

[4294701.117000] freq-table: request for target 1733000 kHz (relation: 1) for cpu 0

[4294701.117000] freq-table: target is 0 (1733000 kHz, 3369)

[4294701.117000] speedstep-centrino: no change needed - msr was and needs to be d29

[4294701.117000] cpufreq-core: governor: change or update limits

[4294701.117000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

[4294701.117000] cpufreq-core: target for CPU 0: 1733000 kHz, relation 1

[4294701.117000] freq-table: request for target 1733000 kHz (relation: 1) for cpu 0

[4294701.117000] freq-table: target is 0 (1733000 kHz, 3369)

[4294701.118000] speedstep-centrino: no change needed - msr was and needs to be d29

[4294701.118000] cpufreq-core: initialization complete

[4294701.118000] cpufreq-core: driver centrino up and running

[4294701.426000] apm: BIOS not found.

[4294701.830000] cpufreq-core: setting new policy for CPU 0: 800000 - 1733000 kHz

[4294701.830000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.831000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.831000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.831000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.831000] cpufreq-core: new min and max freqs are 800000 - 1733000 kHz

[4294701.831000] cpufreq-core: governor switch

[4294701.831000] cpufreq-core: __cpufreq_governor for CPU 0, event 2

[4294701.831000] cpufreq-core: __cpufreq_governor for CPU 0, event 1

[4294701.832000] cpufreq-core: governor: change or update limits

[4294701.832000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

[4294701.862000] cpufreq-core: setting new policy for CPU 0: 800000 - 1733000 kHz

[4294701.863000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.863000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.863000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.863000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.863000] cpufreq-core: new min and max freqs are 800000 - 1733000 kHz

[4294701.863000] cpufreq-core: governor: change or update limits

[4294701.864000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

[4294701.866000] cpufreq-core: <4>Warning: CPU frequency out of sync: cpufreq and timing core thinks of 1733000, is 800000 kHz.

[4294701.866000] cpufreq-core: notification 0 of frequency transition to 800000 kHz

[4294701.866000] cpufreq-core: notification 1 of frequency transition to 800000 kHz

[4294701.866000] cpufreq-core: handle_update for cpu 0 called

[4294701.866000] cpufreq-core: updating policy for CPU 0

[4294701.866000] cpufreq-core: setting new policy for CPU 0: 800000 - 1733000 kHz

[4294701.866000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.866000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.866000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294701.866000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294701.866000] cpufreq-core: new min and max freqs are 800000 - 1733000 kHz

[4294701.866000] cpufreq-core: governor: change or update limits

[4294701.866000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

[4294701.868000] freq-table: request for target 800000 kHz (relation: 0) for cpu 0

[4294701.868000] freq-table: target is 3 (800000 kHz, 1536)

[4294701.868000] speedstep-centrino: target=800000kHz old=0 new=800000 msr=0600

[4294701.868000] cpufreq-core: notification 0 of frequency transition to 800000 kHz

[4294701.868000] cpufreq-core: <4>Warning: CPU frequency is 0, cpufreq assumed 800000 kHz.

[4294704.723000] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.

[4294704.724000] [fglrx] Maximum main memory to use for locked dma buffers: 926 MBytes.

[4294704.724000] [fglrx] module loaded - fglrx 8.25.18 [May 18 2006] on minor 0

[4294704.748000] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 169

[4294705.961000] NET: Registered protocol family 10

[4294705.961000] lo: Disabled Privacy Extensions

[4294705.961000] IPv6 over IPv4 tunneling driver

[4294706.204000] [fglrx] total      GART = 67108864

[4294706.204000] [fglrx] free       GART = 51118080

[4294706.204000] [fglrx] max single GART = 51118080

[4294706.204000] [fglrx] total      LFB  = 60846080

[4294706.204000] [fglrx] free       LFB  = 52654080

[4294706.204000] [fglrx] max single LFB  = 52654080

[4294706.205000] [fglrx] total      Inv  = 0

[4294706.205000] [fglrx] free       Inv  = 0

[4294706.205000] [fglrx] max single Inv  = 0

[4294706.205000] [fglrx] total      TIM  = 0

[4294716.586000] eth1: no IPv6 routers present

[4294736.386000] Bluetooth: Core ver 2.8

[4294736.386000] NET: Registered protocol family 31

[4294736.386000] Bluetooth: HCI device and connection manager initialized

[4294736.386000] Bluetooth: HCI socket layer initialized

[4294751.577000] cpufreq-core: setting new policy for CPU 0: 800000 - 1733000 kHz

[4294751.577000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294751.577000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294751.577000] freq-table: request for verification of policy (800000 - 1733000 kHz) for cpu 0

[4294751.577000] freq-table: verification lead to (800000 - 1733000 kHz) for cpu 0

[4294751.577000] cpufreq-core: new min and max freqs are 800000 - 1733000 kHz

[4294751.577000] cpufreq-core: governor switch

[4294751.577000] cpufreq-core: __cpufreq_governor for CPU 0, event 2

[4294751.577000] cpufreq-core: __cpufreq_governor for CPU 0, event 1

[4294751.577000] cpufreq-core: target for CPU 0: 800000 kHz, relation 0

[4294751.577000] freq-table: request for target 800000 kHz (relation: 0) for cpu 0

[4294751.577000] freq-table: target is 3 (800000 kHz, 1536)

[4294751.577000] speedstep-centrino: target=800000kHz old=1733000 new=800000 msr=0600

[4294751.577000] cpufreq-core: notification 0 of frequency transition to 800000 kHz

[4294751.577000] cpufreq-core: notification 1 of frequency transition to 800000 kHz

[4294751.577000] cpufreq-core: governor: change or update limits

[4294751.577000] cpufreq-core: __cpufreq_governor for CPU 0, event 3

[4294751.577000] cpufreq-core: target for CPU 0: 800000 kHz, relation 0

[4294751.577000] freq-table: request for target 800000 kHz (relation: 0) for cpu 0

[4294751.577000] freq-table: target is 3 (800000 kHz, 1536)

[4294751.577000] speedstep-centrino: no change needed - msr was and needs to be 600

[4294830.001000] synaptics: using relaxed packet validation

----------

## Egalus

I just wanted to mention that the new version patches 2.6.17 nicely and worls without problems.

Thx again for this great patch.

----------

## bdz

 *Egalus wrote:*   

> I just wanted to mention that the new version patches 2.6.17 nicely and worls without problems.
> 
> Thx again for this great patch.

 

Thank you for your feedback.

----------

## bdz

Hello udervolting fellows!

We have just released a new version of the Linux-PHC patch.

Here is the change log:

```
0.2.6 - July, 23th 2006: Maintenance release 

    * Support of vanilla kernel version 2.6.18-rc2

    * Support of ubuntu kernel version 2.6.17-5.15 (edgy eft)

    * Added safety code to avoid using invalid operating points on some laptops

    * Documentation update

    * Debug report script enhancement 

```

You can download it from the sourceforge site: http://sourceforge.net/project/showfiles.php?group_id=161063

We have also setup a new web site. You can visit it here:  https://www.dedigentoo.org/trac/linux-phc

One last thing, that may not be very interesting for most readers of this thread: 

We are working to add the same sysfs interface to the powernow-k8 driver to undervolt AMD Athlon 64 and Opteron CPUs. 

Everybody interested by this new feature can contact us with our mailing list (have a look at the new web site for a link to the linux-phc-user mailing list)

Have a cool undervolting,

BDz

----------

## Mirza

```
patching file arch/i386/kernel/cpu/cpufreq/Kconfig

patching file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c

Hunk #1 FAILED at 11.

Hunk #2 succeeded at 56 (offset 5 lines).

Hunk #4 succeeded at 214 (offset 5 lines).

Hunk #6 succeeded at 566 (offset 5 lines).

Hunk #7 FAILED at 749.

Hunk #8 succeeded at 716 (offset -40 lines).

Hunk #9 FAILED at 745.

Hunk #10 succeeded at 1423 with fuzz 1 (offset -66 lines).

Hunk #11 succeeded at 1505 (offset -53 lines).

3 out of 11 hunks FAILED -- saving rejects to file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.rej

```

see? this is 2.6.18 vanilla kernel ... I was using patch from the SVN: linux-phc-0.2.6-kernel-vanilla-2.6.18.patch

M.

----------

## bdz

 *Mirza wrote:*   

> 
> 
> ```
> patching file arch/i386/kernel/cpu/cpufreq/Kconfig
> 
> ...

 

Can you give the exact version of the kernel you have tried to patch?

linux-phc-0.2.6-kernel-vanilla-2.6.18.patch is based on linux vanilla 2.6.18-rc2

I have tried it on the latest prepatch linux version: vanilla 2.6.18-rc4 and it gave this:

```

Applying patch

patching file arch/i386/kernel/cpu/cpufreq/Kconfig

Hunk #2 succeeded at 109 (offset 1 line).

Hunk #3 succeeded at 151 (offset 1 line).

patching file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c

```

There was some changes in arch/i386/kernel/cpu/cpufreq/Kconfig between 2.6.18-rc2 and 2.6.18-rc4 but the patch still apply correctly.

BDz

----------

## Mirza

ooops ... my mistake ... I forgot that I already applied 2 other patches which are little bit conflicting with your patch. sorry.

now is everything ok.

M.

----------

## lxnay

why not using cpupw ? http://www.tuxamito.com.es/cpupw/index.php

----------

## heilong

I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:

"2000000:1404,1667000:1276,1333000:1148,1000000:1004"

A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,

the defaults being 0.95V at 1GHz and 1.2625V at 2GHz.

What is right and what is wrong?

----------

## bdz

 *heilong wrote:*   

> I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:
> 
> "2000000:1404,1667000:1276,1333000:1148,1000000:1004"
> 
> A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,
> ...

 

Linux PHC is wrong.

The formula currently used to compute voltage values from VID values is only applicable to Intel Pentium M processors (And maybe some VIA processors).

The current formula is:

```
Vcc = 700 + VID * 16
```

From the voltages you have posted we can computed the VID values that were used by Linux PHC to compute Vcc values:

```
2000 MHz: Vcc = 1404 mV -> VID = 44

1667 MHz: Vcc = 1276 mV -> VID = 36

1333 MHz: Vcc = 1148 mV -> VID = 28

1000 MHz: Vcc = 1004 mV -> VID = 19
```

I'm still not sure of that, but I think that the correct formula for Intel Core processors (not Core 2) is the following:

Vcc = 712.5 + VID * 12.5

(This formula would be valid only for VID between 0 and 63)

From the VID values computed above this would give these Vcc voltages values:

```
2000 MHz: VID = 44 -> Vcc = 1262.5 mV

1667 MHz: VID = 36 -> Vcc = 1162.5 mV

1333 MHz: VID = 28 -> Vcc = 1052.5 mV

1000 MHz: VID = 19 -> Vcc = 950.0 mV
```

BDz

----------

## heilong

Thanks a lot!

So to fool undervolt to set voltage at 2GHz to 1.0625V, I get it's VID with the 2nd formula: 28, then put it in the 1st formula to get what

linux-phc thinks is the voltage: 1148. Wow, it's cool. Literally, CPU is very cool now ).

Btw, having different /sys/.../cpu0/op_points_table and /sys/.../cpu1/op_points_table didn't look too good to me, so I added

a couple of lines in /etc/conf.d/undervolt & /etc/init.d/undervolt to write the same VTABLE to cpu1/op_points_table. I guess this

will be fixed in some Core Duo (speedstep?) code along with the "CPUs which need to switch frequency at the same time" feature.

----------

## heilong

Btw, bdz, can you tell me one thing? RMClock under windows can't set voltage on my core duo lower than 0.95V. I'm sure it'll work fine at lower voltages at 1000MHz, for example (coz 0.95V is the default for 1000MHz). linux-phc, on the other hand, allows to echo lower values to the op_points_table. Does it really set the voltage to lower levels or does it just silently ignores the request? Is this a core duo hardware cap, or is it done in software? Can it be overriden in windoze and linux?

----------

## bdz

 *heilong wrote:*   

> Thanks a lot!
> 
> So to fool undervolt to set voltage at 2GHz to 1.0625V, I get it's VID with the 2nd formula: 28, then put it in the 1st formula to get what
> 
> linux-phc thinks is the voltage: 1148. Wow, it's cool. Literally, CPU is very cool now ).

 

You are very welcome. It's good to know that this trick is working  :Smile: 

 *heilong wrote:*   

> Btw, having different /sys/.../cpu0/op_points_table and /sys/.../cpu1/op_points_table didn't look too good to me, so I added
> 
> a couple of lines in /etc/conf.d/undervolt & /etc/init.d/undervolt to write the same VTABLE to cpu1/op_points_table. I guess this
> 
> will be fixed in some Core Duo (speedstep?) code along with the "CPUs which need to switch frequency at the same time" feature.

 

I don't know if this feature will solve this problem by itself or if it will require some modifications in the undervolting patch to change the voltages of both CPU at the same time.

And there is another upcoming feature of the Linux kernel that will change a lot of things regarding undervolting: "merge acpi functionality of cpufreq drivers". This feature will remove the ACPI support from the speedstep-centrino driver and merge it into the acpi-cpufreq driver.

As there is no builtin table support for Intel Core processors in speedstep-centrino this means that undervolting these processors with Linux PHC will not be possible anymore. 

And people with a Pentium M processor that are using ACPI table will have to switch to built-in table to continue using the undervolting code of speedstep-centrino. (There are good reasons for not wanting to switch to built-in table for Pentium M Dothan processors)

There are solutions for this. One solution would be to add builtin table support for Intel Core processors in speedstep-centrino driver. 

Another solution would be to add the undervolting code in the acpi-cpufreq driver. 

But I will not be able to implement myself any of these solutions in the near future.

 *heilong wrote:*   

> Btw, bdz, can you tell me one thing? RMClock under windows can't set voltage on my core duo lower than 0.95V. I'm sure it'll work fine at lower voltages at 1000MHz, for example (coz 0.95V is the default for 1000MHz). linux-phc, on the other hand, allows to echo lower values to the op_points_table. Does it really set the voltage to lower levels or does it just silently ignores the request? Is this a core duo hardware cap, or is it done in software? Can it be overriden in windoze and linux?

 

Linux PHC will use the voltages you give to it if they are between 700 mV and the default voltages of the processor.

A while back, while googling around for information about Intel Core processors, I have read some things about about a cap at 0.95 V for the lowest frequency on Intel Core Duo processors. This is one thing about these processors that I've not been able to verify yet. (I dont have any computer with an Intel Core processor)

However if you are able to undervolt your Core Duo with Linux PHC I can tell you how you can verify this yourself:

I have written a small command line utility that reads some information in various place of the computers. I have written it so that people can run it on their computer to help me trying to understand how Core Duo processors are different from Pentium M processors.

Among the gathered information there are the PERF_CONTROL and PERF_STATUS MSR registers. From these registers you can get several frequency and voltage values:

Min specification frequency and voltage

Max specification frequency and voltage

Target frequency and voltage (This is where you will see if Linux PHC takes into account your settings)

Current frequency and voltage (This is where you should see if the processor takes into account the settings or if there is a cap)

Actually the program outputs the FIDs and the VIDs not the values in Hz and Volts. The interesting part of its output looks like this:

```
Detected 2 CPUs

Vendor:   0

Family:   6

Model:   14

Mask:   8

Type:   Intel CORE

CpuFreq info:

  CPU 0: driver = centrino, governor = performance

  CPU 1: driver = centrino, governor = performance

MSR registers:

  CPU 0: PERF_CTL=0x0000000000000a2c, PERF_STATUS=0x06130a2c06000a2c, FSB_FREQ=0x0000000000000133

  CPU 1: PERF_CTL=0x0000000000000a2c, PERF_STATUS=0x06130a2c06000a2c, FSB_FREQ=0x0000000000000133

        |     CPU 0     |     CPU 1     |

        +-------+-------+-------+-------+

        | FID   | VID   | FID   | VID   |

--------+-------+-------+-------+-------+

Min     | 6     | 19    | 6     | 19    |

Max     | 10    | 44    | 10    | 44    |

--------+-------+-------+-------+-------+

Target  | 10    | 44    | 10    | 44    |

Current | 10    | 44    | 10    | 44    |

--------+-------+-------+-------+-------+
```

In these results:

If you don't have the expected VID in the "Target" line you can tell that the undervolting code has not taken into account your settings.

If you have the same FID and VID for both CPU in the "Target" line and if the VID value is what you have requested but you don't have the same values in the "Current" line you can tell that something is limiting your settings at the processor level.

You can get the source code of this application here: https://www.dedigentoo.org/bdz/linux-phc/

Take the latest msrinfo-X.Y.Z.tar.gz file you find there.

Then you can compile it with something similar to that:

```
$ su -

# cd /tmp

# wget https://www.dedigentoo.org/bdz/linux-phc/msrinfo-0.3.5.tar.gz

# tar xzf msrinfo-0.3.5.tar.gz

# cd msrinfo-0.3.5

# ./configure --prefix=/usr

# make && make install
```

Then you should be able to run the msrinfo program.

Note that you need to be root to be able to run it. You will also need to have the MSR device compiled in your kernel (either builtin or as a module)

Best regards,

BDz

----------

## heilong

Could use less detail in describing how to compile this )

So, anyway, I've just switched to 1GHz and I can see the "current" VID is only set on CPU0 (at least logically, maybe physically they're synced)

	|     CPU 0	|     CPU 1	|

        +-------+-------+-------+-------+

	| FID	| VID	| FID	| VID	|

--------+-------+-------+-------+-------+

Min	| 6	| 19	| 6	| 19	|

Max	| 12	| 44	| 12	| 44	|

--------+-------+-------+-------+-------+

Target	| 6	| 19	| 12	| 28	|

Current	| 12	| 28	| 12	| 28	|

--------+-------+-------+-------+-------+

The min VID of 19, with the 712.5 + VID * 12.5 gives 0.95V. I'll try setting smth lower now.

----------

## heilong

Yep, setting it to 0.9V (vid=15) didn't work. One side note - when I echo the new VTABLE to the /sys/...op_points_table, my CPU frequence changes from 1GHz to 2GHz. Is this a bug or a feature?

	|     CPU 0	|     CPU 1	|

        +-------+-------+-------+-------+

	| FID	| VID	| FID	| VID	|

--------+-------+-------+-------+-------+

Min	| 6	| 19	| 6	| 19	|

Max	| 12	| 44	| 12	| 44	|

--------+-------+-------+-------+-------+

Target	| 6	| 15	| 6	| 15	|

Current	| 6	| 19	| 6	| 19	|

--------+-------+-------+-------+-------+

----------

## bdz

 *heilong wrote:*   

> Yep, setting it to 0.9V (vid=15) didn't work. One side note - when I echo the new VTABLE to the /sys/...op_points_table, my CPU frequence changes from 1GHz to 2GHz. Is this a bug or a feature?
> 
> ```
>         |     CPU 0     |     CPU 1     |
> 
> ...

 

Does not look like a feature  :Smile: 

What did you echo to /sys/...op_points_table? 

Where do you look for frequency to see it change from 1GHz to 2GHz? (The frequency estimation of msrinfo is very likely to be wrong)

From you msrinfo output above the current FID is 6 on both cores. This indicates that the CPU is at 1 GHz. Were you seeing that the CPU was at 2 GHz at the same time you had this output from msrinfo?

Also, seeing the complete output of msr info would be interesting, or at least the part that is before the table.

BDz

----------

## heilong

I used this: 

echo 2000000:1148,1667000:1068,1333000:1004,1000000:940 >/sys/devices/system/cpu/cpu0/cpufreq/op_points_table

Couldn't reproduce switching to 2GHz this time. I'll post if I can.

msrinfo output:

Detected 2 CPUs

Vendor:	0

Family:	6

Model:	14

Mask:	8

Type:	Intel CORE

CpuFreq info:

  CPU 0: driver = centrino, governor = userspace

  CPU 1: driver = centrino, governor = userspace

MSR registers:

  CPU 0: PERF_CTL=0x000000000000060f, PERF_STATUS=0x06130c2c06000613, FSB_FREQ=0x0000000000000133

  CPU 1: PERF_CTL=0x000000000000060f, PERF_STATUS=0x06130c2c06000613, FSB_FREQ=0x0000000000000133

	|     CPU 0	|     CPU 1	|

        +-------+-------+-------+-------+

	| FID	| VID	| FID	| VID	|

--------+-------+-------+-------+-------+

Min	| 6	| 19	| 6	| 19	|

Max	| 12	| 44	| 12	| 44	|

--------+-------+-------+-------+-------+

Target	| 6	| 15	| 6	| 15	|

Current	| 6	| 19	| 6	| 19	|

--------+-------+-------+-------+-------+

Frequency estimations based on TSC:

  CPU 0: core = 1995.12 MHz, bus = 332.52 MHz

  CPU 1: core = 1995.03 MHz, bus = 332.505 MHz

Frequency estimations based on BogoMIPS from /proc/cpuinfo:

  CPU 0: core = 1996.4 MHz, bus = 332.733 MHz, bogomips = 3992.8

  CPU 1: core = 1994.73 MHz, bus = 332.456 MHz, bogomips = 3989.47

Frequency estimations based on measured BogoMIPS:

  CPU 0: core = 997.293 MHz, bus = 166.215 MHz, bogoratio = 2.0004

  CPU 1: core = 997.362 MHz, bus = 166.227 MHz, bogoratio = 2.0004

Frequency estimations based on the FSB_FREQ MSR register:

  CPU 0: core = 1000.02 MHz, bus = 166.67 MHz

  CPU 1: core = 1000.02 MHz, bus = 166.67 MHz

----------

## albright

I've undervolting for a year and a half or so on a fujitsu

p7010 (1.1 ghz centrino) without a hitch ... In the last

little while my notebook has been suffering infrequent,

random hard lockups (nothing in the logs AFAIK).

I disabled undervolting and so far no lockups (but more fan  :Sad:   )

Is it possible that a chip could *lose* its ability to

undervolt over time?

----------

## heilong

albright, maybe you just need to blow the dust away from your CPU's heatsink?

----------

## ottuzzi

Hi there,

I run msrinfo from [1] on my HP nc8430 Core2DUO T7200.

Here are the results:

```
Detected 2 CPUs

Vendor: 0

Family: 6

Model:  15

Mask:   6

Type:   Intel CORE2

CpuFreq info:

  CPU 0: driver = centrino, governor = powersave

  CPU 1: driver = centrino, governor = powersave

MSR registers:

  CPU 0: PERF_CTL=<failed>, PERF_STATUS=<failed>, FSB_FREQ=<failed>

  CPU 1: PERF_CTL=0x0000000000000613, PERF_STATUS=0x06130c2806000613, FSB_FREQ=0x0000000000000933

        |     CPU 0     |     CPU 1     |

        +-------+-------+-------+-------+

        | FID   | VID   | FID   | VID   |

--------+-------+-------+-------+-------+

Min     | -     | -     | 6     | 19    |

Max     | -     | -     | 12    | 40    |

--------+-------+-------+-------+-------+

Target  | -     | -     | 6     | 19    |

Current | -     | -     | 6     | 19    |

--------+-------+-------+-------+-------+

Frequency estimations based on TSC:

  CPU 0: core = 1994.99 MHz, bus =  failed

  CPU 1: core = 1994.93 MHz, bus = 332.489 MHz

Frequency estimations based on BogoMIPS from /proc/cpuinfo:

  CPU 0: core =  failed, bus =  failed, bogomips = 3995.79

  CPU 1: core = 1995.08 MHz, bus = 332.513 MHz, bogomips = 3990.16

Frequency estimations based on measured BogoMIPS:

  CPU 0: core = 1995.01 MHz, bus =  failed

  CPU 1: core = 997.924 MHz, bus = 166.321 MHz, bogoratio = 1.9992

Frequency estimations based on the FSB_FREQ MSR register:

  CPU 0: core =  failed, bus =  failed

  CPU 1: core = 1000.02 MHz, bus = 166.67 MHz

```

Please ask for any info you may need!

Bye

Piero

[1]https://www.dedigentoo.org/trac/linux-phc/

----------

## dgaffuri

 *bdz wrote:*   

> And there is another upcoming feature of the Linux kernel that will change a lot of things regarding undervolting: "merge acpi functionality of cpufreq drivers". This feature will remove the ACPI support from the speedstep-centrino driver and merge it into the acpi-cpufreq driver....
> 
> Another solution would be to add the undervolting code in the acpi-cpufreq driver. 
> 
> But I will not be able to implement myself any of these solutions in the near future.

 

Hi bdz

I've ported a slightly changed old version of your patch to acpi-cpufreq in 2.6.20-rc1, I hope taht this may help you and other users a little. Note that ACPI in speedstep-centrino is deprecated but not yet removed in 2.6.20.

The name of the sysfs entry have been changed to

```
/sys/devices/system/cpu/cpu0/cpufreq/cpufreq_freq_voltages
```

 Be aware that this patch is only tested on my 755 CPU and doesn't include any check on the processor type or even the fact that MSR instead of registers I/O is used to switch frequencies, so use at your own risk and only if you really know what you're doing. In other words, don't blame me if you burn your CPU.

Edit: The patch misses a change to correctly check current frequency when voltage is different from default, I will resubmit as soon as I fix it

```
--- arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c.save    2006-12-23 14:52:45.000000000 +0100

+++ arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-12-24 13:22:28.000000000 +0100

@@ -69,6 +69,7 @@ struct acpi_cpufreq_data {

 static struct acpi_cpufreq_data *drv_data[NR_CPUS];

 static struct acpi_processor_performance *acpi_perf_data[NR_CPUS];

+static acpi_integer *original_acpi_data_control[NR_CPUS];

 static struct cpufreq_driver acpi_cpufreq_driver;

@@ -684,7 +685,7 @@ static int acpi_cpufreq_cpu_init(struct

        data->max_freq = perf->states[0].core_frequency * 1000;

        /* table init */

        for (i=0; i<perf->state_count; i++) {

-               if (i>0 && perf->states[i].core_frequency ==

+               if (i>0 && perf->states[i].core_frequency >=

                    perf->states[i-1].core_frequency)

                        continue;

@@ -764,6 +765,8 @@ static int acpi_cpufreq_cpu_exit(struct

                acpi_processor_unregister_performance(data->acpi_data,

                                                      policy->cpu);

                kfree(data);

+               kfree(original_acpi_data_control[policy->cpu]);

+               original_acpi_data_control[policy->cpu] = NULL;

        }

        return 0;

@@ -780,8 +783,116 @@ static int acpi_cpufreq_resume(struct cp

        return 0;

 }

+static ssize_t show_freq_voltages(struct cpufreq_policy *policy, char *buf)

+{

+       struct acpi_cpufreq_data *data = drv_data[policy->cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i;

+       unsigned int voltage;

+       ssize_t count = 0;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+       /* show space separated list of current voltages */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = perf->states[data->freq_table[i].index].control & INTEL_MSR_RANGE;

+               voltage = 700 + ((voltage & 0xFF) << 4);

+               count += sprintf(&buf[count], "%u ", voltage);

+       }

+       count += sprintf(&buf[count], "\n");

+

+       return count;

+}

+

+static ssize_t store_freq_voltages(struct cpufreq_policy *policy, const char *buf, size_t count)

+{

+       unsigned int cpu = policy->cpu;

+       struct acpi_cpufreq_data *data = drv_data[cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i, j;

+       unsigned int voltage;

+       unsigned int voltage_index;

+       const char *curr_buf = buf;

+       char *next_buf;

+       acpi_integer control;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+

+       /* save original control values to disallow overvolting */

+       if (!original_acpi_data_control[cpu]) {

+               original_acpi_data_control[cpu] = kmalloc(sizeof(acpi_integer) *

+                                       perf->state_count, GFP_KERNEL);

+               if (!original_acpi_data_control[cpu]) {

+                       dprintk("failed to allocate memory for old control values\n");

+                       return -ENOMEM;

+               }

+               for (i = 0; i < perf->state_count; i++)

+                       original_acpi_data_control[cpu][i] = perf->states[i].control;

+       }

+

+       /* set new voltages from user space */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = simple_strtoul(curr_buf, &next_buf, 10);

+               if (next_buf == curr_buf) {

+                       if ((curr_buf - buf == count - 1) && (*curr_buf == '\n')) {

+                               curr_buf++;

+                               break;

+                       }

+                       dprintk("failed to parse voltage value at %i (%s)\n", i, curr_buf);

+                       return -EINVAL;

+               }

+               if (voltage < 700) {

+                       dprintk("skipping voltage at %i, "

+                               "%u is below the minimum of 700 mV\n", i, voltage);

+               } else {

+                       voltage_index = ((voltage - 700) >> 4) & 0xFF;

+                       j = data->freq_table[i].index;

+                       if (voltage_index <= (original_acpi_data_control[cpu][j] & 0xFF)) {

+                               control = (original_acpi_data_control[cpu][j] & 0xFFFFFF00) | voltage_index;

+                               dprintk("setting control %x at %i, default is %x\n",

+                                       (unsigned int) control, i,

+                                       (unsigned int) original_acpi_data_control[cpu][j]);

+                               perf->states[j].control = control;

+                       } else {

+                               dprintk("skipping voltage at %i, "

+                                       "%u is greater than the default %u\n",

+                                       i, voltage,

+                                       700 + ((original_acpi_data_control[cpu][j] & 0xFF) << 4));

+                       }

+               }

+               curr_buf = next_buf;

+               while ((curr_buf - buf < count) && (*curr_buf == ' '))

+                       curr_buf++;

+       }

+

+       /* set new voltage at current frequency */

+       data->resume = 1;

+       acpi_cpufreq_target(policy, get_cur_freq_on_cpu(cpu), CPUFREQ_RELATION_L);

+

+       return curr_buf - buf;

+}

+

+static struct freq_attr cpufreq_freq_attr_freq_voltages =

+{

+       .attr = { .name = "cpufreq_freq_voltages", .mode = 0644, .owner = THIS_MODULE },

+       .show = show_freq_voltages,

+       .store = store_freq_voltages,

+};

+

 static struct freq_attr *acpi_cpufreq_attr[] = {

        &cpufreq_freq_attr_scaling_available_freqs,

+       &cpufreq_freq_attr_freq_voltages,

        NULL,

 };

@@ -815,6 +926,8 @@ static void __exit acpi_cpufreq_exit(voi

        for_each_possible_cpu(i) {

                kfree(acpi_perf_data[i]);

                acpi_perf_data[i] = NULL;

+               kfree(original_acpi_data_control[i]);

+               original_acpi_data_control[i] = NULL;

        }

        return;

 }

```

----------

## dgaffuri

 *dgaffuri wrote:*   

> Edit: The patch misses a change to correctly check current frequency when voltage is different from default, I will resubmit as soon as I fix it

 

This one seems to work better, against 2.6.20-rc2. Note also that, unlike in the PHC patch, sysfs node accepts a space separated list of voltages, corresponding to available frequencies.

```
--- linux/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c.orig      2006-12-24 18:13:17.000000000 +0100

+++ linux/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c   2006-12-25 17:57:29.000000000 +0100

@@ -57,6 +57,8 @@ enum {

 };

 #define INTEL_MSR_RANGE                (0xffff)

+#define INTEL_MSR_FREQUENCY    (0xff00)

+#define INTEL_MSR_VOLTAGE      (0x00ff)

 #define CPUID_6_ECX_APERFMPERF_CAPABILITY      (0x1)

 struct acpi_cpufreq_data {

@@ -69,6 +71,7 @@ struct acpi_cpufreq_data {

 static struct acpi_cpufreq_data *drv_data[NR_CPUS];

 static struct acpi_processor_performance *acpi_perf_data[NR_CPUS];

+static acpi_integer *original_acpi_data_control[NR_CPUS];

 static struct cpufreq_driver acpi_cpufreq_driver;

@@ -104,11 +107,12 @@ static unsigned extract_msr(u32 msr, str

        int i;

        struct acpi_processor_performance *perf;

-       msr &= INTEL_MSR_RANGE;

+       msr &= INTEL_MSR_FREQUENCY;

        perf = data->acpi_data;

        for (i=0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

-               if (msr == perf->states[data->freq_table[i].index].status)

+               if (msr == (perf->states[data->freq_table[i].index].status &

+                   INTEL_MSR_FREQUENCY))

                        return data->freq_table[i].frequency;

        }

        return data->freq_table[0].frequency;

@@ -667,7 +671,7 @@ static int acpi_cpufreq_cpu_init(struct

        data->max_freq = perf->states[0].core_frequency * 1000;

        /* table init */

        for (i=0; i<perf->state_count; i++) {

-               if (i>0 && perf->states[i].core_frequency ==

+               if (i>0 && perf->states[i].core_frequency >=

                    perf->states[i-1].core_frequency)

                        continue;

@@ -747,6 +751,8 @@ static int acpi_cpufreq_cpu_exit(struct

                acpi_processor_unregister_performance(data->acpi_data,

                                                      policy->cpu);

                kfree(data);

+               kfree(original_acpi_data_control[policy->cpu]);

+               original_acpi_data_control[policy->cpu] = NULL;

        }

        return 0;

@@ -763,8 +769,119 @@ static int acpi_cpufreq_resume(struct cp

        return 0;

 }

+static ssize_t show_freq_voltages(struct cpufreq_policy *policy, char *buf)

+{

+       struct acpi_cpufreq_data *data = drv_data[policy->cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i;

+       unsigned int voltage;

+       ssize_t count = 0;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+       /* show space separated list of current voltages */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = perf->states[data->freq_table[i].index].control;

+               voltage = 700 + ((voltage & INTEL_MSR_VOLTAGE) << 4);

+               count += sprintf(&buf[count], "%u ", voltage);

+       }

+       count += sprintf(&buf[count], "\n");

+

+       return count;

+}

+

+static ssize_t store_freq_voltages(struct cpufreq_policy *policy, const char *buf, size_t count)

+{

+       unsigned int cpu = policy->cpu;

+       struct acpi_cpufreq_data *data = drv_data[cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i, j;

+       unsigned int voltage;

+       unsigned int voltage_index, original_index;

+       const char *curr_buf = buf;

+       char *next_buf;

+       acpi_integer control;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+

+       /* save original control values to disallow overvolting */

+       if (!original_acpi_data_control[cpu]) {

+               original_acpi_data_control[cpu] = kmalloc(sizeof(acpi_integer) *

+                   perf->state_count, GFP_KERNEL);

+               if (!original_acpi_data_control[cpu]) {

+                       dprintk("failed to allocate memory for old control values\n");

+                       return -ENOMEM;

+               }

+               for (i = 0; i < perf->state_count; i++)

+                       original_acpi_data_control[cpu][i] = perf->states[i].control;

+       }

+

+       /* set new voltages from user space */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = simple_strtoul(curr_buf, &next_buf, 10);

+               if (next_buf == curr_buf) {

+                       if ((curr_buf - buf == count - 1) && (*curr_buf == '\n')) {

+                               curr_buf++;

+                               break;

+                       }

+                       dprintk("failed to parse voltage value at %i (%s)\n", i, curr_buf);

+                       return -EINVAL;

+               }

+               if (voltage < 700) {

+                       dprintk("skipping voltage at %i, "

+                               "%u is below the minimum of 700 mV\n", i, voltage);

+               } else {

+                       voltage_index = ((voltage - 700) >> 4) & INTEL_MSR_VOLTAGE;

+                       j = data->freq_table[i].index;

+                       original_index = original_acpi_data_control[cpu][j] &

+                           INTEL_MSR_VOLTAGE;

+                       if (voltage_index <= original_index) {

+                               control = (original_acpi_data_control[cpu][j] &

+                                   INTEL_MSR_FREQUENCY) | voltage_index;

+                               dprintk("setting control %x at %i, default is %x\n",

+                                       (unsigned int) control, i,

+                                       (unsigned int) original_acpi_data_control[cpu][j]);

+                               perf->states[j].control = control;

+                       } else {

+                               dprintk("skipping voltage at %i, "

+                                       "%u is greater than the default %u\n",

+                                       i, voltage,

+                                       700 + (original_index << 4));

+                       }

+               }

+               curr_buf = next_buf;

+               while ((curr_buf - buf < count) && (*curr_buf == ' '))

+                       curr_buf++;

+       }

+

+       /* set new voltage at current frequency */

+       data->resume = 1;

+       acpi_cpufreq_target(policy, get_cur_freq_on_cpu(cpu), CPUFREQ_RELATION_L);

+

+       return curr_buf - buf;

+}

+

+static struct freq_attr cpufreq_freq_attr_freq_voltages =

+{

+       .attr = { .name = "cpufreq_freq_voltages", .mode = 0644, .owner = THIS_MODULE },

+       .show = show_freq_voltages,

+       .store = store_freq_voltages,

+};

+

 static struct freq_attr *acpi_cpufreq_attr[] = {

        &cpufreq_freq_attr_scaling_available_freqs,

+       &cpufreq_freq_attr_freq_voltages,

        NULL,

 };

@@ -798,6 +915,8 @@ static void __exit acpi_cpufreq_exit(voi

        for_each_possible_cpu(i) {

                kfree(acpi_perf_data[i]);

                acpi_perf_data[i] = NULL;

+               kfree(original_acpi_data_control[i]);

+               original_acpi_data_control[i] = NULL;

        }

        return;

 }

```

----------

## Schmolch

Hey Guys,

i want to try this out, i got the sunrise-overlay and tried to emerge linux-phc with 3 different sources (gentoo, git, vanilla) but i always get this error:

```
make[2]: Entering directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'

if i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I..     -O2 -march=prescott -pipe -fomit-frame-pointer -MT measurefreq.o -MD -MP -MF ".deps/measurefreq.Tpo" -c -o measurefreq.o measurefreq.cpp; \

        then mv -f ".deps/measurefreq.Tpo" ".deps/measurefreq.Po"; else rm -f ".deps/measurefreq.Tpo"; exit 1; fi

measurefreq.cpp:28:21: Fehler: asm/msr.h: Datei oder Verzeichnis nicht gefunden

measurefreq.cpp: In function »void MeasureFreq(arguments)«:

measurefreq.cpp:196: Fehler: »rdtsc« wurde in diesem Gültigkeitsbereich nicht definiert

make[2]: *** [measurefreq.o] Fehler 1

make[2]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'

make[1]: *** [all-recursive] Fehler 1

make[1]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq'

make: *** [all] Fehler 2

!!! ERROR: app-laptop/linux-phc-0.2.8 failed.

Call stack:

  ebuild.sh, line 1613:   Called dyn_compile

  ebuild.sh, line 970:   Called qa_call 'src_compile'

  environment, line 4151:   Called src_compile

  linux-phc-0.2.8.ebuild, line 82:   Called die

!!! emake failed

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/app-laptop/linux-phc-0.2.8/temp/build.log'.

```

Its a fresh Gentoo ~x86 install on a new Laptop (Lenovo X60T).

Sorry if this issue has been discussed a few pages earlier, if not, i never exposed my laziness  :Wink: 

----------

## Gentree

Oh phc!    :Laughing: 

----------

## rmh3093

 *Schmolch wrote:*   

> Hey Guys,
> 
> i want to try this out, i got the sunrise-overlay and tried to emerge linux-phc with 3 different sources (gentoo, git, vanilla) but i always get this error:
> 
> ```
> ...

 

Try this:

```
ebuild /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.20.ebuild compile

cp /var/tmp/portage/sys-kernel/linux-headers-2.6.20/work/gentoo-headers-base-2.6.20/include/asm-i386/msr.h /usr/include/asm/
```

----------

## Robot_s

 *Entropy42 wrote:*   

> FYI, with a few caveats, linux-pch also works on Yonah (Core Duo) chips.
> 
> Most of the caveats are root problems with cpufreq itself - it does NOT handle Core Duo chips well at all.  It detects that the two cores are on the same chip (see the affected_cpus value) but still presents independent controls for each CPU.  This is WRONG!  All frequency/voltage settings are locked for the entire chip (both cores), so having independent settings in cpufreq is nonsensical and often provides inconsistent results.
> 
> 

 

I've read the datasheet  for the Core Duo cpus. It is perfectly correct to set two different frequencies, as the processor chooses the highest one.

Anyways, could someone provide me with some default values for Intel Core Duo T2300? My bios is kinda buggy (since i have reflashed it) and i would like to patch the kernel with some "normal values"  :Smile: 

----------

## b3nbranch

 *heilong wrote:*   

> I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:
> 
> "2000000:1404,1667000:1276,1333000:1148,1000000:1004"
> 
> A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,
> ...

 

I'm a little confused. Did you have to add a table to speedstep-centrino.c for your T2400,

or did it pick up defaults from somewhere? I would very much like to undervolt my T7400,

and have taken several of the first steps to use PHC, but don't quite understand what you did

to get this far with a processor that's not directly supported by the patch.

Thanks!

Ben

----------

## rafelbev

I have come across this patch implementing an interesting cpu idle infrastructure. This is being proposed by guys from Intel and should be generic enough for most modern processors. Following some patches on the LKML I believe its first presense inside the git tree is inside the test branch of the acpi git tree. I tried merging it quickly but didn't manage to patch it up well.

It also appears that in current 2.6.21 kernels, most of the speed step stuff has gone out from the speedstep-centrino driver and into acpi-cpufreq driver. I am guessing that the code is now more generic and reusable across the board too. With the latest 2.6.21 and DYNTICKS enabled I managed to scrape another Watt down to 18W. This is still far away from the 11W when booted in Windows

----------

## b3nbranch

I'm still running 2.6.17-11, it sounds like things are advancing on the

power management front in the official kernels, if slowly.

I added a table for my t7400 to the patched speedstep-centrino.c, and

it's working. I'm now fine tuning the voltages. Perhaps this will all get

tossed when I upgrade to 2.6.20 or 2.6.21, but it's been interesting!

----------

## rafelbev

Did you manage to get a noticable difference in battery life? Do you have a measurement in watts on the different typical power consumption?

----------

## b3nbranch

 *rafelbev wrote:*   

> Did you manage to get a noticable difference in battery life? Do you have a measurement in watts on the different typical power consumption?

 

I'm running an MOTD (Mobile on the Desktop) rig, so no battery. The T7400, just like the

earlier poster's Yonah, seems to be locked at 0.95v@1GHz for the minimum setting, so

no change at idle (56 watts measured by a kill-a-watt meter at the AC outlet). However,

running the Mersenne prime (mprime) torture test at 2.17GHz, the system's power draw

dropped from 98w to 85w, with the CPU running at about 1.02v rather than 1.21v.

The torture test faults quickly at 1.00v; it ran for 3 hours with no problem at 1.01v, and

I'm sticking with 1.02v for a bit of safety margin.

----------

## Whoopie

Hi,

why does acpi-cpufreq report other default values then speedstep-centrino?

speedstep-centrino:

798000 -> 988

1064000 -> 1084

1330000 -> 1180

1596000 -> 1276

1862000 -> 1356

acpi-cpufreq:

800000 -> 988

1066000 -> 1068

1333000 -> 1148

1600000 -> 1228

1866000 -> 1308

Thanks for helping.

Best regards,

WhoopieLast edited by Whoopie on Sun May 13, 2007 2:21 pm; edited 1 time in total

----------

## b3nbranch

 *Whoopie wrote:*   

> Hi,
> 
> why does acpi-cpufreq report other default values then speedstep-centrino?
> 
> <snip tables>
> ...

 

I haven't completely researched this, but I believe that acpi-cpufreq obtains

tables from the BIOS of the computer, whereas speedstep-centrino uses

compiled-in tables. In fact, I was able to change my frequency steps from

1.0 - 1.33 - 1.67 - 2.17 to 1.0 - 1.5 - 1.83 - 2.17 by editing the appropriate

table in speedstep-centrino.

So the probably cause of the difference is that two difference data sources

are being used.

Hope this helps,

Ben

----------

## Whoopie

Hi Ben,

thanks for your answer. It sounds logical. 

Just saw that acpi-cpufreq also reports different frequencies:

```

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 

1866000 1600000 1333000 1066000 800000 

```

Best regards,

Whoopie

----------

## widan

 *rafelbev wrote:*   

> Do you have a measurement in watts on the different typical power consumption?

 

The ratio of power usages of the CPU only between undervolted and stock should roughly be equal to the square of the ratio of core voltages.

 *b3nbranch wrote:*   

> no change at idle (56 watts measured by a kill-a-watt meter at the AC outlet) ... the system's power draw dropped from 98w to 85w, with the CPU running at about 1.02v rather than 1.21v.

 

If we assume all the power usage at idle is due to other things than the CPU (not true, the CPU still uses some power at idle, but it's hard to quantify from "wall outlet" measurements), the CPU part of the power usage dropped from 98-56=42 W to 85-56=29 W. Power ratio is 29/42=0.69, and square of voltage ratio is (1.02/1.21)^2=0.71. That's reasonably close to the theory.

----------

## info2

Hey,

i have ported dgaffuri's patch to kernel 2.6.22 (ubuntu feisty with gutsy kernel), compiled the acpi_cpufreq.ko and insmod'ed it.

Now i can read the CPU's Voltages:

>>1324 1228 1116 1004

Then i changed the last two values to   1000 and 800, the Patch seems to correct them  :Wink: , now i have:

>>1324 1228 988 796 

I switched the Frequencies around hoping that the kernel will set the new values,

but it seems not to affect something. 

The system is as hot as ever even when it is doing (nearly) nothing.

>>Thermal 1: ok, 53.0 degrees C

How can i make sure the system set the Voltages? What could be the problem?

CPU-Info:

Vendor: 0

Family: 6

Model:  15

Mask:   6

Type:   Intel CORE2

T7200

Here the Patch-File for 2.6.22:

```
--- acpi-cpufreq_orig.c   2007-05-13 20:55:48.000000000 +0200

+++ acpi-cpufreq.c   2007-05-21 15:30:01.000000000 +0200

@@ -57,6 +57,8 @@

 };

 

 #define INTEL_MSR_RANGE      (0xffff)

+#define INTEL_MSR_FREQUENCY    (0xff00)

+#define INTEL_MSR_VOLTAGE      (0x00ff)

 #define CPUID_6_ECX_APERFMPERF_CAPABILITY   (0x1)

 

 struct acpi_cpufreq_data {

@@ -69,6 +71,7 @@

 

 static struct acpi_cpufreq_data *drv_data[NR_CPUS];

 static struct acpi_processor_performance *acpi_perf_data[NR_CPUS];

+static acpi_integer *original_acpi_data_control[NR_CPUS];

 

 static struct cpufreq_driver acpi_cpufreq_driver;

 

@@ -104,11 +107,11 @@

    int i;

    struct acpi_processor_performance *perf;

 

-   msr &= INTEL_MSR_RANGE;

+   msr &= INTEL_MSR_FREQUENCY;

    perf = data->acpi_data;

 

    for (i=0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

-      if (msr == perf->states[data->freq_table[i].index].status)

+      if (msr == (perf->states[data->freq_table[i].index].status & INTEL_MSR_FREQUENCY))

          return data->freq_table[i].frequency;

    }

    return data->freq_table[0].frequency;

@@ -668,7 +671,7 @@

    data->max_freq = perf->states[0].core_frequency * 1000;

    /* table init */

    for (i=0; i<perf->state_count; i++) {

-      if (i>0 && perf->states[i].core_frequency ==

+      if (i>0 && perf->states[i].core_frequency >=

           perf->states[i-1].core_frequency)

          continue;

 

@@ -749,6 +752,8 @@

       acpi_processor_unregister_performance(data->acpi_data,

                         policy->cpu);

       kfree(data);

+                kfree(original_acpi_data_control[policy->cpu]);

+                original_acpi_data_control[policy->cpu] = NULL;

    }

 

    return 0;

@@ -765,8 +770,119 @@

    return 0;

 }

 

+static ssize_t show_freq_voltages(struct cpufreq_policy *policy, char *buf)

+{

+       struct acpi_cpufreq_data *data = drv_data[policy->cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i;

+       unsigned int voltage;

+       ssize_t count = 0;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+       /* show space separated list of current voltages */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = perf->states[data->freq_table[i].index].control;

+               voltage = 700 + ((voltage & INTEL_MSR_VOLTAGE) << 4);

+               count += sprintf(&buf[count], "%u ", voltage);

+       }

+       count += sprintf(&buf[count], "\n");

+

+       return count;

+}

+

+static ssize_t store_freq_voltages(struct cpufreq_policy *policy, const char *buf, size_t count)

+{

+       unsigned int cpu = policy->cpu;

+       struct acpi_cpufreq_data *data = drv_data[cpu];

+       struct acpi_processor_performance *perf;

+       unsigned int i, j;

+       unsigned int voltage;

+       unsigned int voltage_index, original_index;

+       const char *curr_buf = buf;

+       char *next_buf;

+       acpi_integer control;

+

+       if (unlikely(data == NULL ||

+            data->acpi_data == NULL || data->freq_table == NULL)) {

+               return -ENODEV;

+       }

+

+       perf = data->acpi_data;

+

+

+       /* save original control values to disallow overvolting */

+       if (!original_acpi_data_control[cpu]) {

+               original_acpi_data_control[cpu] = kmalloc(sizeof(acpi_integer) *

+                   perf->state_count, GFP_KERNEL);

+               if (!original_acpi_data_control[cpu]) {

+                       dprintk("failed to allocate memory for old control values\n");

+                       return -ENOMEM;

+               }

+               for (i = 0; i < perf->state_count; i++)

+                       original_acpi_data_control[cpu][i] = perf->states[i].control;

+       }

+

+       /* set new voltages from user space */

+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {

+               voltage = simple_strtoul(curr_buf, &next_buf, 10);

+               if (next_buf == curr_buf) {

+                       if ((curr_buf - buf == count - 1) && (*curr_buf == '\n')) {

+                               curr_buf++;

+                               break;

+                       }

+                       dprintk("failed to parse voltage value at %i (%s)\n", i, curr_buf);

+                       return -EINVAL;

+               }

+               if (voltage < 700) {

+                       dprintk("skipping voltage at %i, "

+                               "%u is below the minimum of 700 mV\n", i, voltage);

+               } else {

+                       voltage_index = ((voltage - 700) >> 4) & INTEL_MSR_VOLTAGE;

+                       j = data->freq_table[i].index;

+                       original_index = original_acpi_data_control[cpu][j] &

+                           INTEL_MSR_VOLTAGE;

+                       if (voltage_index <= original_index) {

+                               control = (original_acpi_data_control[cpu][j] &

+                                   INTEL_MSR_FREQUENCY) | voltage_index;

+                               dprintk("setting control %x at %i, default is %x\n",

+                                       (unsigned int) control, i,

+                                       (unsigned int) original_acpi_data_control[cpu][j]);

+                               perf->states[j].control = control;

+                       } else {

+                               dprintk("skipping voltage at %i, "

+                                       "%u is greater than the default %u\n",

+                                       i, voltage,

+                                       700 + (original_index << 4));

+                       }

+               }

+               curr_buf = next_buf;

+               while ((curr_buf - buf < count) && (*curr_buf == ' '))

+                       curr_buf++;

+       }

+

+       /* set new voltage at current frequency */

+       data->resume = 1;

+       acpi_cpufreq_target(policy, get_cur_freq_on_cpu(cpu), CPUFREQ_RELATION_L);

+

+       return curr_buf - buf;

+}

+

+static struct freq_attr cpufreq_freq_attr_freq_voltages =

+{

+       .attr = { .name = "cpufreq_freq_voltages", .mode = 0644, .owner = THIS_MODULE },

+       .show = show_freq_voltages,

+       .store = store_freq_voltages,

+};

+

 static struct freq_attr *acpi_cpufreq_attr[] = {

    &cpufreq_freq_attr_scaling_available_freqs,

+   &cpufreq_freq_attr_freq_voltages,

    NULL,

 };

 

@@ -800,6 +916,8 @@

    for_each_possible_cpu(i) {

       kfree(acpi_perf_data[i]);

       acpi_perf_data[i] = NULL;

+      kfree(original_acpi_data_control[i]);

+               original_acpi_data_control[i] = NULL;

    }

    return;

 }
```

----------

## info2

It seems that the CPU just don't set the new voltages.

checking msrinfo after setting new values shows up new target voltages but they are not reached.

I have no windows on my system (   :Very Happy:   -> i'm free), but maybe somebody of you have. Could somebody please check if he/she is able to set lower voltages for a Core2 Duo in windows, for example by using " NHC - Notebook Hardware Control " ?

Thank you.

[Update1] :

I asked a friend that owns a T5500 to try NHC and he is able tu set a Voltage of 0.95 @ 1Ghz.

Googling around i found a DataSheed by Intel that says that you can lower the Voltage at lowest speed to 0.750Vcc.

http://developer.intel.com/design/mobile/datashts/314078.htm

Would be really "hot" if somebody can manage the patch to work. I would be in love with the world  if i can make me new Laptop cooler.

----------

## brian33x51

Back to the ORIGINAL question....

Any new utilities to screw with the VRM directly on the fly to change voltages?

I've got this MSI K7D Master-L with 2 thoroughbred athlonmps (well modded xps) which I'm currently running undervolted to 1.45V in the bios.

Normal spec voltage for the cpus (version 681) is 1.6V.  My seem to stay ~3C less than before both unloaded and loaded.

I'd like to do some testing without rebooting to see if 1.5V might be cooler, ie if the VRM is overloading from having to supply too many amps.

----------

## Whoopie

Hi,

there's also https://www.dedigentoo.org/bdz/linux-phc/linux-phc-0.3.0-pre1.tar.gz which adds undervolting support to acpi-cpufreq.

Best regards,

Whoopie

----------

## ph03

 *Whoopie wrote:*   

> Hi,
> 
> there's also https://www.dedigentoo.org/bdz/linux-phc/linux-phc-0.3.0-pre1.tar.gz which adds undervolting support to acpi-cpufreq.
> 
> Best regards,
> ...

 

Would I be able to undervolt AMD Athlon 64 Mobile CPUs using this patched acpi-cpufreq driver?

Regards, ph03

----------

## jorrit

 *pilla wrote:*   

>  *albright wrote:*    *Quote:*   
> 
> AFAIK, cpufreq does both voltage and clock scaling (together) 
> 
>  
> ...

 

It can be done. I'm doing it because otherwise my AMD would heat up too quickly. The trick is finding out (by experimenting) how low you can go with the voltage without getting an unstable system. I was able to go from 1.45V to about 1.35V with 1800MHz.

Greetings,

----------

## info2

Hey!

Linux-PHC-0.3 is available now.

You can get it on SF:

http://sourceforge.net/projects/linux-phc/

i'll be also available in the svn on dedigentoo soon.

In this release, all patches are against acpi-cpufreq. The Interface hase changed since 0.2x and now is showing the Voltage ID's (VIDs) instead of voltages.

This Patch has been tested with Pentium-M and Core/Core2 -CPUs. Patches are available for kernel 2.6.20 - 2.6.23. If wished lower versions will be made. 

There are some more changes. Take a look at the projects homepage to get them all.

We need more developers and we wish more users that'll give us feedback about averything.  :Smile: 

Thank you - and keep cool.

----------

## Walldorf2000

I desparetely wait for release 0.4.0 https://www.dedigentoo.org/trac/linux-phc/  :Wink: 

 *Quote:*   

> 0.4.0 - <Released date not defined yet>: Major release ¶
> 
>  * Add support for the powernow-k8 driver (AMD Athlon 64 and Opteron CPUs)

 

----------

## albright

anybody know how you modify /etc/conf.d/undervolt and

/etc/init.d/undervolt for the new linux-phc (.3)

the patch worked fine on suspend2-2.6.22-r1 sources, and

I have the new files in /sys .... /cpufreq but I note that

/etc/conf.d/undervolt points to the wrong file now and

/etc/init.d/undervolt won't start (unsurprisingly).

What are the magic words?

TIA

----------

## albright

sorry to add this - I should have put it in my last post:

What is the relation between the VIDS and actual

voltages. With the old linux-phc my chip used these

voltages:

```
CUSTOM_VTABLE="1100000:828,1000000:812,900000:780,800000:748,600000:700"
```

I wonder what VID number corresponds to 8.28v etc?

----------

## Ehnvis

For Pentium-M: VID = (voltage - 700)/16

For Athlon 64, Turion, Opteron: VID = (1550 - voltage) / 25

voltage in the formulas above has to be in millivolts (ie 828 in your case for the first one).

----------

## albright

thanks ehnvis; it seems to be working. I note that the lowest

possible voltage (700mv) works out to a VID of 0. I guess that's

ok ....

----------

## just-linux

Is there an ebuild for linux-phc-0.3.0 allready available? I've tried to find one, but to no avail.

----------

## Ehnvis

There is no ebuild for linux-phc you need to grab it from here, https://www.dedigentoo.org/trac/linux-phc/ , and then patch your kernel with it. Not sure if there exists any kernel in portage that already has this patch on it which might be another idea.

----------

## just-linux

I tried to make one, but unfortunately i failed  :Very Happy:  It would have been my first ebuild  :Very Happy:  Anyway, I have now an already patched kernel and everything works fine ( 2.6.22-kamikaze7)

I had a look at the new package and I wonder why there is still the old undervolt config file and the old undervolt init script in the new 0.3.0 version.

And something else, my old undervolt config file looks like:

```

# Default voltages that will be restored at shutdown if SWITCH_BACK=yes

DEFAULT_VTABLE="798000:988,1064000:1116,1330000:1244,1596000:1356"

# Custom voltages that will be applied at boot time

CUSTOM_VTABLE="2000000:1164,1600000:956,1333000:876,1066000:796,800000:700"

```

If i take the formula "VID = (voltage - 700)/16" I would get the 5 VIDs "29 16 11 6 0". But I can't go lower than 18. Why can't I use the voltage 700 (VID 0) as I could before?

```
tobi linux # msrinfo

Detected 1 CPU

Vendor: 0

Family: 6

Model:  13

Mask:   8

Type:   Intel Pentium M Dothan C0

CpuFreq info:

  CPU 0: driver = acpi-cpufreq, governor = conservative

MSR registers:

  CPU 0: PERF_CTL=0x0000000000000612, PERF_STATUS=0x06120f2906000612, FSB_FREQ=0x0000000000000311

        |     CPU 0     |     CPU 1     |

        +-------+-------+-------+-------+

        | FID   | VID   | FID   | VID   |

--------+-------+-------+-------+-------+

Min     | 6     | 18    | -     | -     |

Max     | 15    | 41    | -     | -     |

--------+-------+-------+-------+-------+

Target  | 6     | 18    | -     | -     |

Current | 6     | 18    | -     | -     |

--------+-------+-------+-------+-------+

```

@bdz

Thanks a lot for your small utility! It just works great!  :Very Happy: 

----------

## info2

Hello,

just-linux, you wondered why there is the old init script? I wonder why you have this old init script. In the final release the gentoo-script is hybrid to take use of the linux-PHC-0.2x interface and the linux-PHC-0.3.0 interface.

Please notice that the release is not in CVS yet but available on sourceforge (mea culpa).

The final release also offers pre-compiled modules for users that don't want to compile the module or the whole kernel.

Take a look at the release notes.

The issue that you can not set a lower vid than 18 sounds not logically to m but i'm interested in what could be the reason.

Other people reported that they could successfully set a VID of 0. Maybe there are other things preventing your system from that? I don't know. Maybe it's because your BIOS is broken. Linux-PHC-0.2x used build-in tables. Linux-PHC-0.3 does not due technically reasons (acpi-cpufreq). There is a new kernel module in developement (named "PHC-EST" initiated by BDZ) that will fix this, but i don't know when it'll be ready. 

If somebody of you is interested in helping with the developement of this module - you're welcome.

A look in the future: I found a person that offered us developing a patch for AMD-CPUs, but it'll take some month he said. Stay tuned.

Also the userspace-tool PHCtool is going on in developement. In the upcoming version (0.5) it'll (among many other newfeatures) show voltages next to the VIDs if the cpu (and the matching formula) is known.

If you have questions, you are welcome to meet us in the IRC-Chat. I'm there very often (cmichael), but maybe you need to wait some time until i notice you  :Wink: 

I hope i could answear some questions. 

see you

----------

## info2

Some users reported me an error that occurs  if they want to read from the interface files. 

They get an "No such device".

I tracked town the problem to the point acpi-cpufreq decides either the system is "SYSTEM_IO_CAPABLE" or "SYSTEM_INTEL_MSR_CAPABLE".

```

   switch (perf->control_register.space_id) {

   case ACPI_ADR_SPACE_SYSTEM_IO:

      dprintk("SYSTEM IO addr space\n");

      data->cpu_feature = SYSTEM_IO_CAPABLE;

      break;

   case ACPI_ADR_SPACE_FIXED_HARDWARE:

      dprintk("HARDWARE addr space\n");

      if (!check_est_cpu(cpu)) {

         result = -ENODEV;

         goto err_unreg;

      }

      data->cpu_feature = SYSTEM_INTEL_MSR_CAPABLE;

      break;

   default:

      dprintk("Unknown addr space %d\n",

         (u32) (perf->control_register.space_id));

      result = -ENODEV;

      goto err_unreg;

   }

```

The system of those people that decides to have "SYSTEM_IO_CABALE" while the PHC code check if it's "SYSTEM_INTEL_MSR_CAPABLE".

I think this is caused by broken ACPI BIOS informations.

I'm not sure if this check just can be removed. What do you think?

If this check is neccessary for some reasons, what could be the best way to give ppl with that problem a solution?

Maybe another SysFS file for example, where you can disable this check manually by writing a "1" into it?

I hope you can help since i'm not sure how to solve this at best.

Edit:

  just forcing SYSTEM_INTEL_MSR_CAPABLE seems not to work for the user that currently is testing this.

Regards

cmichael

----------

## Schmolch

What are everybody's experiences with undervolting their CPU?

I can't see any difference on my lv core-duo-Laptop regarding heat or battery-life.

l don't see any drop in power-consumption with powertop. 

How much does a lower voltage matter on a idle lv CPU?

----------

## just-linux

For my Intel Pentium M Dothan (2000MHz), undervolting does quite a big difference. At full frequency, It drops the temperature by approximately 20°C  :Very Happy:  I haven't had a look at the battery life yet. However, as soon as I have to travel again, I'll check this out  :Very Happy: 

@ info2

Thanks for for the hints  :Wink:  But still, I can't set my VIDs lower than 18 :S And I'm pretty sure that my Bios is not broken...

----------

## shladnik

Hi all,

I was using patch 0.2.9 happily, but recently i decided to upgrade kernel (linux-2.6.20-suspend2-r6 -> linux-2.6.21-suspend2-r7), so i downloed newer patch also.

I see the files:

 *Quote:*   

> gentoo_notes ~ # ls /sys/devices/system/cpu/cpu0/cpufreq/phc*
> 
> /sys/devices/system/cpu/cpu0/cpufreq/phc_controls          /sys/devices/system/cpu/cpu0/cpufreq/phc_fids
> 
> /sys/devices/system/cpu/cpu0/cpufreq/phc_default_controls  /sys/devices/system/cpu/cpu0/cpufreq/phc_version
> ...

 

but i cant do anything with them:

 *Quote:*   

> gentoo_notes ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/phc*
> 
> cat: /sys/devices/system/cpu/cpu0/cpufreq/phc_controls: No such device
> 
> cat: /sys/devices/system/cpu/cpu0/cpufreq/phc_default_controls: No such device
> ...

 

I am using ondemand governor.

Thanks

Stefan

----------

## info2

Hello 

shladnik:

There are some users that have this problem.

The reason is that acpi-cpufreq decides if your system is either "SYSTEM_IO_CAPABLE" or "SYSTEM_INTEL_MSR_CAPABLE". It seems that especially on older hardware acpi-cpufreq switches to the first while linux-phc need the second state.

We are currently reworking the speedstep-centrino patches. They will be released with linux-phc-0.3.1. 

They will have the same sysfs interface like acpi-cpifreq so PHCtool and other userspace programs can be used with it.

Until these patches are completed you should use the 0.2x release.

If you like to test the new patches: we need you  :Wink:  In some few weeks the first test release will be ready.

just-linux:

Very strange.

Could you compile your kernel with cpufreq.debug enabled and send me the output of dmesg with all cpufreq messages in it (after trying to set a vid below 18, etc to have everything in it)?

Maybe i can see whats wrong.

Did it worked with the old patches and speedstep-centrino? Maybe you're also an candidate for 0.3.1.

Schmolch:

You are the first one with an lv-cpu.

It would be quite interesting to see your changes (standard-vids and lower vids, temperature difference and battery time difference, if any).

If you like you can post them here of meet me in the IRC channel of linux-phc.

Like i already wrote, we'll need people to test the coming speedstep-centrino patches once they are ready.

----------

## just-linux

@info2

Recently, I tried again to set a VID lower than 18 and it WORKED! I don't really know why, I haven't changed anything... 

```

tobi tobi # cat /proc/cpuinfo | grep MHz

cpu MHz         : 800.000

```

```

        |     CPU 0     |     CPU 1     |

        +-------+-------+-------+-------+

        | FID   | VID   | FID   | VID   |

--------+-------+-------+-------+-------+

Min     | 6     | 18    | -     | -     |

Max     | 15    | 41    | -     | -     |

--------+-------+-------+-------+-------+

Target  | 6     | 0     | -     | -     |

Current | 6     | 0     | -     | -     |

--------+-------+-------+-------+-------+

```

----------

## info2

Great news!

Maybe it's because the sun is in line with Venus and there was a mice running over a hill in Afrika.

----------

## info2

Tester needed!

I'm proud to tell you that linux-phc-0.3.1 is nearby complete.

We just wish to test it on some different systems / processors to be sure it'll work for everybody.

Whats new?

 * The speedstep-centrino patches has been reworked. 

    They now use the new interface acpi-cpufreq already use and is compatible with PHCtool.

 * Also this patch doesn't just reject values out of range of 0.700 - 1.600Volts, it is rejecting all values above the default  voltage of each step.

    Accidently overvolting is now not even possible by a microvolt. Acpi-cpufreq patches already own this check.

I'll upload the developement release as soon as possible in svn. 

People that want to test it now can ask for it on the irc-channel.

----------

## TheKaneB

Hi!

I'm the new entry who reworked the 0.2.x patch into the 0.3.1 patch... I'm here to get any feedback directly from you.

@info2: do we know each other? ^_^

----------

## Schmolch

 *info2 wrote:*   

> Hello 
> 
> Schmolch:
> 
> You are the first one with an lv-cpu.
> ...

 

Hi info2,

i was in the channel and we came to the conclusion that a core-duo cannot have a lower voltage then it's lowest standard voltage.

----------

## shladnik

I can report that new patch works for me. 

I used the patch from svn:

linux-phc/trunk/devel/kernel-patch/speedstep-centrino/linux-phc-0.3.1-kernel-vanilla-2.6.21.7_sc.patch

I am using kernel linux-2.6.21-suspend2-r7 (gentoo system of course) with following processor:

 *Quote:*   

> processor       : 0
> 
> vendor_id       : GenuineIntel
> 
> cpu family      : 6
> ...

 

on Acer Travelmate 4000 Lmi

Stefan

----------

## info2

Thanks a lot, shladnik.

Using this new patch and the new interface you should also be able to use PHCtool.

----------

## shladnik

Well, i can't try it right now, my system crashed...   :Crying or Very sad:    don't know exaclty what happened. Probably something about hibernate or switching between X and console. Is there any possibility that patch would cause that? However, filesystem is corrupted (reiserfs), --rebuild-tree didn't help, so i will have to reinstall gentoo. Well, there are some files still readable. Pray for my /home and /etc.

Stefan

----------

## info2

 *Quote:*   

>  Is there any possibility that patch would cause that? 

 

I never heard something like that.

It is known that some programs or the whole system can crash if you undervolt too deep and put some load to the cpu.

But I never heard that the whole file system gets currupted - especially in that hard way you described.

I wish you the best.

----------

## shladnik

It was suspend2 probably or simply write cash of disk wasn't flushed.

For sure it wasn't undervolting too deep, since i am using this configuration for over a year without problems. And even if cpu would crash, there is probably no chance that this would affect file system.

----------

## superwutze

well, i have to admit that i didn't read the whole thread, so maybe i missed it, but in a quick scan i haven't read anyone mentioning the x86_64 platform.

i have a hp 6510b with an intel t7700 in a pure 64bit environment.

i patched the kernel (gentoo-2.6.22-r6) successfully but there were no options in the config menu. also i use the acpi-scaling driver right now. i now, the 64bit centrinos are pretty young, but will there be support for them?

on my last notebooks cpupw (pentium-m, 1g3) and the powernow-k8 patch (turion tl-56) worked very good and i just dislike alltime-running-fans  :Smile: 

so far i don't even know the available frequency/voltage pairs. cpupw just fails and on vista64 rmclock doesn't work either.

----------

## info2

Hello superwutze.

We never tried to apply those patches to a pure 64Bit system. 

We would need developers and testers with 64Bit machines to maintain 64Bit patches.

Technically it >>could<< work.

----------

## TheKaneB

Hi superwutze,

as info2 said, to write a driver for your cpu we need a developer who owns that hardware. However, we are working to improve the old powernow-k8 patch for amd64 platforms, in order to be able to control every platform (centrino, core, amd64) with a generic platform-independent interface, so we can use the same tool for every machine. If anyone with good coding skills and the right hardware wants to help, please contact me or info2.

bye!

----------

## bushwakko

I have a macbook pro 2.33ghz (not santa rosa) and I have undervolted in osx like this: http://generation.no/~wakko/undervolt.png and using phctool to find the same settings in linux and applying them made my laptop lock up pretty fast, so I'm thinking something isn't quite right. anyone can confirm this?

edit: I'm running 64-bit ubuntu at the moment, with the kamikaze patchset. I think they might use an old patch (2.6.22-pre1) but I'm not sure.

----------

## tnt

hm... many core2duo users run 64bit gentoos. it would be very nice if there was some 64bit version of PHC...

----------

## tnt

btw, I've just found this great site:

http://www.lesswatts.org/

and had to share it with you...   :Laughing: 

----------

## vovin

I tried to change voltage using patch 0.3.1 on

Linux localhost 2.6.23.9-phc #1 SMP Sat Dec 8 01:00:39 CET 2007 x86_64 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz GenuineIntel GNU/Linux

It seems to detect CPU:

affected_cpus

0

cpuinfo_cur_freq

2664000

cpuinfo_max_freq

2664000

cpuinfo_min_freq

1998000

phc_controls

8:42 6:29

phc_default_controls

8:42 6:29

phc_default_vids

42 29

phc_fids

8 6

phc_version

0.3.1

phc_vids

42 29

scaling_available_frequencies

2664000 1998000

scaling_available_governors

ondemand userspace

scaling_cur_freq

2664000

scaling_driver

acpi-cpufreq

scaling_governor

userspace

scaling_max_freq

2664000

scaling_min_freq

1998000

scaling_setspeed

2664000

If I change phc_vids, there is no change in voltage and idle temperature according to gkrellm2.

If I change voltage in BIOS, I can see lower voltage and idle temperature in gkrellm2.

----------

## dixon

I've tried out the latest linux-phc 0.3.1 running ubuntu gutsy gibbon(CPU T5470). Everything was working fine except for one thing. I cannot decrease the voltage of the lowest frequency and this frequency is the mostly used  :Sad:  If I change it to any lower value the phctool analysis tab gives me ->

target vid - 14

target vcc - 0.8875V

reached vid - 15

reached vcc - 0.9000V

Though lowering the voltages of other(higher) frequencies is working just fine :\

----------

## SteveBallmersChair

 *Schmolch wrote:*   

>  *info2 wrote:*   Hello 
> 
> Schmolch:
> 
> You are the first one with an lv-cpu.
> ...

 

That is true. I have a Core 2 Duo U7500 and here's what I have:

Default (for my chip)

Speed               Vcore

1067000            875 mV (VID = 13)

800000              850 mV (VID = 11)

I can set the VID for the top speed to 11 and no lower. The VID for the bottom frequency will not budge below 11. I can set it below that in phc_vids, but msrtool says that the VIDs stay anchored at 11. Also, I had to go to x86 from amd64 to get PHC to work as the patch does not work on an x86_64 kernel. I'm a little pissed, but I guess I found out what you guys wanted to know.

----------

## gesho

hi folks, thanks for your work.

now i'm runnning 2.6.23-r5, the phc-0.3.0 tarball had nothing for this one (r3 was the last). anything planned?

----------

## marcogrego

hi everybody,

I am a new entry, and I happly tried phctool with GUI. I am able to set values under the "voltage" tab, but unfortunately I got a "n/a" for all the columns for the "Analysis" tab. Which makes me think my system is not correctly recognized (?).

My aim is just checking whether the undervolting I am doing is applied. 

I also did patch the acpi-cpufreq kernel module and recompiled a custom kernel excluding the deprecated speedstep-centrino. (my kernel: 2.6.22)

Any advice?

Thank you in advance!

--

Marco

----------

## SteveBallmersChair

 *marcogrego wrote:*   

> hi everybody,
> 
> I am a new entry, and I happly tried phctool with GUI. I am able to set values under the "voltage" tab, but unfortunately I got a "n/a" for all the columns for the "Analysis" tab. Which makes me think my system is not correctly recognized (?).
> 
> My aim is just checking whether the undervolting I am doing is applied. 
> ...

 

You need to load the model-specific registers (MSR) module:

sudo modprobe msr

Then put it in /etc/modules.autoload.d/kernel-2.6 so that it gets loaded in the future automatically.

----------

## marcogrego

thank you so much that worked great!

----------

## marcogrego

Hey folks,

I have a pentium M 715 Dothan @1.5GHz

and it supports only two frequencies:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 

1500000 600000 

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 

acpi-cpufreq

Does anybody have the same issue? AFAIK it's quite unlikely, or to be precise, rare to have only 2 frequencies available for frequency scaling... I also used the module speedstep-centrino unsuccesfully.

----------

## pierrestz

Hi

I have a Pentium-M Sonoma 1.73Ghz processor and undervolting works well with phc 0.3.1 + speedstep-centrino on kernel 2.6.22

But i have some cpu freezes in ondemand mode when i set different voltage for the 3 highest frequency.

For example vids : 25 25 25 2 works with the ondemand governor (factory default : 41 32 25 1 :Cool: 

but other choices for the 3 first voltages gives a cpu freeze.

That's strange because with userspace governor i can set (in continuous) more efficient and specific voltage for each step : 23 17 11 2  but it freezes when i put the ondemand governor...

Is it a known bug ?

also it's the 1st time i can get the undervolting working : it fails with patched acpi-cpufreq.ko

----------

## albright

I see in kernel 2.6.24-r4 that Intel Enhanced SpeedStep

is deprecated. What - if any - implications has this for

linux-phc? I take it that for now at least I have to keep

using the enhanced speedstep for underclocking?

----------

## marcogrego

you're right it is deprecated, and as such you will have to use acpi-cpufreq (or something similar), this works fine with the undervolting process. 

Additionally you can take advantage of the Intel speedstep technology by using the module mentioned above without being obliged to use the old one.

ps: the underclocking is implied by the speedstep itself which decreases the clock speed dynamically according the clock frequencies set available for your cpu.

----------

## jannis

Just my experience with undervolting using phc:

I've got a Core 2 Duo T5500 running 2.6.23-gentoo right now and undervolting works (changed 1,66GHz VID from 40 to 19 and 1,33GHz VID from 30 to 19) but it won't let me go below 19 which is the default VID for 1,00GHz. My machine is running in 64bit mode and the maximum Core-Temp has changed from about 71°C to 58°C

----------

## jannis

Anyone knows how to get a Core 2 Duo below VID 19?

----------

## legrosmaxou

I am using a Banias 1500 , I d like to directly change the frequency tables in the kernel sources.

In the old versions it was possible in the centrino module, but no that it is integrated in the acpi driver I cant find the tables.

any help ?

----------

## marcogrego

I dont think it's possible. As fas as I know It was with the old module "speedstep-centrino", the new one does not include any specific section for what you are trying to do.

IMHO

----------

## legrosmaxou

where would it find the tables then ?

----------

## Schwinni

The tables are in the ACPI P-States driver.

PHC-0.3.2 can patch gentoo-sources-2.6.26 successfully.

Find the patch here:

http://phc.athousandnights.de/viewtopic.php?f=13&t=2

The VID/frequency pairs can be found in /sys/devices/system/cpu/cpu<n>/cpufreq/phc_controls.

For Pentium-M processors you can use VID = (Vcc - 700) / 16 <=> Vcc = (VID * 16) + 700 to calculate the voltage for a certain VID.

Use these scripts to start/stop and config the undervolting:

https://www.dedigentoo.org/trac/linux-phc/browser/trunk/src/gentoo

Best regards,

Chris

----------

## .yankee

For those of you, who haven't searched the portage recently and would like to try a ready program:

```

* sys-power/cpuspeedy

     Available versions:  0.4.1

     Homepage:            http://cpuspeedy.sourceforge.net/

     Description:         A simple and easy to use program to control the speed and the voltage of CPUs on the fly.

* sys-power/powernowd

     Available versions:  0.90 ~0.96 0.97

     Homepage:            http://www.deater.net/john/powernowd.html

     Description:         Daemon to control the speed and voltage of CPUs

```

----------

## albright

 *Quote:*   

> * sys-power/cpuspeedy 
> 
>  * sys-power/powernowd 

 

those are good programs but the point of undervolting is to

lower the voltage of the processor at GIVEN speed. For

example, my centrino ran at 600mhz at stock 7.6 v; with

undervolting I run at 600mhz at 7 v. The programs above

can't do that so far as I know. They are doing a different

job.

----------

## .yankee

 *albright wrote:*   

> 
> 
> those are good programs but the point of undervolting is to
> 
> lower the voltage of the processor at GIVEN speed. For
> ...

 

Actually, as I took a look at their websites, there seems to be NOTHING about manipulating the voltage in any of those! Sorry, if I mislead someone - it just seems the ebuild descriptions are very misleading themselves.

----------

## schorsche

Hello there, 

I downloaded the newest phc-patch for gentoo kernel 2.6.30 from

http://www.linux-phc.org/forum/viewtopic.php?f=13&t=2

It patches fine and the voltage stepping works after rebooting into

the newly compiled kernel. 

However, 

/sys/devices/system/cpu/cpu<n>/cpufreq/phc_controls

shows only two available frequencies, that is the highes (1500MHz)

and the lowest (600 MHZ) frequency on my laptop. 

What has happened with all the freq-steps in between?

----------

