Most recent kernel where this bug did not occur: 2.6.22.6 (have not tried earlier) Distribution: mainline Hardware Environment: cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3000+ 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: Giga-byte Technology GA-K8N Ultra-9 Mainboard Software Environment: kernel + debian stable (4.0r(today)) + some compiled updates like recent pm-utils to grab acpidump Problem Description: powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3000+ processors (version 2.00.00) ACPI Exception (processor_perflib-0234): AE_NOT_FOUND, Evaluating _PSS [20070126] powernow-k8: BIOS error - no PSB or ACPI _PSS objects Steps to reproduce: get the hardware, compile kernel, modprobe powernow-k8 (every probe complains)
Created attachment 12856 [details] acpidump
Created attachment 12857 [details] dmidecode
Created attachment 12858 [details] lspci
Created attachment 12859 [details] config.gz
looking at the error message from dmesg and the bios date in dmidecode... anyone of you guys could confirm: Is this just bios being too old for this processor or is the problem in the kernel-acpi use?
BIOS Information Vendor: Award Software International, Inc. Version: F2 Release Date: 01/14/2005 BIOS date looks fine, ACPI should certainly be enabled on this board. Looking at the acpidump, the code to support P-states appears to be some sort of template that the programmer never filled in -- as the values are generally all -1 or 0, and there is no _PSS present. Scope (\_PR.CPU0) { Name (_PCT, Package (0x02) { ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) }, ResourceTemplate () { Register (FFixedHW, 0x00, // Bit Width 0x00, // Bit Offset 0x0000000000000000, // Address ,) } }) Method (_PPC, 0, NotSerialized) { Return (0x00) } Name (PPSS, Package (0x05) { Package (0x06) { 0xFFFF, 0xFFFFFFFF, 0xFF, 0xFF, 0xFFFFFFFF, 0x03FF }, ... Further, there is no SSDT or Load() statements in this DSDT to extend the AML, and so there is no ACPI support for P-states in this BIOS. See if a BIOS upgrade is available which does include ACPI support for P-states, or work with the native support in the k8 driver. This is not a Linux/ACPI bug.
Yep. The BIOS definetly misses cpufreq information. Drtyc: Search for a BIOS update, chances are high that this processor is recognised with it and valid cpufreq info is passed. If not you might want to tell us, someone should at least ask at gigabyte to update their BIOS info.
As this is a BIOS issue we cannot do anything about -> closing as won't fix.
Ok. Found update - my fault that I should have noticed that earlier. v.F2 2005/01/14 -> v.F8 2005/12/05 Let you know if I experience any "different" acpi exception. Anyway the board is slowly becoming historic model... Thanks for your time and effort.