Athlon 64 complains of frequency mismatch
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
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.
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 lineobj-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.
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:0x99999999acpi_pdump: P1: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P2: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P3: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P4: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P5: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P6: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P7: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P8: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P9: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999control_register:
130 12 127 0 0 0 0status_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/acpiinterface 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
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/acpiinterface and running it through Intel's decompiler? That's where I've started to go.
Quoted 7 lines
Not really --
acpi_pdumpdumps what's received by the powernow-k8 driver from the ACPI subsystem, while decompiling/proc/acpi/dsdtprints 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_PSSentries (grep -20_PSS)?
I did fetch it. There are no entries for _PSS or even PSS.
Quoted 2 lines
Thanks,
Dominik
Quoted 1 line · Marc Singer
I did fetch it. There are no entries for
_PSSor 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
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 0And 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.
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 lineobj-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: 10acpi_pdump: P0: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P1: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P2: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P3: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P4: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P5: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P6: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P7: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P8: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999acpi_pdump: P9: 161061273 MHz, 629145 mW, 10066329 uS s:0x99999999 c:0x99999999 control_register:
130 12 127 0 0 0 0status_register:
130 12 127 0 0 0 0
Is this really helpful?