RE: ACPI / cpufreq on Presario R3120

RE: ACPI / cpufreq on Presario R3120

[paul.devriendt]

> We could kludge around this by doing a compare of the tables before we
> abort, and if they are the same, just ignore one of them.
> If it differs, we do what we do now.
> 
> Ideally, this should be fixed in a BIOS update though, or 
> alternatively
> an ACPI fallback.
> 
> Paul ?
> 
> 	Dave

I'm willing to put it in the driver. It is easy to ignore certain
table entries (thanks Dominik!), and I already have to do so for
the case where BIOSs are filling out unused entries with -1 instead
of accurately reporting how many entries actually exist.

Paul.

Re: ACPI / cpufreq on Presario R3120

[Ken Hughes]

paul.devriendt@amd.com wrote:

> I'm willing to put it in the driver. It is easy to ignore certain
> table entries (thanks Dominik!), and I already have to do so for
> the case where BIOSs are filling out unused entries with -1 instead
> of accurately reporting how many entries actually exist.

I can vouch that it would be worth it; I just commented out the test
for multiple lo table entries and the modules loaded fine:

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.08b)
powernow-k8: Too many lo freq table entries
powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0x6 (1400 mV)
powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x18 (950 mV)
powernow-k8:    2 : fid 0x0 (800 MHz), vid 0x18 (950 mV)
powernow-k8: cpu_init done, current fid 0x8, vid 0x6

I then can do this:

root@budgie:~# echo powersave 
 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor  ; cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) XP Processor 3000+
stepping        : 8
cpu MHz         : 797.863
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall mmxext 3dnowext 3dnow
bogomips        : 1581.05
root@budgie:~# echo performance 
 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ; cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) XP Processor 3000+
stepping        : 8
cpu MHz         : 1595.727
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall mmxext 3dnowext 3dnow
bogomips        : 3162.11

I didn't even realize I'd been stuck in "low gear" this whole time.

Ken

Re: ACPI / cpufreq on Presario R3120

[Bruno Ducrot]

On Thu, Jun 03, 2004 at 04:42:22PM -0500, paul.devriendt@amd.com wrote:
> 
> > We could kludge around this by doing a compare of the tables before we
> > abort, and if they are the same, just ignore one of them.
> > If it differs, we do what we do now.
> > 
> > Ideally, this should be fixed in a BIOS update though, or 
> > alternatively
> > an ACPI fallback.
> > 
> > Paul ?
> > 
> > 	Dave
> 
> I'm willing to put it in the driver. It is easy to ignore certain
> table entries (thanks Dominik!), and I already have to do so for
> the case where BIOSs are filling out unused entries with -1 instead
> of accurately reporting how many entries actually exist.

What about doing this kludge in drivers/acpi/processor.c in 
acpi_processor_get_performance_states() so that all
drivers will benefit for this?

Dominik?

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: ACPI / cpufreq on Presario R3120

[Dominik Brodowski]

On Fri, Jun 04, 2004 at 11:59:45AM +0200, Bruno Ducrot wrote:
> On Thu, Jun 03, 2004 at 04:42:22PM -0500, paul.devriendt@amd.com wrote:
> > 
> > > We could kludge around this by doing a compare of the tables before we
> > > abort, and if they are the same, just ignore one of them.
> > > If it differs, we do what we do now.
> > > 
> > > Ideally, this should be fixed in a BIOS update though, or 
> > > alternatively
> > > an ACPI fallback.
> > > 
> > > Paul ?
> > > 
> > > 	Dave
> > 
> > I'm willing to put it in the driver. It is easy to ignore certain
> > table entries (thanks Dominik!), and I already have to do so for
> > the case where BIOSs are filling out unused entries with -1 instead
> > of accurately reporting how many entries actually exist.
> 
> What about doing this kludge in drivers/acpi/processor.c in 
> acpi_processor_get_performance_states() so that all
> drivers will benefit for this?
> 
> Dominik?

Hm. First of all, it looks to be not to be invalid behaviour wrt the ACPI
specification -- even though it doesn't make sense. So, doing this
workaround in drivers/acpi/processor.c would be way more complicated: we'd
need to add a flag "VALID_STATE" [remember, processor.c doesn't know about
frequency table helpers, and I'd like to keep it that way!], check for it in
every ACPI-cpufreq driver [four at the moment], ... -- even though only
_one_ needs such a workaround, AFAICS. And it's really easy in powernow-k8,
AFAICS:




Ignore two identical low freq entries in the ACPI tables for the powernow-k8
driver.

Signed-off-by:	Dominik Brodowski <linux@brodo.de>

--- linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c~	2004-05-26 22:30:43.000000000 +0200
+++ linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-06-04 17:22:23.959400368 +0200
@@ -734,9 +734,21 @@
 		}
 
 		/* verify only 1 entry from the lo frequency table */
-		if ((fid < HI_FID_TABLE_BOTTOM) && (cntlofreq++)) {
-			printk(KERN_ERR PFX "Too many lo freq table entries\n");
-			goto err_out;
+		if (fid < HI_FID_TABLE_BOTTOM) {
+			if (cntlofreq) {
+				/* if both entries are the same, ignore this
+				 * one... 
+				 */
+				if ((powernow_table[i].frequency != powernow_table[cntlofreq].frequency) ||
+				    (powernow_table[i].index != powernow_table[cntlofreq].index)) {
+					printk(KERN_ERR PFX "Too many lo freq table entries\n");
+					goto err_out;
+				}
+
+				dprintk(KERN_INFO PFX "double low frequency table entry, ignoring it.\n");
+				powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
+			} else
+				cntlofreq = i;
 		}
                                                                                                             
 		if (powernow_table[i].frequency != (data->acpi_data.states[i].core_frequency * 1000)) {

Re: ACPI / cpufreq on Presario R3120

[Bruno Ducrot]

On Fri, Jun 04, 2004 at 05:25:19PM +0200, Dominik Brodowski wrote:
> 
> Hm. First of all, it looks to be not to be invalid behaviour wrt the ACPI
> specification -- even though it doesn't make sense. So, doing this
> workaround in drivers/acpi/processor.c would be way more complicated: we'd
> need to add a flag "VALID_STATE" [remember, processor.c doesn't know about
> frequency table helpers, and I'd like to keep it that way!], check for it in
> every ACPI-cpufreq driver [four at the moment], ... -- even though only
> _one_ needs such a workaround, AFAICS. And it's really easy in powernow-k8,

Well, the spec will claims that p-states are sorted in descending order by
typical power dissipation (in the _PSS).  So yes, you are right since this is
not worded as 'strict descending order' (but well, this suck imho)..

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: ACPI / cpufreq on Presario R3120

[Dominik Brodowski]

On Fri, Jun 04, 2004 at 06:07:32PM +0200, Bruno Ducrot wrote:
> On Fri, Jun 04, 2004 at 05:25:19PM +0200, Dominik Brodowski wrote:
> > 
> > Hm. First of all, it looks to be not to be invalid behaviour wrt the ACPI
> > specification -- even though it doesn't make sense. So, doing this
> > workaround in drivers/acpi/processor.c would be way more complicated: we'd
> > need to add a flag "VALID_STATE" [remember, processor.c doesn't know about
> > frequency table helpers, and I'd like to keep it that way!], check for it in
> > every ACPI-cpufreq driver [four at the moment], ... -- even though only
> > _one_ needs such a workaround, AFAICS. And it's really easy in powernow-k8,
> 
> Well, the spec will claims that p-states are sorted in descending order by
> typical power dissipation (in the _PSS).  So yes, you are right since this is
> not worded as 'strict descending order' (but well, this suck imho)..

I might agree it is indeed a bug, but it is more easily being handled in the
individual drivers.

	Dominik

Re: ACPI / cpufreq on Presario R3120

[Ken Hughes]

Dominik Brodowski wrote:

> Ignore two identical low freq entries in the ACPI tables for the powernow-k8
> driver.
> 
> Signed-off-by:	Dominik Brodowski <linux@brodo.de>
> 
> --- linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c~	2004-05-26 22:30:43.000000000 +0200
> +++ linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-06-04 17:22:23.959400368 +0200
> @@ -734,9 +734,21 @@
>  		}
>  
>  		/* verify only 1 entry from the lo frequency table */
> -		if ((fid < HI_FID_TABLE_BOTTOM) && (cntlofreq++)) {
> -			printk(KERN_ERR PFX "Too many lo freq table entries\n");
> -			goto err_out;
> +		if (fid < HI_FID_TABLE_BOTTOM) {
> +			if (cntlofreq) {
> +				/* if both entries are the same, ignore this
> +				 * one... 
> +				 */
> +				if ((powernow_table[i].frequency != powernow_table[cntlofreq].frequency) ||
> +				    (powernow_table[i].index != powernow_table[cntlofreq].index)) {
> +					printk(KERN_ERR PFX "Too many lo freq table entries\n");
> +					goto err_out;
> +				}
> +
> +				dprintk(KERN_INFO PFX "double low frequency table entry, ignoring it.\n");
> +				powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
> +			} else
> +				cntlofreq = i;
>  		}
>                                                                                                              
>  		if (powernow_table[i].frequency != (data->acpi_data.states[i].core_frequency * 1000)) {
> 

I patched 2.6.7-rc2 with this, and get this output from the module:

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (versio1.00.09b)
powernow-k8: invalid freq entries 4294967295 kHz vs. 800000 kHz
powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0x6 (1400 mV)
powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x18 (950 mV)
powernow-k8: cpu_init done, current fid 0x8, vid 0x6

Seems to be working OK.  Thanks for everyone's help.

Ken

[PATCH] Re: ACPI / cpufreq on Presario R3120

[Dominik Brodowski]

On Fri, Jun 04, 2004 at 09:55:56AM -0700, Ken Hughes wrote:
> I patched 2.6.7-rc2 with this, and get this output from the module:
> 
> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (versio1.00.09b)
> powernow-k8: invalid freq entries 4294967295 kHz vs. 800000 kHz

Awww. Missed a "continue;" statement in the patch. Updated version attached.

> powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0x6 (1400 mV)
> powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x18 (950 mV)
> powernow-k8: cpu_init done, current fid 0x8, vid 0x6

So you only get two P-States? Paul, does this look OK?

	Dominik



Ignore two identical low freq entries in the ACPI tables for the powernow-k8
driver.

Signed-off-by:  Dominik Brodowski <linux@brodo.de>

--- linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c.original	2004-05-26 22:30:43.000000000 +0200
+++ linux-2.6.7-rc1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-06-05 15:44:31.429196000 +0200
@@ -734,9 +734,22 @@
 		}
 
 		/* verify only 1 entry from the lo frequency table */
-		if ((fid < HI_FID_TABLE_BOTTOM) && (cntlofreq++)) {
-			printk(KERN_ERR PFX "Too many lo freq table entries\n");
-			goto err_out;
+		if (fid < HI_FID_TABLE_BOTTOM) {
+			if (cntlofreq) {
+				/* if both entries are the same, ignore this
+				 * one... 
+				 */
+				if ((powernow_table[i].frequency != powernow_table[cntlofreq].frequency) ||
+				    (powernow_table[i].index != powernow_table[cntlofreq].index)) {
+					printk(KERN_ERR PFX "Too many lo freq table entries\n");
+					goto err_out;
+				}
+
+				dprintk(KERN_INFO PFX "double low frequency table entry, ignoring it.\n");
+				powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
+				continue;
+			} else
+				cntlofreq = i;
 		}
                                                                                                             
 		if (powernow_table[i].frequency != (data->acpi_data.states[i].core_frequency * 1000)) {

RE: ACPI / cpufreq on Presario R3120

[paul.devriendt]

This patch looks good, thanks Dominik. So, ignoring the AMD specific
case where there can only be 1 low freq entry, what happens in the
generic case where BIOS provides 2 (or more) identical pstates ?
Does the helper code just accept this happily, or should I also
add a check in powernow-k8 for this ? Paul.

Re: ACPI / cpufreq on Presario R3120

[Dominik Brodowski]

On Fri, Jun 04, 2004 at 01:01:40PM -0500, paul.devriendt@amd.com wrote:
> This patch looks good, thanks Dominik. So, ignoring the AMD specific
> case where there can only be 1 low freq entry, what happens in the
> generic case where BIOS provides 2 (or more) identical pstates ?

It will happily tell the driver sometimes to use the one entry, sometimes
the other entry (later one if ->target() is called with CPUFREQ_RELATION_H, 
earlier one if it is called with CPUFREQ_RELATION_L).

> Does the helper code just accept this happily, or should I also
> add a check in powernow-k8 for this ? Paul.

My patch was for powernow-k8 :-)

	Dominik

RE: ACPI / cpufreq on Presario R3120

[paul.devriendt]

 
> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors 
> (version 1.20.08b - March 20, 2004)
> powernow-k8: Too many lo freq table entries

BIOS produces tables of frequencies/voltages that are
valid for this processor. With a K8, the lists of valid
frequencies are split up into 2 tables - the low frequency
table (<1.6GHz) and the high frequency table (>= 1.6GHz).

The hardware is unable to transition between two low
frequencies. It can only transition low-high high-low or
high-high. (See chapter 9 of the BIOS and Kernel Developers
Guide, available from www.amd.com)

The driver does not have support for the only way to go
from low to low, which is low-high-low. This is because 
BIOSs are not supposed to provide >1 entry from the low
frequency table. And this, in turn, is because AMD
processor data sheets only describe a single low frequency
state as being valid for a given part.

Therefore, you have a broken BIOS. You should report this 
to the machine manufacturer.

I suggest, as a workaround, that you set CONFIG_ACPI_PROCESSOR
in the kernel config. This will then use the ACPI objects
which hopefully are constructed correctly. (I do not think
you are currently using them, but I'm not sure, you could
check your current config).

Paul.

ACPI / cpufreq on Presario R3120

[Ken Hughes]

I've got a Presario with an AMD XP-M 3000+ CPU (a 32-bit K8).
I can't get the acpi or powernow-k8 modules to load on the
2.6.6 kernel;  loading acpi gives this message:

  > acpi_processor_perf-0301 [1219] acpi_cpufreq_cpu_init : Unsupported 
address space [127, 127]

and powernow-k8 (with and without Pavel's patches) gives this:

  > powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 
1.20.08b - March 20, 2004)
  > powernow-k8: Too many lo freq table entries
  > powernow-k8: BIOS error - no PSB

I dumped the DSDT but it doesn't seem to have much info on the CPU.

The applicable section in my .config file is:

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_TABLE=m
 

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

Any suggestions where I should look?  I'm not sure if it's a
APCI or cpufreq issue  -- Ken

Re: ACPI / cpufreq on Presario R3120

[Bruno Ducrot]

Hi,

On Thu, Jun 03, 2004 at 07:32:38AM -0700, Ken Hughes wrote:
> I've got a Presario with an AMD XP-M 3000+ CPU (a 32-bit K8).

You have a AMD64 ?

> I can't get the acpi or powernow-k8 modules to load on the
> 2.6.6 kernel;  loading acpi gives this message:
> 
>  > acpi_processor_perf-0301 [1219] acpi_cpufreq_cpu_init : Unsupported 
> address space [127, 127]
> 
> and powernow-k8 (with and without Pavel's patches) gives this:
> 
>  > powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 
> 1.20.08b - March 20, 2004)
>  > powernow-k8: Too many lo freq table entries
>  > powernow-k8: BIOS error - no PSB

Then it's AMD64, not an XP-M (or else powernow-k8 would not print
that it found a AMD64 or an Opteron I believe).

To be sure, what say /proc/cpuinfo ?

Going back to your problem, can you send to me an acpidmp output, or post a
link to it?

wget ftp://ftp.kernel.org//pub/linux/kernel/people/lenb/acpi/utils/pmtools-20031210.tar.bz2
tar xjvfp pmtools-20031210.tar.bz2
cd pmtools-20031210/acpidmp
make
sudo ./acpidmp > acpidmp.out
bzip2 acpidmp.out 

> I dumped the DSDT but it doesn't seem to have much info on the CPU.

This may be on another ACPI table, likely in SSDT.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: ACPI / cpufreq on Presario R3120

[Ken Hughes]

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

Bruno Ducrot wrote:
> Hi,
> 
> On Thu, Jun 03, 2004 at 07:32:38AM -0700, Ken Hughes wrote:
> 
>>I've got a Presario with an AMD XP-M 3000+ CPU (a 32-bit K8).
> 
> You have a AMD64 ?
> 
.....
>>
>> > powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 
>>1.20.08b - March 20, 2004)
>> > powernow-k8: Too many lo freq table entries
>> > powernow-k8: BIOS error - no PSB
> 
> Then it's AMD64, not an XP-M (or else powernow-k8 would not print
> that it found a AMD64 or an Opteron I believe).
> 
> To be sure, what say /proc/cpuinfo ?

It's an AMD64/K8 core, but 32-bit only:
http://www.theinquirer.net/?article=14578

# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) XP Processor 3000+
stepping        : 8
cpu MHz         : 797.944
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext 3dnowext 
3dnow
bogomips        : 1576.96

> Going back to your problem, can you send to me an acpidmp output?

Attached.

>>I dumped the DSDT but it doesn't seem to have much info on the CPU.
> 
> This may be on another ACPI table, likely in SSDT.

It's in the SSDT probably.

Ken

[-- Attachment #2: acpidmp.out.bz2 --]
[-- Type: application/x-bzip, Size: 20933 bytes --]

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: ACPI / cpufreq on Presario R3120

[Bruno Ducrot]

On Thu, Jun 03, 2004 at 11:02:43AM -0700, Ken Hughes wrote:
> Bruno Ducrot wrote:
> >Hi,
> >
> >On Thu, Jun 03, 2004 at 07:32:38AM -0700, Ken Hughes wrote:
> >
> >>I've got a Presario with an AMD XP-M 3000+ CPU (a 32-bit K8).
> >
> >You have a AMD64 ?
> >
> .....
> >>
> >>> powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 
> >>1.20.08b - March 20, 2004)
> >>> powernow-k8: Too many lo freq table entries
> >>> powernow-k8: BIOS error - no PSB
> >
> >Then it's AMD64, not an XP-M (or else powernow-k8 would not print
> >that it found a AMD64 or an Opteron I believe).
> >
> >To be sure, what say /proc/cpuinfo ?
> 
> It's an AMD64/K8 core, but 32-bit only:
> http://www.theinquirer.net/?article=14578

What's that?  Will look at amd site then.

Ok, you have that in a SSDT :

    Name (_PSS, Package (0x03)
    {
        Package (0x06)
        {
            0x00000640, 
            0x0000F230, 
            0x00000064, 
            0x00000006, 
            0xE0202988, 
            0x00000188
        }, 

        Package (0x06)
        {
            0x00000320, 
            0x000032C8, 
            0x00000064, 
            0x00000006, 
            0xE0202E00, 
            0x00000600
        }, 

        Package (0x06)
        {
            0x00000320, 
            0x000032C8, 
            0x00000064, 
            0x00000006, 
            0xE0202E00, 
            0x00000600
        }
    })


The last two states are *exactly* the same.  Then powernow-k8 complains that
there is 2 low states (which is not supported, as Paul will tell us).
Then the driver fail.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: ACPI / cpufreq on Presario R3120

[Dave Jones]

On Thu, 2004-06-03 at 19:20, Bruno Ducrot wrote:

> 
>         Package (0x06)
>         {
>             0x00000320, 
>             0x000032C8, 
>             0x00000064, 
>             0x00000006, 
>             0xE0202E00, 
>             0x00000600
>         }, 
> 
>         Package (0x06)
>         {
>             0x00000320, 
>             0x000032C8, 
>             0x00000064, 
>             0x00000006, 
>             0xE0202E00, 
>             0x00000600
>         }
>     })
> 
> 
> The last two states are *exactly* the same.  Then powernow-k8 complains that
> there is 2 low states (which is not supported, as Paul will tell us).
> Then the driver fail.

We could kludge around this by doing a compare of the tables before we
abort, and if they are the same, just ignore one of them.
If it differs, we do what we do now.

Ideally, this should be fixed in a BIOS update though, or alternatively
an ACPI fallback.

Paul ?

	Dave