Bug 497938
| Summary: | [RHEL4] Strange cpufreq Entries in sysfs on AMD Quad-Core Systems | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Qian Cai <qcai> | ||||||
| Component: | kernel | Assignee: | Bhavna Sarathy <bnagendr> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 4.8 | CC: | bhavna.sarathy, dhoward, jarod, jfeeney, jplans, kzhang, peterm, rdoty, sghosh | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 497939 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-01-27 04:01:06 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 497939 | ||||||||
| Attachments: |
|
||||||||
|
Description
Qian Cai
2009-04-28 00:29:21 UTC
Are we sure that the individual cores in the quad core machines aren't scalable? affected_cpus appears correct on the dual core system I tested earlier. On sun-x4600m2-01 I appear to be able to set the frequencies of the cores individually, which suggests that it's correct for affected_cpus to only contain one core. I think we can close this bug. Indeed, it does seem the latest generation of Opteron procs can have their cores scaled individually. Didn't know that. http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_15224,00.html Affected_cpu's is defined as all the CPUs that are changed when any CPU in that group is changed. Greyhound cores have independent frequency control, so each core should have its own number and not effect any other cores. Not a bug. One thing is strange on this system is that some cores even have different available frequences, is that normal? # cat /sys/devices/system/cpu/*/cpufreq/scaling_available_frequencies 2300000 2000000 1700000 1400000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 2300000 2000000 1700000 1400000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 but they are the same type of CPUs as far as I can tell. # grep 8356 /proc/cpuinfo model name : Quad-Core AMD Opteron(tm) Processor 8356 ... # grep 8356 /proc/cpuinfo | wc -l 32 Another strange thing is that we can change the frequency to some values should not be allowed. # cat /sys/devices/system/cpu/cpu28/cpufreq/scaling_cur_freq 1150000 # cat /sys/devices/system/cpu/cpu28/cpufreq/scaling_available_frequencies 2300000 2000000 1700000 1400000 1200000 The following output might be easier to follow. # cat */scaling_available_frequencies cpu0: 2300000 2000000 1700000 1400000 cpu1: 2300000 2000000 1700000 1400000 1200000 cpu2: 2300000 2000000 1700000 1400000 1200000 cpu3: 2300000 2000000 1700000 1400000 1200000 cpu4: 2300000 2000000 1700000 1400000 1200000 cpu5: 2300000 2000000 1700000 1400000 1200000 cpu6: 2300000 2000000 1700000 1400000 1200000 cpu7: 2300000 2000000 1700000 1400000 1200000 cpu8: 2300000 2000000 1700000 1400000 1200000 cpu9: 2300000 2000000 1700000 1400000 1200000 cpu10: 2300000 2000000 1700000 1400000 1200000 cpu11: 2300000 2000000 1700000 1400000 1200000 cpu12: 2300000 2000000 1700000 1400000 1200000 cpu13: 2300000 2000000 1700000 1400000 1200000 cpu14: 2300000 2000000 1700000 1400000 1200000 cpu15: 2300000 2000000 1700000 1400000 1200000 cpu16: 2300000 2000000 1700000 1400000 1200000 cpu17: 2300000 2000000 1700000 1400000 1200000 cpu18: 2300000 2000000 1700000 1400000 1200000 cpu19: 2300000 2000000 1700000 1400000 1200000 cpu20: 2300000 2000000 1700000 1400000 1200000 cpu21: 2300000 2000000 1700000 1400000 1200000 cpu22: 2300000 2000000 1700000 1400000 1200000 cpu23: 2300000 2000000 1700000 1400000 1200000 cpu24: 2300000 2000000 1700000 1400000 1200000 cpu25: 2300000 2000000 1700000 1400000 1200000 cpu26: 2300000 2000000 1700000 1400000 1200000 cpu27: 2300000 2000000 1700000 1400000 1200000 cpu28: 2300000 2000000 1700000 1400000 1200000 cpu29: 2300000 2000000 1700000 1400000 cpu30: 2300000 2000000 1700000 1400000 cpu31: 2300000 2000000 1700000 1400000 Do you think the above 2 problems, - different avaiable frequencies for cores in the same package - comment #7 - can change the frequency to something should not allowed - comment #6 might a bug in hardware/BIOS? It's defintely looking that way. I tested on my quad core system with 8 cores and didn't see the issues you list. I certainly don't have access to a 32 core system. Please look into upgrading the BIOS on your system and retest. Bhavna, Andrew Crosson has helped upgrade the system to, BIOS 126 (0ABIT126) and the ILOM is updated to firmware 3.0.3.31, Build 42822. However, the problem is still here. - different avaiable frequencies for cores in the same package - comment #7 - can change the frequency to something should not allowed - comment #6 The affected machine is in RHTS, so you can reserve it from there. Let me know if need any assistant. sun-x4600m2-01.rhts.bos.redhat.com (In reply to comment #6) > Another strange thing is that we can change the frequency to some values should > not be allowed. > # cat /sys/devices/system/cpu/cpu28/cpufreq/scaling_cur_freq > 1150000 > # cat /sys/devices/system/cpu/cpu28/cpufreq/scaling_available_frequencies > 2300000 2000000 1700000 1400000 1200000 Can you clarify your statement? I'm not sure if you mean you can change the frequencies and it shouldn't be allowed or something else. Bhavna, sorry I have not made myself clearly. what I mean was that why one of CPUs was running in the speed of 1150000, which was not one of values in scaling_available_frequencies as you can see from the above? Is this still an issue? The problem at the moment even after the firmware upgrade is, - different avaiable frequencies for cores in the same package - comment #7 - can running into the frequency to something not listed - comment #6 Hi Bhavna,
I looked into the function fill_powernow_table_pstate(), and found that it get the info from rdmsr(MSR_PSTATE_DEF_BASE + index, lo, hi); then did some computation to get the frequency.
static int fill_powernow_table_pstate(struct powernow_k8_data *data, struct cpufreq_frequency_table *powernow_table)
{
-------------cut-------------------------
rdmsr(MSR_PSTATE_DEF_BASE + index, lo, hi);
if (!(hi & HW_PSTATE_VALID_MASK)) {
printk("==invalid pstate %d, ignoring\n", index);
powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
continue;
}
fid = lo & HW_PSTATE_FID_MASK;
did = (lo & HW_PSTATE_DID_MASK) >> HW_PSTATE_DID_SHIFT;
powernow_table[i].index = index | (fid << HW_FID_INDEX_SHIFT) | (did << HW_DID_INDEX_SHIFT);
powernow_table[i].frequency = find_khz_freq_from_fiddid(fid, did);
---------------------cut-----------------------
}
don't know why, when index is 4, "lo" got from rdmsr does not always the same, 28 out of 32 it is 0x8, but the other 4 it equals to 0x7, this leads to the computed freq got from find_khz_freq_from_fiddid does not equal to which got by ACPI. this is why "cat */scaling_available_frequencies" displays disaccord.
while in RHEL5.4 kernel, fill_powernow_table_pstate did a big change, and freq is no longer got through rdmsr(although rdmsr is still invoked, but it is not used to get freq).
Bhavna, is there possibility that the cpu MSR does not work properly? need to replace the CPU?
Is this occurring on RHEL 5, or just on RHEL 4? on latest RHEL5.4, kernel is 2.6.18-152.el5, freqs for all cpus are same: [root@sun-x4600m2-01 ~]# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 2300000 2000000 1700000 1400000 1200000 This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Created attachment 416988 [details]
Patch to fix this issue by removing code that reads the MSRs
This driver hasn't been updated in a while, so there was a fair bit of old code in it that needed to be removed.
This patch fixes the reported problem by removing some MSR reads against some non-architectural MSRs that would change between processor revisions. Instead, it relies on the ACPI _PSS objects to get frequency information.
Created attachment 442240 [details]
Patch to fix this issue by removing code that reads the MSRs
Fixed some formatting errors in the patch.
|