Bugzilla – Bug 113112
DBS doesn't work anymore on Pentium-D
Last modified: 2006-02-03 09:20:03 UTC
On a Pentium D/Glenwood SDV (D3C4601) DBS doesn't work anymore with 10.0. Frequency always stays at 3.2Ghz. It worked with SLES9-SP2 (frequency goes down to 2.8Ghz when idle). The problem doesn't seem to be in user space with powersaved, because even setting the speed manually in /sys using scaling_setspeed for one CPU doesn't do anything The mainline rc7 kernel has the same problem. The kernel is a 2.6.13rc6 10.0 kernel with no changes in this area compared to mainline. The ACPI cpufreq module gets loaded and reports success: acpi-cpufreq: CPU0 - ACPI performance management activated. acpi-cpufreq: CPU1 - ACPI performance management activated. acpi-cpufreq: CPU2 - ACPI performance management activated. acpi-cpufreq: CPU3 - ACPI performance management activated. and it also reports the available frequencies in /sys alberich:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_frequencies 3200000 2800000 alberich:/sys/devices/system/cpu/cpu0/cpufreq # cat scaling_available_governors ondemand userspace powersave performance Configured governour was userspace, but it also didn't work with ondemand.
I was able test this on a glenwood system locally. But, GV3 seems to fail on that system both with 2.6.13-rc6 and onlder 2.6.10 kernel as well. Things seem to work only on CPU0. For all the other CPUs, transition fails both with ondemand and userspace governor. In that sense, I think it is not a problem specific to ondemand as even userspace fails (I guess summary of this bugzilla needs to change to reflect that. Are you sure that things used to work with SLES9-SP2 on the same system with same BIOS? I will look at this closer tomorrow and try to root cause this one. Thanks.
Yes, SLES9 definitely works - or at least /proc/cpuinfo reports all cpus at 2.8Ghz after boot. I hope it's not lying. I didn't claim this to be an ondemand bug, I just first suspect ondemand so I disabled it, but that didn't help.
This is presumably a bug in BIOS. I got the latest BIOS for this board and the problem went away. With the latest BIOS ((Version BK95510J.86A.1784) all the 4 CPUs change the frequency successfully both with ondemand and with userspace governor. You should be able to get the latest BIOS from premier.intel.com. I got my BIOS from here (http://support.intel.com/design/motherbd/bk/bk_bios.htm). The link for BIOS download is hidden in a document D3C4602_Linux_Installation_procedure.pdf is available in downloads for this particular system. Let me know if it doesn't work with this latest BIOS.
Ok I can try that .But why did SLES9 work with the old BIOS?
Yes. I am not sure about SLES9 either. Probably there was some other bug in /proc/cpuinfo and its frequency output?
It didn't look buggy to me - started at 2.8Ghz and when I started a CPU hog all the CPUs went to 3.2Ghz in cpuinfo (as expected because it's a single sockegt)
Actually, /proc/cpuinfo frequency output is bogus and still needs fixing. It just reports "cpu_khz". There is no per_cpu'ness in its output. But, that code looks unchanged to me. So, I don't know why the difference is there. Do you remember seeing some at 2.8 and some at 3.2. Or were all of them at 2.8 or all of them were at 3.2? With the current OS and BIOS, we do what is called BIOS coordinated P-state, in which case BIOS does all the coordination across cores/threads. OS, still thinks each logical processor is independent and can change the frequency on its own. So, if you just run one CPU hog, only one CPU will go to highest frequency. ACPI 3.0 has support for Software coordination, where in OS will do the above coordination and we will know at what frequency each CPU is running at. I am almost through with the code to support that. Once we have that and the required BIOS support for it, we will see all the logical CPUs of a package changing the frequency at once.
All CPUs changed frequency in parallel. So all 2.8 or all 3.2.
I upgraded to the lastest BIOS (BK95510J.86A.1959.2005.0826.1723) now but the CPU speed in 10.0 still stays at 3.2Ghz. So something is still broken.
Some more information. The difference between the 10.0 kernel and SLES9 is that 10.0 just reports acpi-cpufreq: CPU0 - ACPI performance management activated. acpi-cpufreq: CPU1 - ACPI performance management activated. acpi-cpufreq: CPU2 - ACPI performance management activated. acpi-cpufreq: CPU3 - ACPI performance management activated. while SLES9 reports cpufreq: CPU0 - ACPI performance management activated. cpufreq: *P0: 3200 MHz, 89000 mW, 160 uS cpufreq: P1: 2800 MHz, 67729 mW, 160 uS cpufreq: CPU1 - ACPI performance management activated. cpufreq: *P0: 3200 MHz, 89000 mW, 160 uS cpufreq: P1: 2800 MHz, 67729 mW, 160 uS cpufreq: CPU2 - ACPI performance management activated. cpufreq: *P0: 3200 MHz, 89000 mW, 160 uS cpufreq: P1: 2800 MHz, 67729 mW, 160 uS cpufreq: CPU3 - ACPI performance management activated. cpufreq: *P0: 3200 MHz, 89000 mW, 160 uS cpufreq: P1: 2800 MHz, 67729 mW, 160 uS
Just to be sure it's not because the SSDT table is not loaded: Is there a message like: nsload-0141: *** Warning: Table CPU1PM has already been loaded (not bad) in /var/log/messages?
No such message. I guess i'll add some printks and try to figure out what's wrong.
This is strange. It works fine on my system with 2.6.13 kernel. Is there a place where I can downlod kotd for SUSE 10. I can try that kernel on my system and try to reproduce this one.
ftp://ftp.suse.com/pub/projects/kernel/kotd/x86_64/HEAD
I tested it now on a Coyote (with Nocona CPUs) and DBS also doesn't work there anymore. So it looks like a systematic problem. Venki, are you sure it works for you?
Yes. I just saw this issue on Nocona today and root caused it. Its a BIOS issue and fix is on its way. That got exposed by recent change in kernel to support SMP C-states. I will try to have a workaround for the time being and post it here in a day or two. I am not sure at this moment whether the Pentium D issue is also similar one. I have to look at acpidump and figure it out. I will do it tomorrow.
Created attachment 49252 [details] skip NULL _PDC writes Attached patch worksaround the P-state regression on Coyote with 2.6.13. The actual bug is in BIOS and I am working with the BIOS folks to get it fixed. If this workaround doesn't have any side-effects on any other systems, then we can have it in kernel as well, just to be safe against buggy BIOSes.
Things seem to work perfectly for me on Pentium D system with 20050902175209 kotd. All CPUs go to 2.8 when idle, and as I run multiple instances of a CPU intensive program one by one, all CPUs go to 3.2 GHz one by one. And as I kill the cpu hogs, all cpus come back to 2.8. This with both ondemand and userspace governors. So, there is some difference between Pentium D system here and Pentium D system that Andi has. Andi: Can you try whether patch in comment #17 makes any difference for you on this system?
Sorry for the delay. The patch didn't apply to HEAD and with it hand applied i see no difference on either the Coyote or the Pentium-D :-( I tested with a static config (arch/x86_64/defconfig) with ACPI cpufreq and setting the lower speed manually with powersave -l Also just tested kotd 20050912152055 again on the P-D and it also doesn't seem to work. I must admit my P-D is preproduction (A-1 I think) and has a few other quirks, but at least with SLES9 DBS has always worked fine. That the Coyote doesn't work is also a bit worrying. Thomas, do you see DBS working on some Intel Xeon machines?
Yes. DBS not working on Xeon is a serious issue. I am downloading the latest kotd right now. Will try it on Xeon system here in the lab and let you know how it goes.
Created attachment 49858 [details] _PDC skip workaround for kotd kernel. Tested kotd (20050912152055) on few Xeon systems here. Kernel was X86_64, built with my own config (as I wanted to avoid building modules). Result: - With kotd, Speedstep didn't work on Coyote (with Irwindale CPUs) system. - I applied the attached patch to kotd, and speedstep worked on the same system (Coyote with Irwindale - 3.6, 3.2, 2.8 GHz). - I tried the kernel with patch on another Coyote with Nocona processors. Things worked fine on that system (3.4 and 2.8 GHz). - I also tried it on a Harwich (MP - with Potomac CPUs) and things worked fine on that system as well. I will try to change the options in my config to match the defconfig (atleast in Power Management section) and see whether that makes any difference. Andy: Meanwhile can you please get cpufreq.debug from your system. That should give us some more clues about where things are going wrong. Thanks.
I guess it's obsolete now. 10.1 seems to work and I doubt we'll do an update for 10.0 for this.