Skip to contentSkip to conversation

Athlon 64 complains of frequency mismatch

DISCUSSION Marc Singer 2 participants 8 messages Jun 18, 2004 – Jun 22, 2004

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

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

Quoted 3 lines · 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.

#2 lore raw
Quoted 15 lines · 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

Quoted 7 lines

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.

#3 lore raw
Quoted 20 lines · Marc Singer

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

Quoted 1 line

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?

Quoted 4 lines

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

#4 lore raw
Quoted 3 lines · Dominik Brodowski
Quoted 1 line

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.

Quoted 5 lines
Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

Thanks,
Dominik

#5 lore raw
Quoted 1 line · Marc Singer

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

#6 lore raw
Quoted 2 lines · Dominik Brodowski

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.

#7 lore raw
In reply to Dominik Brodowski
Quoted 17 lines · 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,

Quoted 8 lines

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?