Description of problem: cpufreq do not work on Harwich platform. Harwich (with 4x Xeon 3.2G, dual cores). BIOS verison: SHW40.86B.P.11.00.0070.121920060947 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. enable EIST in BIOS 2. boot RHEL4.7 3. ls /sys/devices/system/cpu/cpu0/ cpu0 is empty directory. Actual results: Expected results: Additional info:
Created attachment 308363 [details] Patches to fix acpi cpufreq driver load fail and cpu frequencey change fail
I backport a patche acpi_cpufreq_add_acpi_perf_data_and_software_coordination.patch can fix the bug. I valiate on Harwich platform, cpufreq work round with this patch.
Can you let me know where you backported the patch from? What git commit had this patch?
RHEL4.7 kernel include a large patch to acpi-cpufreq driver(acpi.c) with the patch name: linux-2.6.9-x86-acpi-pstate.patch. But kernel patch with this patch, has two bugs: 1) acpi.ko fail to load because data->acpi_data is NULL pointer entry parameter in acpi_processor_register_performance function (acpi.c). 2) After fix the 1) bug, acpi.ko is load correctly, but the cpu frequencey can not be changed because the acpi.c do not record the the cpu depenedency for software coordination. So, I fix these two bugs to enable acpi cpufreq driver. After patch acpi_cpufreq_add_acpi_perf_data_and_software_coordination.patch to kernel-2.6.9-70ELsmp, the acpi-cpufreq can be loaded and cpu frequencey can be changed with workload change or user different setting on Harwich. The patch source codes include in acpi-cpufreq.c(acpi.c rename to acpi- cpufreq.c), but these code include in different git commits.
Updating PM score.
Youquan, Is your last patch posted still current? Just wondering if we need to update anything. Matthew, Is there anything else you need from Intel in order to fix this bug?
No change to the patches till now.
I believe this to have been fixed by the patches from 458156 and 440267, which add the same code. See commits 13409a6d90bf438226518b6f453af56043aa75f9 and 970e6d7ee5faccb5e0fdfdd2288ad25ae8b3d9d7.
Youquan, Can you see if Bug 458156 and Bug 440267 have added the same code as your patches?
I can not access the bug 440267, so I can not check it. Can you grant me access priority?
Youquan, Can you provide a Harwich for me to experiment with? If there is one in RHTS, please reserve it and send me the root info.
Harwich truland, processor Xeon 7130 3.2GHz. BIOS: SHW40.86B.P.11.00.0070.121920060947 I am sure that RHTS has this machine. Verify that 2.6.9-78.24.EL can fix this bug. The patches for Bug 458156 and Bug 440267 is mostly the same as my patch.
Youquan, Are you saying that 2.6.9-78.24 fixes the bug, or are you saying that you need it to be tested?
Yes. I mean that I verify that 2.6.9-78.24 fix the bug.
Martin, Are you going to verify if the bug really fixed? Thanks, Luming
I finally get access to a system from RHTS: intel-s3e8132-01.rhts.bos.redhat.com It is said that this system could be Harwich... With RHEL4.8 installed, there is still an empty /sys/devices/system/cpu/cpu0/ on this system. I tried to check EIST in BIOS, but there are problems *unresolved* to do that through remote console just by pressing <DEL>. I'm working with RH trying to find a solution..
Thanks for John's great help, I got a Harwich.. I can see these info on harbinger.lab.bos.redhat.com. [root@harbinger ~]# cat /proc/version Linux version 2.6.9-82.ELlargesmp (mockbuild.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)) #1 SMP Wed Feb 25 12:57:24 EST 2009 [root@harbinger ~]# ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus scaling_available_governors scaling_max_freq cpuinfo_max_freq scaling_cur_freq scaling_min_freq cpuinfo_min_freq scaling_driver scaling_setspeed scaling_available_frequencies scaling_governor So, sounds like the symptom of the bug has gone with 2.6.9-92 kernel.