Latest working kernel version: Don't know Earliest failing kernel version: Don't know Distribution: openSUSE, Ubuntu Hardware Environment: ASUS P5K (latest bios: 0902), Intel E2180, 2GB Ram Software Environment: Normal opensuse install Problem Description: The E2180 is spec'd to work with 200Mhz front side bus, and has 6x thru 10x multipliers, so, with speedstep, it should go from 1.2ghz to 2.0ghz, and that happens fine. The problem is, I overclocked the frontside bus to 313Mhz, (and still have speedstep enabled), so speeds should be between 1.88ghz and 3.13ghz, but the problem is cpufreq still reports the "available" speeds as being between 1.2 and 2.0ghz. I think this is only visual, since when booting the kernel says "Detected 3130.093 MHz processor.", but after booting, /proc/cpuinfo and other places all assume the aforementioned speeds. I've also tested, and this still happens on Ubuntu Herdy alpha 5 that uses 2.6.24.2, so this should be distro-unrelated. Steps to reproduce: Overclock the FSB, and check reported cpufreq speeds.
Created attachment 15105 [details] cat /proc/cpuinfo
Created attachment 15106 [details] acpidump output
Created attachment 15107 [details] dmesg I'm using nvidia binary module, but this happens when I use other kernels and the nv opensource driver, so it's not related.
Created attachment 15108 [details] cpufreq-info output
This ACPI device looks quite powerful, it seems to be a new ASUS specific ACPI device we do not support yet: Device (ASOC) { Name (_HID, "ATK0110") Maybe Corentin knows more about this machine, do you know about this device? There also overclocking data and much more is included... The cpufreq tables are included in another table that gets loaded at runtime. Hopefully you can fetch them via: acpidump --addr 0x7FF8E0D0 --length 0x0214 >ssdt_table_cpu0.dump acpidump --addr 0x7FF8E2F0 --length 0x0143 >ssdt_table_cpu2.dump Two should be enough..., can you attach these (best each and as plain text, that's easier to handle). Hmm before you attach new tables, you should make sure you run the latest BIOS. If not and you still have problems, better re-attach acpidump. CPUfreq problems often get resolved with a BIOS update on rather new machines.
I just confirmed, release "0902" is the latest version of the bios. I don't know if this is related to the device you are referring, but I have an option in the bios called "ACPI Version" that is enabled, and it's description says "Add additional tables as per ACPI 2.0 specifications". I've tried disabling it and the cpufreq result is the same as with it enabled.
Created attachment 15112 [details] acpidump --addr 0x0D0 --length 0x0214x0143 >ssdte_cpu0.dump
Created attachment 15113 [details] acpidump --addr 0x2F0 --length 0x0143x0143 >ssdte_cpu2.dump
if you overclock, you pretty much give up all hope of having the BIOS do the right thing. See http://www.codemonkey.org.uk/projects/cpufreq/common.php
Forgive me if what i'm saying is stupid and obvious, but that site mentions that "Other than measuring the speed every time a transition occurred (which isn't feasible as it would incur a noticable performance overhead), it isn't possible for cpufreq to know the current speed if it doesn't match what the BIOS tables tell it that multiplier maps to." My understanding is that speedstep works by lowering the cpu multiplier, while keeping other things constant (not sure about proc voltage, but they don't matter much to this problem), so I have displayed 1.2, 1.6 and 2.0 ghz corresponding to the even multipliers 6x, 8x and 10x on my processor (not sure why the odd ones aren't used). Now if we were to get the real maximum speed (real_max_speed), that is multiplier * frontsidebus, and divide it by the maximum speed on the bios tables (bios_max_speed), we would get basically (multipler/multiplier)*(overclockedFSB/ratedFSB). Now overclockedFSB/ratedFSB is a constant because speedstep doesn't touch the fsb, in my case it is 313/200 = 1.565. Wouldn't it be possible to obtain this constant once, and then use it to correct the shown possible speeds? Eg, instead of 1.2, 1.6, 2.0 as reported by the bios, we would have 1.2*constant, 1.6*constant, 2.0*constant ghz, that should be the correct speed the processor is working at, when overclocked. When not overclocked, constant = 1, so no problem there (probably it would be 1.0000001 or something like that, but there could be a test and only consider the difference if it's greater than x %). Again, sorry if none of this makes sense, maybe i'm reading it wrong :)
Don't know this machine, can you join a cat /proc/acpi/dsdt please ?
Created attachment 15120 [details] cat /proc/acpi/dsdt
Well, overclocking isn't supported by cpufreq, so getting "wrong" frequency measurements isn't at all surprising. Is this a valid bug?
But if it works almost perfectly, and the only problem is the speed displayed, why simply say "we don't support it"? Are there really that many changes for cpufreq when the processor is under- or overclocked. I for one, think that cpufreq is *more* important when overclocking: my cpu is working at a lower frequency and cooler when idle, and only works at a higher frequency when needed, instead of all the time.