RE: Speedstep-centrino problems

RE: Speedstep-centrino problems

[Simon Moore]

Thanks for warning me about that.

I suppose I could ask Dell which variant they installed (or how to find
out which variant is installed). If I were to be certain which variant
it was, would the patch be safe if modified accordingly?

Or anyone up to patching it such that the variant can be defined at
runtime? ;) I would but I'm just a stupid java developer. :)

Reagrds,

Saimon

> -----Mensaje original-----
> De: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] En nombre de 
> Rich Townsend
> Enviado el: jueves, 10 de febrero de 2005 13:06
> Para: galin-Dn6zUBO643CDvotElmWtJA@public.gmane.org
> CC: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Asunto: Re: [ACPI] Speedstep-centrino problems
> 
> 
> I was under the impression that this patch was possibly 
> dangerous. This 
> is because the Pentium M Dothan series (the recent-ish ones, with 2Mb 
> cache) each come in four variants, VID#A through VID#D. Each 
> variant has 
> a different set of voltage characteristics, but unforutnately 
> there is 
> no way to tell which variant one has installed (is this 
> actually true? 
> How about a visual inspection?)
> 
> The patch assumes that your Pentium M is a VID#C variant. If 
> this is not 
> the case, and there is too much of a mismatch between the voltage 
> characteristics, then (possibly-serious) problems may ensue.
> 
> This is my understanding as to why Dothan frequency tables 
> have not yet 
> appeared in any "official" patch, and to why this particular 
> patch was 
> rejected.
> 
> cheers,
> 
> Rich
> 
> Galin Yordanov wrote:
> > Hello,
> > 
> > I have Acer TM4500 with Centrino 1.6 (Dothan)and i had the same 
> > problem .. then i found this patch (attached), cannot 
> remember where i 
> > found it but it works ;)
> > 
> > Regards,
> > Galin
> > On Thursday 10 February 2005 04:38 am, Simon Moore wrote:
> > 
> >>Hi,
> >>
> >>I'm trying to get acpi cpu throttling working for my Dell Inspiron 
> >>510m with a Pentium M Centrino 1.6 Ghz cpu.
> >>
> >>I have tried a number of possibilites but have not got anywhere. I 
> >>have an open case over at the gentoo forums but we have not had 
> >>success in resolving this problem.
> >>
> >>This is my last ditch attempt to try and find a solution to this 
> >>problem. I think I have exhausted most possible avenues so 
> I'm trying 
> >>to get some kernel hacker on board and help me with this.
> >>
> >>I would very much appreciate it if someone could take a 
> look at this 
> >>thread and possbily come up with a suggestion of what might 
> be causing 
> >>this. (http://forums.gentoo.org/viewtopic.php?p=2076710) I 
> have a lot 
> >>of info in that thread that you should find useful but if 
> there's any 
> >>other info you require I'll post it tonight.
> >>
> >>For what it's worth I hope it intrigues some of you enough 
> to help me 
> >>out.
> >>
> >>Thanks all the same,
> >>
> >>Regards,
> >>
> >>Saimon
> >>
> >>
> >>--------------------------
> >>Saimon Moore
> >>Departamento TI
> >>CondisLine e-Commerce S.A.
> >>
> >>telf./fax: 93 565 3400 ext. 473 / 935752325 
> http://www.condisline.com
> >>mailto://simon_moore-HnN13UdsTkzz1n+OaKNE4w@public.gmane.org
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from 
> real users. Discover which products truly live up to the 
> hype. Start reading now. 
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396> &op=click
> 
> _______________________________________________
> 
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> https://lists.sourceforge.net/lists/listinfo/ac> pi-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Speedstep-centrino problems

[Rich Townsend]

Simon Moore wrote:
> Thanks for warning me about that.
> 
> I suppose I could ask Dell which variant they installed (or how to find
> out which variant is installed). If I were to be certain which variant
> it was, would the patch be safe if modified accordingly?

I would think the chances are exceedingly small of you a) finding 
someone at Dell who actually knows this, and b) getting the information 
out of them.

> 
> Or anyone up to patching it such that the variant can be defined at
> runtime? ;) I would but I'm just a stupid java developer. :)

The problem is not so much to do with the ability to choose the 
appropriate VID#, it is more about working out *which* VID# to choose. 
If someone could address the latter question, I'd be more than happy to 
have a shot at the former.

cheers,

Rich


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Speedstep-centrino problems

[Dominik Brodowski]

> The problem is not so much to do with the ability to choose the 
> appropriate VID#, it is more about working out *which* VID# to choose. 
> If someone could address the latter question, I'd be more than happy to 
> have a shot at the former.

At some frequency levels, you can read out the current settings and
determine which VID# is used. At other frequency levels, you cannot,
though, as some VID# can have the same voltage for certain levels.
Therefore, I do not see a runtime-way to determine the correct VID# to
choose.

	Dominik


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Dothan VID# identification script (was Re: Speedstep-centrino problems)

[Rich Townsend]

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

Dominik Brodowski wrote:
>>The problem is not so much to do with the ability to choose the 
>>appropriate VID#, it is more about working out *which* VID# to choose. 
>>If someone could address the latter question, I'd be more than happy to 
>>have a shot at the former.
> 
> 
> At some frequency levels, you can read out the current settings and
> determine which VID# is used. At other frequency levels, you cannot,
> though, as some VID# can have the same voltage for certain levels.
> Therefore, I do not see a runtime-way to determine the correct VID# to
> choose.
> 
> 	Dominik

The attached Perl script demonstrates one run-time approach to 
determining the correct VID# to use. In principle, this approach could 
be integrated into the kernel, to allow Pentium M Dothan support to be 
added to speedstep-centrino.

Rather paradoxically, for this script to work, cpufreq must already be 
up and running. This is because the script uses the entries in 
/sys/devices/.../cpufreq to get a *provisional* list of processor 
frequencies. It is expected that this list be obtained from the 
processor P-state information in the DSDT, so for the script to work, 
make sure you have the acpi_cpufreq table helper installed (see 
instructions at the end of this post).

The script iterates through the provisional frequency list, setting the 
processor frequency using the scaling_[max|min]_freq files in 
/sys/devices/.../cpufreq. The frequency and voltage are then read back 
using the IA32_PERF_STATUS MSR. This way, a frequency/voltage table is 
built up for the system. Each entry of the table is *guaranteed* to be a 
valid frequency/voltage pair, although some frequencies may be missing 
from the table due to DSDT bugs (on my 1.6Ghz Dothan system, the DSDT 
mislabels the 1000 MHz frequency, and omits the 800 Mhz frequency).

The frequency/voltage table is then cross-checked against *all* of the 
Pentium M Dothan tables published by Intel (i.e., all of the possible 
processor and VID# combinations). If there is a single, *unique* match, 
then the Perl script prints out this match, plus the *full* 
frequency/voltage table (including entries that the DSDT may have 
missed). Example output on my system is as follows:

Identified Intel(r) Pentum(r) M Processor 725 Core, 1.6 Ghz, VID#A
Frequency/voltage table:
  600 MHz        ->      988 mV
  800 MHz        ->      1068 mV
  1000 MHz       ->      1132 mV
  1200 MHz       ->      1212 mV
  1400 MHz       ->      1276 mV
  1600 MHz       ->      1340 mV

Of course, we can't guarantee that there will always be a match; or that 
there won't be duplicate matches. Also, this approach relies on having 
ACPI P-states, to build up the frequency/voltage table. However, it 
still seems to me to be a pretty robust way of determining the VID# in a 
system, and one that could be incorporated into speedstep-centrino. 
Dominik, what do you think?

cheers

Rich

PS Almost forgot: for those wanting to use the script, make sure you 
have cpufreq enabled in your kernel, and make sure the ACPI Processor 
P-states driver is installed (CONFIG_X86_ACPI_CPUFREQ), and that you 
also have the userspace governor installed 
(CONFIG_CPU_FREQ_GOV_USERSPACE). Then, just run the script *as root*, 
with no arguments.

[-- Attachment #2: dothan_id.pl --]
[-- Type: text/plain, Size: 5703 bytes --]

#!/usr/bin/perl -w
#
#  dothan_id.pl
#
#  (c) 2005 Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org>
#
# Script to identify the voltage ID (VID#) of a 
# Pentium M Dothan CPU

# Constants

$CPUFREQ_DIR = "/sys/devices/system/cpu/cpu0/cpufreq";

$MSR_FILE = "/dev/cpu/0/msr";
$MSR_IA32_PERF_STATUS = 0x198;

$DEBUG = 0;

# Enumerate the avaliable frequencies

@afreqs = split(' ', cpufreq_read('scaling_available_frequencies'));

# Set the governor to userspace

cpufreq_write('scaling_governor', 'userspace');
cpufreq_read('scaling_governor') eq 'userspace' or die "Unable to set governor to userspace\n";

# Iterate through the available frequencies, building
# up the frequency/voltage table

%freq_table = ();

foreach my $afreq (sort { $a <=> $b } @afreqs) {

# Set the current frequency

    cpufreq_write('scaling_max_freq', $afreq);
    cpufreq_write('scaling_min_freq', $afreq);

    cpufreq_read('scaling_cur_freq') == $afreq or die "Unable to set frequency to $afreq\n";

# Read back the frequency and voltage into using
# the MSR

    my $msr_str;

    open MSR_FILE, "<$MSR_FILE" or die "Unable to read from $MSR_FILE\n$!";
    seek MSR_FILE, $MSR_IA32_PERF_STATUS, 0;
    read MSR_FILE, $msr_str, 8;
    close MSR_FILE;

    my $msr_val = 0;
    
    for(my $i = 0; $i < 8; $i++) {
	$msr_val <<= 8;
	$msr_val += ord(substr($msr_str, 7-$i, 1));
    }

    $msr_val &= 0xffffffff;

    my $freq = 100*($msr_val>>8 & 0xff);
    my $volt = 16*($msr_val & 0xff) + 700;

    $freq_table{$freq} = $volt;

    $DEBUG && printf("Available frequency %d gives frequency %d MHz @ %d mV\n", $afreq, $freq, $volt);
}

# Set up the voltage data table, taken from Intel's 
# January 2005 datasheet for the Pentium M Dothan

%DOTHAN_DATA = (
		715 => {
		    'rating' => '1.5',
		    'freqs' => [600, 800, 1000, 1200, 1500],
		    'VIDs' => {
			'A' => [988, 1068, 1148, 1228, 1340],
			'B' => [988, 1068, 1148, 1212, 1324],
			'C' => [988, 1068, 1132, 1212, 1308],
			'D' => [988, 1052, 1116, 1180, 1276]
			}
		},
		725 => {
		    'rating' => '1.6',
		    'freqs' => [600, 800, 1000, 1200, 1400, 1600],
		    'VIDs' => {
			'A' => [988, 1068, 1132, 1212, 1276, 1340],
			'B' => [988, 1068, 1132, 1196, 1260, 1324],
			'C' => [988, 1052, 1116, 1180, 1244, 1308],
			'D' => [988, 1052, 1116, 1164, 1228, 1276]
			}
		},
		735 => {
		    'rating' => '1.7',
		    'freqs' => [600, 800, 1000, 1200, 1400, 1700],
		    'VIDs' => {
			'A' => [988, 1052, 1116, 1180, 1244, 1340],
			'B' => [988, 1052, 1116, 1180, 1244, 1324],
			'C' => [988, 1052, 1116, 1164, 1228, 1308],
			'D' => [988, 1052, 1100, 1148, 1212, 1276]
			}
		},
		745 => {
		    'rating' => '1.8',
		    'freqs' => [600, 800, 1000, 1200, 1400, 1600, 1800],
		    'VIDs' => {
			'A' => [988, 1052, 1116, 1164, 1228, 1292, 1340],
			'B' => [988, 1052, 1100, 1164, 1212, 1276, 1324],
			'C' => [988, 1052, 1100, 1148, 1212, 1260, 1308],
			'D' => [988, 1036, 1084, 1132, 1180, 1228, 1276]
			}
		},
		755 => {
		    'rating' => '2.0',
		    'freqs' => [600, 800, 1000, 1200, 1400, 1600, 1800, 2000],
		    'VIDs' => {
			'A' => [988, 1052, 1100, 1148, 1196, 1244, 1292, 1340],
			'B' => [988, 1036, 1084, 1132, 1180, 1228, 1276, 1324],
			'C' => [988, 1036, 1084, 1132, 1180, 1228, 1276, 1308],
			'D' => [988, 1036, 1084, 1116, 1164, 1196, 1244, 1276]
			}
		},
		765 => {
		    'rating' => '2.1',
		    'freq' => [600, 800, 1000, 1200, 1400, 1600, 1800, 2100],
		    'VIDs' => {
			'A' => [988, 1036, 1084, 1132, 1180, 1228, 1276, 1340],
			'B' => [988, 1036, 1084, 1132, 1180, 1212, 1260, 1324],
			'C' => [988, 1036, 1084, 1116, 1164, 1212, 1244, 1308],
			'E' => [988, 1052, 1100, 1148, 1196, 1244, 1292, 1356]
			}
		}
		);

# Attempt to match the frequency table against one
# of the Dothan tables

@match_cpus = ();
@match_VIDs = ();

foreach $cpu (keys %DOTHAN_DATA) {

    foreach $VID (keys %{$DOTHAN_DATA{$cpu}->{'VIDs'}}) {

# Dynamically create a table for the current cpu/VID
# pair

	my %dothan_freq_table = ();

	for(my $i_freq = 0; $i_freq <= $#{$DOTHAN_DATA{$cpu}->{'freqs'}}; $i_freq++) {
	    my $freq = $DOTHAN_DATA{$cpu}->{'freqs'}->[$i_freq];
	    my $volt = $DOTHAN_DATA{$cpu}->{'VIDs'}->{$VID}->[$i_freq];
	    $dothan_freq_table{$freq} = $volt;
	}
			 
# See whether the frequency table is a 
# subset of the Dothan table

	my $match = 1;

	foreach my $freq (keys %freq_table) {
	    if(!exists($dothan_freq_table{$freq}) ||
	       $dothan_freq_table{$freq} != $freq_table{$freq}) {
		$match = 0;
		last;
	    }
	}
	    
# If a match was found, store the cpu and VID

	if($match) {
	    push @match_cpus, $cpu;
	    push @match_VIDs, $VID;
	}
	
    }
}	
	
# Print out the results

if(@match_cpus == 0) {

    print "No matches found\n";

}
elsif(@match_cpus == 1) {

    my $cpu = $match_cpus[0];
    my $VID = $match_VIDs[0];

    printf("Identified Intel(r) Pentum(r) M Processor %d Core, %2.1f Ghz, VID#%s\n", 
	   $cpu, $DOTHAN_DATA{$cpu}->{'rating'}, $VID);

    printf("Frequency/voltage table:\n");

    for(my $i_freq = 0; $i_freq <= $#{$DOTHAN_DATA{$cpu}->{'freqs'}}; $i_freq++) {
	my $freq = $DOTHAN_DATA{$cpu}->{'freqs'}->[$i_freq];
	my $volt = $DOTHAN_DATA{$cpu}->{'VIDs'}->{$VID}->[$i_freq];
	printf(" %d MHz\t->\t%d mV\n", $freq, $volt);
    }

}
else {

    print "Duplicate matches found, no identification possible\n";

}

# Finish

sub cpufreq_read {

    open CPUFREQ, "<$CPUFREQ_DIR/$_[0]" or die "Unable to read from $CPUFREQ_DIR/$_[0]\n$!";
    my $line = <CPUFREQ>;
    close CPUFREQ;

    chomp $line;

    return $line;

}

sub cpufreq_write {

    open CPUFREQ, ">$CPUFREQ_DIR/$_[0]" or die "Unable to write to $CPUFREQ_DIR/$_[0]\n$!";
    print CPUFREQ $_[1];
    close CPUFREQ;

}

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Dominik Brodowski]

On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
> Of course, we can't guarantee that there will always be a match; or that 
> there won't be duplicate matches. Also, this approach relies on having 
> ACPI P-states, to build up the frequency/voltage table. However, it 
> still seems to me to be a pretty robust way of determining the VID# in a 
> system, and one that could be incorporated into speedstep-centrino. 
> Dominik, what do you think?

It indeed seems somewhat robust to me, I'd like to get Venkatesh's input on
this, though. "Transient voltages" may pose a problem, though...

I wouldn't favor for inclusion into speedstep-centrino, though -- one
cpufreq driver requiring at first one other to run, then to unload the other
with speedstep-centrino taking over... no, that doesn't _feel_ right. I
wouldn't vote against including the Dothan tables but only using them if the
user passes a parameter "vid=[a-f]", though.

Just my $0.02,

	Dominik

PS: moved this discussion to the cpufreq list which seems more appropriate
for this stuff.

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Rich Townsend]

Dominik Brodowski wrote:
> On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
> 
>>Of course, we can't guarantee that there will always be a match; or that 
>>there won't be duplicate matches. Also, this approach relies on having 
>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>still seems to me to be a pretty robust way of determining the VID# in a 
>>system, and one that could be incorporated into speedstep-centrino. 
>>Dominik, what do you think?
> 
> 
> It indeed seems somewhat robust to me, I'd like to get Venkatesh's input on
> this, though. "Transient voltages" may pose a problem, though...

Gak, hadn't thought of that.

> 
> I wouldn't favor for inclusion into speedstep-centrino, though -- one
> cpufreq driver requiring at first one other to run, then to unload the other
> with speedstep-centrino taking over... no, that doesn't _feel_ right. I
> wouldn't vote against including the Dothan tables but only using them if the
> user passes a parameter "vid=[a-f]", though.

I concurr. Unless a subset of acpi_cpufreq could be implemented within 
speedstep-centrino without nasty hackery, you end up with an unpleasant 
dependency problem. I'll look into adding the vid= option over the 
Dothan tables patch.

cheers,

Rich

RE: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: cpufreq-bounces@ZenII.linux.org.uk 
>[mailto:cpufreq-bounces@ZenII.linux.org.uk] On Behalf Of Rich Townsend
>Sent: Sunday, February 13, 2005 6:12 AM
>To: Dominik Brodowski
>Cc: cpufreq@ZenII.linux.org.uk; Simon Moore
>Subject: Re: Dothan VID# identification script (was Re: [ACPI] 
>Speedstep-centrino problems)
>
>Dominik Brodowski wrote:
>> On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
>> 
>>>Of course, we can't guarantee that there will always be a 
>match; or that 
>>>there won't be duplicate matches. Also, this approach relies 
>on having 
>>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>>still seems to me to be a pretty robust way of determining 
>the VID# in a 
>>>system, and one that could be incorporated into speedstep-centrino. 
>>>Dominik, what do you think?
>> 
>> 
>> It indeed seems somewhat robust to me, I'd like to get 
>Venkatesh's input on
>> this, though. "Transient voltages" may pose a problem, though...
>
>Gak, hadn't thought of that.
>

Actually, if you use CNTL MSR in place of STATUS MSR, you don't have to
worry about transients.

Thanks,
Venki

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Rich Townsend]

Pallipadi, Venkatesh wrote:
>>-----Original Message-----
>>From: cpufreq-bounces@ZenII.linux.org.uk 
>>[mailto:cpufreq-bounces@ZenII.linux.org.uk] On Behalf Of Rich Townsend
>>Sent: Sunday, February 13, 2005 6:12 AM
>>To: Dominik Brodowski
>>Cc: cpufreq@ZenII.linux.org.uk; Simon Moore
>>Subject: Re: Dothan VID# identification script (was Re: [ACPI] 
>>Speedstep-centrino problems)
>>
>>Dominik Brodowski wrote:
>>
>>>On Sat, Feb 12, 2005 at 06:28:27PM -0500, Rich Townsend wrote:
>>>
>>>
>>>>Of course, we can't guarantee that there will always be a 
>>
>>match; or that 
>>
>>>>there won't be duplicate matches. Also, this approach relies 
>>
>>on having 
>>
>>>>ACPI P-states, to build up the frequency/voltage table. However, it 
>>>>still seems to me to be a pretty robust way of determining 
>>
>>the VID# in a 
>>
>>>>system, and one that could be incorporated into speedstep-centrino. 
>>>>Dominik, what do you think?
>>>
>>>
>>>It indeed seems somewhat robust to me, I'd like to get 
>>
>>Venkatesh's input on
>>
>>>this, though. "Transient voltages" may pose a problem, though...
>>
>>Gak, hadn't thought of that.
>>
> 
> 
> Actually, if you use CNTL MSR in place of STATUS MSR, you don't have to
> worry about transients.

OK! What is the offset of the CNTL MSR? And does it decode to a 
freq/voltage pair in the same way as STATUS?

On a related note, is there a simple way to set the CPU to its maximum 
frequency, without having to know what the associated voltage is?

cheers,

Rich

Re: Dothan VID# identification script (was Re: [ACPI] Speedstep-centrino problems)

[Dominik Brodowski]

On Sun, Feb 20, 2005 at 09:23:12AM -0500, Rich Townsend wrote:
> OK! What is the offset of the CNTL MSR?

MSR_IA32_PERF_CTL


> And does it decode to a freq/voltage pair in the same way as STATUS?

Yes.

> On a related note, is there a simple way to set the CPU to its maximum 
> frequency, without having to know what the associated voltage is?

Using speedstep-centrino, no.

	Dominik