Most recent kernel where this bug did not occur: NA
Distribution: Ubuntu 7.04
Hardware Environment: Intel Core Duo 2, Foxconn "946GZ7MA-1.1" motherboard
Steps to reproduce:
sudo modprobe acpi_cpufreq
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.20-16-generic/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device
Created attachment 12455 [details]
dmesg output. includes debug output from loading acpi_cpufreq
Created attachment 12457 [details]
This is a new computer. A piece of paper came with it insisting that it had been flashed to the latest available BIOS version.
The BIOS has an option for "Enhanced Intel Speedstep Technology", which is enabled.
Created attachment 12458 [details]
Using <http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20070714-debug.tar.gz> as suggested in the similar bug #8630.
Looking at the diff between acpidump and acpidump.debug, I guess the same bug is responsible for the hpet error:
[ 22.623044] PM: Adding info for No Bus:hpet
[ 22.623240] hpet_acpi_add: no address or irqs in _CRS
and the lack of C-state support (no C-states shown in /proc/acpi/processor/CPU0/power
Can't test further until Wednesday - I'm waiting for a replacement to the power supply that exploded yesterday.
The force rsdt patch (attachment id=12468) does what it's supposed to. The hpet is detected now, and cpufreq works as far as I can tell. So this bug is definitely the same as #8630.
*** This bug has been marked as a duplicate of bug 8630 ***
The reason that this system reports no C-states deeper
than C1 is because that is what the BIOS tells us:
[05Fh 095 1] _CST Support : 00
[060h 096 2] C2 Latency : 0065
[062h 098 2] C3 Latency : 03E9
x65 and x3e9 are 101 and 1001, which explicitly disable C-states.
_CST=0 (and the absence of _CST in the SSDT) tells us that
it isn't available either.
This isn't too surprising, as very few desktop processors today
ship with C-states deeper than C1.