Athlon 64 complains of frequency mismatch

Athlon 64 complains of frequency mismatch

[Marc Singer]

Below is the dmesg output from the powernow driver. I'd be glad to
patch the driver to fix&test if you can give me some indication as to
where to look for the trouble.

Cheers.

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09b)
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid freq entries 3300000 kHz vs. 2147483048 kHz
powernow-k8: invalid powernow_table

Re: Athlon 64 complains of frequency mismatch

[Dominik Brodowski]

Hi,

It looks like there's either a problem in the ACPI tables. So I'd like to
dump the relevant parts of the ACPI tables -- so, please, 
could you put this file

http://www.brodo.de/patches/2004-04-06/cpufreq-acpi_pdump.c

into the directory [assuming you're running a 64bit kernel]

arch/x86_64/kernel/cpufreq/ in the linux kernel sources,
add the line

obj-m += cpufreq-acpi_pdump.o

to the file "Makefile" in this directory,

re-build the kernel and modules, and then 

modprobe cpufreq-acpi_pdump

and send the dmesg to me?

Thanks,
	Dominik

On Fri, Jun 18, 2004 at 11:51:03AM -0700, Marc Singer wrote:
> Below is the dmesg output from the powernow driver. I'd be glad to
> patch the driver to fix&test if you can give me some indication as to
> where to look for the trouble.

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Sat, Jun 19, 2004 at 12:44:56PM +0200, Dominik Brodowski wrote:
> Hi,
> 
> It looks like there's either a problem in the ACPI tables. So I'd like to
> dump the relevant parts of the ACPI tables -- so, please, 
> could you put this file
> 
> http://www.brodo.de/patches/2004-04-06/cpufreq-acpi_pdump.c
> 
> into the directory [assuming you're running a 64bit kernel]
> 
> arch/x86_64/kernel/cpufreq/ in the linux kernel sources,
> add the line
> 
> obj-m += cpufreq-acpi_pdump.o
> 
> to the file "Makefile" in this directory,
> 
> re-build the kernel and modules, and then 
> 
> modprobe cpufreq-acpi_pdump
> 
> and send the dmesg to me?

On rumination, I came to a similar conclusion.  I can do as you ask.
Is this the same as grabbing the dsdt from the /proc/acpi interface
and running it through Intel's decompiler?  That's where I've started
to go.

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Sat, Jun 19, 2004 at 12:44:56PM +0200, Dominik Brodowski wrote:
> Hi,
> 
> It looks like there's either a problem in the ACPI tables. So I'd like to
> dump the relevant parts of the ACPI tables -- so, please, 
> could you put this file
> 
> http://www.brodo.de/patches/2004-04-06/cpufreq-acpi_pdump.c
> 
> into the directory [assuming you're running a 64bit kernel]
> 
> arch/x86_64/kernel/cpufreq/ in the linux kernel sources,
> add the line
> 
> obj-m += cpufreq-acpi_pdump.o
> 
> to the file "Makefile" in this directory,
> 
> re-build the kernel and modules, and then 
> 
> modprobe cpufreq-acpi_pdump
> 
> and send the dmesg to me?
> 
> Thanks,
> 	Dominik

It complains of a device not being present and leaves this in the
dmesg log:


number of states: 10
acpi_pdump: P0: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P1: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P2: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P3: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P4: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P5: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P6: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P7: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P8: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
acpi_pdump: P9: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
control_register:
130 12 127 0 0 0 0
status_register:
130 12 127 0 0 0 0

Is this really helpful?

Re: Athlon 64 complains of frequency mismatch

[Dominik Brodowski]

On Sat, Jun 19, 2004 at 09:36:31AM -0700, Marc Singer wrote:
> It complains of a device not being present and leaves this in the
> dmesg log:
> 
> 
> number of states: 10
> acpi_pdump: P0: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P1: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P2: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P3: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P4: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P5: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P6: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P7: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P8: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> acpi_pdump: P9: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999
> control_register:
> 130 12 127 0 0 0 0
> status_register:
> 130 12 127 0 0 0 0
> 
> Is this really helpful?
Partly. It shows the values received by the powernow-k8 driver are
_completely_ bogus. A standard questions: have you tried a BIOS update?

> On rumination, I came to a similar conclusion.  I can do as you ask.
> Is this the same as grabbing the dsdt from the /proc/acpi interface
> and running it through Intel's decompiler?  That's where I've started
> to go.

Not really -- acpi_pdump dumps what's received by the powernow-k8 driver
from the ACPI subsystem, while decompiling /proc/acpi/dsdt prints out what's
really there in the ACPI tables. In your case, it might indeed be
interesting whether a more appropriate P-States part of the DSDT is
contained somewhere, which is not initialized properly. Could you
disassemble the DSDT, please, and check for _PSS entries (grep -20 _PSS)?

Thanks,
	Dominik

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Mon, Jun 21, 2004 at 10:26:01PM +0200, Dominik Brodowski wrote:
> > Is this really helpful?
> Partly. It shows the values received by the powernow-k8 driver are
> _completely_ bogus. A standard questions: have you tried a BIOS update?

I looked for one.  I downloaded a BIOS, though I'm not sure it is
newer than the one installed.  The release notes make no mention of
powernow or acpi.

> > On rumination, I came to a similar conclusion.  I can do as you ask.
> > Is this the same as grabbing the dsdt from the /proc/acpi interface
> > and running it through Intel's decompiler?  That's where I've started
> > to go.
> 
> Not really -- acpi_pdump dumps what's received by the powernow-k8 driver
> from the ACPI subsystem, while decompiling /proc/acpi/dsdt prints out what's
> really there in the ACPI tables. In your case, it might indeed be
> interesting whether a more appropriate P-States part of the DSDT is
> contained somewhere, which is not initialized properly. Could you
> disassemble the DSDT, please, and check for _PSS entries (grep -20 _PSS)?
> 

I did fetch it.  There are no entries for _PSS or even PSS.

> Thanks,
> 	Dominik

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

> > Partly. It shows the values received by the powernow-k8 driver are
> > _completely_ bogus. A standard questions: have you tried a 
> BIOS update?
> 
> I looked for one.  I downloaded a BIOS, though I'm not sure it is
> newer than the one installed.  The release notes make no mention of
> powernow or acpi.

> I did fetch it.  There are no entries for _PSS or even PSS.

The frequency/voltage values are different for different processor
models. The way that this is supposed to work is that the BIOS
provides a table of the frequency/voltage data that the driver 
uses, thus making the driver independent of the platform.

Obviously if the BIOS does not do this, then the driver has no
data. I do have a version of the driver that uses hardcoded
values for my own testing purposes, but the source has to be
edited to put in the correct values for your particular processor.

I did intend to make this data module parameters, but have not
had the time to do so yet. You can find the correct data values
for your processor from the "Power and Thermal" pdfs available 
on www.amd.com. Let me know if you want a copy of this hardcoded
driver (or it is easy to modify the driver ourself).

Paul.

RE: Athlon 64 complains of frequency mismatch

[Arjan van de Ven]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]


> I did intend to make this data module parameters, but have not

how about a sysfs file instead ?

> had the time to do so yet. You can find the correct data values
> for your processor from the "Power and Thermal" pdfs available 
> on www.amd.com. Let me know if you want a copy of this hardcoded
> driver (or it is easy to modify the driver ourself).

hmmm I wonder if say x86info or similar app can include those tables and
put them into the sysfs file during system boot..... to bypass the
firmware dependancy entirely. x86info has lots of cpu low level stuff
already so it just might fit there...

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

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

Re: Athlon 64 complains of frequency mismatch

[Andi Kleen]

Arjan van de Ven <arjanv@redhat.com> writes:

>> I did intend to make this data module parameters, but have not
>
> how about a sysfs file instead ?
>
>> had the time to do so yet. You can find the correct data values
>> for your processor from the "Power and Thermal" pdfs available 
>> on www.amd.com. Let me know if you want a copy of this hardcoded
>> driver (or it is easy to modify the driver ourself).
>
> hmmm I wonder if say x86info or similar app can include those tables and
> put them into the sysfs file during system boot..... to bypass the
> firmware dependancy entirely. x86info has lots of cpu low level stuff
> already so it just might fit there...

I thought some laptops had limited thermal design and required
more restrictions? e.g. it may not be safe to bypass the BIOS completely.
Or at least not automatically when you don't know what you're doing.

-Andi

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Mon, Jun 21, 2004 at 11:02:06PM -0700, paul.devriendt@amd.com wrote:
> > > Partly. It shows the values received by the powernow-k8 driver are
> > > _completely_ bogus. A standard questions: have you tried a 
> > BIOS update?
> > 
> > I looked for one.  I downloaded a BIOS, though I'm not sure it is
> > newer than the one installed.  The release notes make no mention of
> > powernow or acpi.
> 
> > I did fetch it.  There are no entries for _PSS or even PSS.
> 
> The frequency/voltage values are different for different processor
> models. The way that this is supposed to work is that the BIOS
> provides a table of the frequency/voltage data that the driver 
> uses, thus making the driver independent of the platform.
> 
> Obviously if the BIOS does not do this, then the driver has no
> data. I do have a version of the driver that uses hardcoded
> values for my own testing purposes, but the source has to be
> edited to put in the correct values for your particular processor.
> 
> I did intend to make this data module parameters, but have not
> had the time to do so yet. You can find the correct data values
> for your processor from the "Power and Thermal" pdfs available 
> on www.amd.com. Let me know if you want a copy of this hardcoded
> driver (or it is easy to modify the driver ourself).

Perhaps I'm missing something.  If AMD advertizes Cool&Quiet as does
this vendor, MSI, then there has to be someplace where this data is
given to Windows.  Are we talking about the vendor providing a Windows
driver without including the necessary information in the BIOS?

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

> Perhaps I'm missing something.  If AMD advertizes Cool&Quiet as does
> this vendor, MSI, then there has to be someplace where this data is
> given to Windows.  Are we talking about the vendor providing a Windows
> driver without including the necessary information in the BIOS?

The Windows XP driver gets the information from the same place as
the Linux driver ... the ACPI _PSS object.

If Windows is able to find the data but Linux can not, then we have
some sort of bug or spec compliance issue.

Windows 2000 gets the information from the BIOS PSB table, and the
Linux driver is also capable of using this data (if CONFIG_ACPI_PROCESSOR
is not set, or if ACPI _PSS data can not be found).

Paul.

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

 
> I thought some laptops had limited thermal design and required
> more restrictions? e.g. it may not be safe to bypass the BIOS 
> completely.
> Or at least not automatically when you don't know what you're doing.
> 
> -Andi

Yes, so any sort of do it yourself / override capability is at your
own risk. 

Paul.

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Tue, Jun 22, 2004 at 08:26:38AM -0700, paul.devriendt@amd.com wrote:
> > Perhaps I'm missing something.  If AMD advertizes Cool&Quiet as does
> > this vendor, MSI, then there has to be someplace where this data is
> > given to Windows.  Are we talking about the vendor providing a Windows
> > driver without including the necessary information in the BIOS?
> 
> The Windows XP driver gets the information from the same place as
> the Linux driver ... the ACPI _PSS object.

And if there is no _PSS ACPI object(s)?

> If Windows is able to find the data but Linux can not, then we have
> some sort of bug or spec compliance issue.
> 
> Windows 2000 gets the information from the BIOS PSB table, and the
> Linux driver is also capable of using this data (if CONFIG_ACPI_PROCESSOR
> is not set, or if ACPI _PSS data can not be found).

I take this to mean that I might see the correct data if I disable the
ACPI PROCESSOR module.  Right?

Re: Athlon 64 complains of frequency mismatch

[Dominik Brodowski]

On Tue, Jun 22, 2004 at 09:07:41AM -0700, Marc Singer wrote:
> On Tue, Jun 22, 2004 at 08:26:38AM -0700, paul.devriendt@amd.com wrote:
> > > Perhaps I'm missing something.  If AMD advertizes Cool&Quiet as does
> > > this vendor, MSI, then there has to be someplace where this data is
> > > given to Windows.  Are we talking about the vendor providing a Windows
> > > driver without including the necessary information in the BIOS?
> > 
> > The Windows XP driver gets the information from the same place as
> > the Linux driver ... the ACPI _PSS object.
> 
> And if there is no _PSS ACPI object(s)?

It falls back to BIOS PSB -- at least it should...

> > If Windows is able to find the data but Linux can not, then we have
> > some sort of bug or spec compliance issue.
> > 
> > Windows 2000 gets the information from the BIOS PSB table, and the
> > Linux driver is also capable of using this data (if CONFIG_ACPI_PROCESSOR
> > is not set, or if ACPI _PSS data can not be found).
> 
> I take this to mean that I might see the correct data if I disable the
> ACPI PROCESSOR module.  Right?

You can try that, yes, but normally it should already be tried
automagically.

	Dominik

Re: Athlon 64 complains of frequency mismatch

[Dominik Brodowski]

On Mon, Jun 21, 2004 at 02:42:36PM -0700, Marc Singer wrote:
> I did fetch it.  There are no entries for _PSS or even PSS.

But an entry XPSS which contains these bogus entries...


            Name (XPSS, Package (0x03)
            {
                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                },

                Package (0x06)
                {
                    0x09999999,
                    0x00099999,
                    0x00999999,
                    0x00999999,
                    0x99999999,
                    0x99999999
                }
            })


I'm surprised a) that the BIOS-provided tables contain such obviously bogus
data, and b) that XPSS is used by the ACPI subsystem instead of reporting
there is no _PSS.

Also, are there any entries in the BIOS you can toggle which might be
related to "Cool&Quiet", "PnP-capable OS", ...?

	Dominik

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Tue, Jun 22, 2004 at 07:11:03PM +0200, Dominik Brodowski wrote:
> Also, are there any entries in the BIOS you can toggle which might be
> related to "Cool&Quiet", "PnP-capable OS", ...?

Bingo.  There is a Cool&Quiet enable option.  The dump module now
produces this:

    ACPI: Processor [CPU1] (supports C1, 16 throttling states)
    number of states: 10
    acpi_pdump: P0: 2000 MHz, 89000 mW, 125 uS s:0x8c c:0xa020288c
    acpi_pdump: P1: 1800 MHz, 66000 mW, 125 uS s:0x18a c:0xa020298a
    acpi_pdump: P2: 1800 MHz, 66000 mW, 125 uS s:0x18a c:0xa020298a
    acpi_pdump: P3: 1800 MHz, 66000 mW, 125 uS s:0x18a c:0xa020298a
    acpi_pdump: P4: 1800 MHz, 66000 mW, 125 uS s:0x18a c:0xa020298a
    acpi_pdump: P5: 800 MHz, 35000 mW, 125 uS s:0x280 c:0xa0202a80
    acpi_pdump: P6: 800 MHz, 35000 mW, 125 uS s:0x280 c:0xa0202a80
    acpi_pdump: P7: 800 MHz, 35000 mW, 125 uS s:0x280 c:0xa0202a80
    acpi_pdump: P8: 800 MHz, 35000 mW, 125 uS s:0x280 c:0xa0202a80
    acpi_pdump: P9: 800 MHz, 35000 mW, 125 uS s:0x280 c:0xa0202a80
    control_register:
    130 12 127 0 0 0 0
    status_register:
    130 12 127 0 0 0 0

And the powernow-p8 driver loads.

Perhaps this is an addition to the FAQ:

 Q609: AMD Cool&Quiet CPU won't load the powernow-k? driver.  Why?

 A609: The powernow driver gets it's information about processor
       states from the BIOS's reported ACPI control data.  If the
       powernow driver won't load it may be because Cool&Quiet hasn't
       been enabled in the BIOS.  Make sure that BIOS settings for a
       PowerNow or a Cool&Quiet option are enabled.

Or, maybe the driver should output a kernel message about BIOS
settings.

Cheers.

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

I am of the opinion that this is a bug in the ACPI subsystem.
The BIOS developers find it easy to always have the space
allocated for their tables. They "hide" them by tricks
such as changing _PSS to XPSS.

Paul.

> -----Original Message-----
> From: cpufreq-bounces@www.linux.org.uk 
> [mailto:cpufreq-bounces@www.linux.org.uk] On Behalf Of 
> Dominik Brodowski
> Sent: Tuesday, June 22, 2004 12:11 PM
> To: Marc Singer
> Cc: cpufreq@www.linux.org.uk
> Subject: Re: Athlon 64 complains of frequency mismatch
> 
> On Mon, Jun 21, 2004 at 02:42:36PM -0700, Marc Singer wrote:
> > I did fetch it.  There are no entries for _PSS or even PSS.
> 
> But an entry XPSS which contains these bogus entries...
> 
> 
>             Name (XPSS, Package (0x03)
>             {
>                 Package (0x06)
>                 {
>                     0x09999999,
>                     0x00099999,
>                     0x00999999,
>                     0x00999999,
>                     0x99999999,
>                     0x99999999
>                 },
> 
>                 Package (0x06)
>                 {
>                     0x09999999,
>                     0x00099999,
>                     0x00999999,
>                     0x00999999,
>                     0x99999999,
>                     0x99999999
>                 },
> 
>                 Package (0x06)
>                 {
>                     0x09999999,
>                     0x00099999,
>                     0x00999999,
>                     0x00999999,
>                     0x99999999,
>                     0x99999999
>                 }
>             })
> 
> 
> I'm surprised a) that the BIOS-provided tables contain such 
> obviously bogus
> data, and b) that XPSS is used by the ACPI subsystem instead 
> of reporting
> there is no _PSS.
> 
> Also, are there any entries in the BIOS you can toggle which might be
> related to "Cool&Quiet", "PnP-capable OS", ...?
> 
> 	Dominik
> 
> _______________________________________________
> Cpufreq mailing list
> Cpufreq@www.linux.org.uk
> http://www.linux.org.uk/mailman/listinfo/cpufreq
> 
> 
> 

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

> Perhaps this is an addition to the FAQ:
> 
>  Q609: AMD Cool&Quiet CPU won't load the powernow-k? driver.  Why?
> 
>  A609: The powernow driver gets it's information about processor
>        states from the BIOS's reported ACPI control data.  If the
>        powernow driver won't load it may be because Cool&Quiet hasn't
>        been enabled in the BIOS.  Make sure that BIOS settings for a
>        PowerNow or a Cool&Quiet option are enabled.
> 
> Or, maybe the driver should output a kernel message about BIOS
> settings.

Where is the FAQ ? I would like to read it :)

How about having the driver put out a message referring to go 
read the FAQ ?

Paul.

Re: Athlon 64 complains of frequency mismatch

[Marc Singer]

On Wed, Jun 23, 2004 at 12:43:51AM -0700, paul.devriendt@amd.com wrote:
> > Perhaps this is an addition to the FAQ:
> > 
> >  Q609: AMD Cool&Quiet CPU won't load the powernow-k? driver.  Why?
> > 
> >  A609: The powernow driver gets it's information about processor
> >        states from the BIOS's reported ACPI control data.  If the
> >        powernow driver won't load it may be because Cool&Quiet hasn't
> >        been enabled in the BIOS.  Make sure that BIOS settings for a
> >        PowerNow or a Cool&Quiet option are enabled.
> > 
> > Or, maybe the driver should output a kernel message about BIOS
> > settings.
> 
> Where is the FAQ ? I would like to read it :)
> 
> How about having the driver put out a message referring to go 
> read the FAQ ?

Hmm.  It's hard to read your response.  If you are being sarcastic
then perhaps I need to be more explicit.

--- linux/Documentation/cpu-freq/user-guide.txt_orig	2004-06-23 00:51:46.000000000 -0700
+++ linux/Documentation/cpu-freq/user-guide.txt	2004-06-23 00:52:35.000000000 -0700
@@ -71,6 +71,14 @@
 [*] Only if "ACPI Processor Performance States" are available
 to the ACPI<->BIOS interface.
 
+ Q: AMD Cool&Quiet CPU won't load the powernow-k? driver.  Why?
+
+ A: The powernow driver gets it's information about processor
+    states from the BIOS's reported ACPI control data.  If the
+    powernow driver won't load it may be because Cool&Quiet hasn't
+    been enabled in the BIOS.  Make sure that BIOS settings for a
+    PowerNow or a Cool&Quiet option are enabled.
+
 
 1.3 sparc64
 -----------

RE: Athlon 64 complains of frequency mismatch

[paul.devriendt]

> > > Or, maybe the driver should output a kernel message about BIOS
> > > settings.
> > 
> > Where is the FAQ ? I would like to read it :)
> > 
> > How about having the driver put out a message referring to go 
> > read the FAQ ?
> 
> Hmm.  It's hard to read your response.  If you are being sarcastic
> then perhaps I need to be more explicit.

No, I was not being sarcastic. Sorry for the confusion. I was 
suggesting that the driver should output a message referring to 
the FAQ rather than a message specifically about BIOS settings.

Paul.

RE: Athlon 64 complains of frequency mismatch

[Len Brown]

On Wed, 2004-06-23 at 03:43, paul.devriendt@amd.com wrote:
> I am of the opinion that this is a bug in the ACPI subsystem.
> The BIOS developers find it easy to always have the space
> allocated for their tables. They "hide" them by tricks
> such as changing _PSS to XPSS.

Feel free to file an ACPI bug here and I'll be happy to look into it:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Component: power-processor

It should describe the behaviour of the two configurations
A. Cool&Quiet enabled in BIOS
B. Cool & Quiet disabled in BIOS
and what is unexpected.

It should include the output from acpidmp taken in each configuration.
acpidmp is available in /usr/sbin/, or in pmtools:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Only with this can we tell what curve ball the BIOS is throwing.

thanks,
-Len