Bug 9035
Summary: | cpufreq k8 module trouble during modprobe on gigabyte board | ||
---|---|---|---|
Product: | Power Management | Reporter: | Drtyc (drtyc) |
Component: | cpufreq | Assignee: | Thomas Renninger (trenn) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.22.6 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump
dmidecode lspci config.gz |
Description
Drtyc
2007-09-18 14:37:19 UTC
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. |