[Bug 410533] New: ondemand govenor does not set maximum frequency when on battery
https://bugzilla.novell.com/show_bug.cgi?id=410533 Summary: ondemand govenor does not set maximum frequency when on battery Product: openSUSE 11.0 Version: Final Platform: i386 OS/Version: openSUSE 11.0 Status: NEW Severity: Major Priority: P5 - None Component: Mobile Devices AssignedTo: zoz@novell.com ReportedBy: pablo@blueoakdb.com QAContact: qa@suse.de Found By: --- Hi, On openSUSE 11.0/RC3, I reported an issue with my laptop (see bug 399068) similar to this one. At that time, the end result was that the maximum CPU frequency _eventually_ was set (after 17 seconds). I mention it now because there seems to be a regression between RC3 and Final but I'll leave it up to you folks to decide. Today I was on battery and noticed a CPU bound process wasn't kicking the maximum CPU frequency (2.4GHz); it stayed at 800Mhz. This was after being on battery for many minutes (well beyond the 17 second threshold from bug 399068). What's interesting is for an initial short burst (less than a second), the CPU frequency spikes to the maximum and afterwards, it stays at the minimum. Further, upon stopping the CPU bound process it takes about 13 seconds before the maximum is reset from 800MHz to 2.4GHz; note there is nothing else running after the CPU bound process is terminated. I collected some instrumentation below to show exactly what I'm talking about. Please let me know if you need additional data. ps: I'm heading out on vacation for a week so if I don't respond, it's because I'll be away and not because I'm ignoring the problem. :) Experiment ========== In one shell, I run the following to monitor my CPU frequency bounds: while [ 1 ] ; do date; cpufreq-info | grep 'current policy:'; sleep 1; done and in another shell, my CPU bound process: while [ 1 ] ; do echo x; done Here's the result of the monitoring - see in-line comments for additional data: Fri Jul 18 14:36:56 EDT 2008 current policy: frequency should be within 800 MHz and 2.40 GHz. current policy: frequency should be within 800 MHz and 2.40 GHz. Fri Jul 18 14:36:57 EDT 2008 current policy: frequency should be within 800 MHz and 2.40 GHz. current policy: frequency should be within 800 MHz and 2.40 GHz. # # Start CPU bound process # Fri Jul 18 14:36:58 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:36:59 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:00 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:01 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. # # Stop CPU bound process - notice delay until # the maximum frequency is reset - this may be related # to bug 399068. # Fri Jul 18 14:37:02 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:03 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:04 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:05 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:06 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:07 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:08 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:09 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:10 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:11 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:12 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. Fri Jul 18 14:37:13 EDT 2008 current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. # # Maximum CPU reset to correct value. # Fri Jul 18 14:37:14 EDT 2008 current policy: frequency should be within 800 MHz and 2.40 GHz. current policy: frequency should be within 800 MHz and 2.40 GHz. Fri Jul 18 14:37:15 EDT 2008 current policy: frequency should be within 800 MHz and 2.40 GHz. current policy: frequency should be within 800 MHz and 2.40 GHz. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=410533 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=410533#c2 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Thomas Renninger <trenn@novell.com> 2008-07-30 08:49:22 MDT --- Please check: - for a BIOS update - For a BIOS option that limits frequency in battery case (could also be called "powersave option for battery mode" or whatever... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=410533 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |pablo@blueoakdb.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=410533 User pablo@blueoakdb.com added comment https://bugzilla.novell.com/show_bug.cgi?id=410533#c3 Pablo Sanchez <pablo@blueoakdb.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|pablo@blueoakdb.com | --- Comment #3 from Pablo Sanchez <pablo@blueoakdb.com> 2008-07-30 09:51:33 MDT --- Lo and behold, on 7.28 A12 became available. I flashed my BIOS from A11 to A12. After this flash, the problem remained. Per your suggestion, I hunted around the BIOS and found `Performance > Dynamic Acceleration' enabled. I turned it `off' and retried the test. Same results. Next, keeping `Dynamic Acceleration' disabled, I disabled `Performance > SpeedStep' but this resulted in the CPU not having any stepping ability. :) One thing I noticed this time around is if run the test for a long time, I do see in my polling window the frequency bounds set to 800 MHz and 2.40 GHz for one cycle, then it reverts again to 800/800. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=410533 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=410533#c4 Thomas Renninger <trenn@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #4 from Thomas Renninger <trenn@novell.com> 2008-08-14 09:00:06 MDT --- Then it seems to be intended by BIOS that when on battery to lower cpufreq or it is a BIOS bug. processor.ignore_ppc=1 boot param can workaround it. Hmm, you should better ask the vendor whether the battery requires lower power consumption, just to be sure you do not damage (unlikely..., but still) any HW. -> pretty sure a BIOS issue. If the limit gets activated at boot time, then there might be a fix in the latest kernels and 11.1 and also 11.0 should work for you soon. See bug #374099. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=410533 User pablo@blueoakdb.com added comment https://bugzilla.novell.com/show_bug.cgi?id=410533#c5 Pablo Sanchez <pablo@blueoakdb.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Pablo Sanchez <pablo@blueoakdb.com> 2008-08-14 17:11:11 MDT --- Hi Thomas, Thank you for getting back to me. Your suggestion of using "processor.ignore_ppc=1 boot param can workaround it" indeed worked around the issue. Thank you! Given I'm a small fish in Dell's huge pond, I very much doubt I can ask for for them to fix their issue. <Philosophical>I believe like some issues found on Linux, on Linux we have to work-around them. Not until we have large enough market-share.</Philosophical> Your suggestion to use the latest kernel dovetails well with my above philosophical point! <g> I'll close this bug. Cheers! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com