From: Jarod Wilson <jwilson@redhat.com>
To: "Ferdinand Hübner" <fh@cvmx.org>
Cc: cpufreq@lists.linux.org.uk
Subject: Re: CPU-Frequency limited to lowest available frequency while under load
Date: Thu, 01 Nov 2007 14:36:48 -0400 [thread overview]
Message-ID: <472A1CC0.5080409@redhat.com> (raw)
In-Reply-To: <1193941879.4202.17.camel@noname>
[-- Attachment #1.1: Type: text/plain, Size: 1873 bytes --]
Thomas Renninger wrote:
> Hi Ferdinand,
>
> I cut down the mail a bit...
> On Thu, 2007-11-01 at 19:07 +0100, Ferdinand Hübner wrote:
>> Thomas Renninger wrote:
>>
>>> It can be:
>>> 1) frequency limited by BIOS through _PPC
>>> 2) frequency reduced by thermal passive limit
>>> 3) some really odd cpufreq core bug
>>>
>>> >From the last bugs occurring in this area I expect it's 1.
>
>> I repeated the test a couple of times and the _PPC values have always
>> been 0 except for the last test I did. The value was 3 in the last test.
>> Does that mean that the BIOS is partially responsible?
> If the value is 3, the highest three freqs are not allowed by BIOS.
> This may be intended, probably not.
>
> IMO best is you open a bug at http://bugzilla.kernel.org to collect info
> at one place..., for now I'd assign it to the ACPI component.
>
> acpidump output should be most important atm, pls attach it there and
> take me into CC list.
>
> Is it possible for you to reproduce this easily?
> Maybe something you noticed like: it always happens after x mins or
> after loading module y...
> You could also try to not load other ACPI modules: battery, thermal,
> button, fan, ac.
> Maybe it does not happen then anymore?
I didn't pay much attention to earlier posts in this thread, so pardon
if this has already been covered, but...
I had a similar sounding case reported in the Red Hat bugzilla, where a
Dell laptop wouldn't scale above its minimum frequency if the system was
running on a travel charger. This turned out to be a limitation imposed
intentionally by the system BIOS (and documented somewhere on Dell's web
site). On battery and on the normal charger, the same system had no
problems whatsoever.
Just throwing it out there, ignore me if its irrelevant. :)
--
Jarod Wilson
jwilson@redhat.com
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
[-- Attachment #2: Type: text/plain, Size: 147 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq
next prev parent reply other threads:[~2007-11-01 18:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 10:23 CPU-Frequency limited to lowest available frequency while under load Ferdinand Hübner
2007-10-31 13:28 ` Thomas Renninger
2007-11-01 18:07 ` Ferdinand Hübner
2007-11-01 18:31 ` Thomas Renninger
2007-11-01 18:36 ` Jarod Wilson [this message]
2007-11-06 16:01 ` Ferdinand Hübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=472A1CC0.5080409@redhat.com \
--to=jwilson@redhat.com \
--cc=cpufreq@lists.linux.org.uk \
--cc=fh@cvmx.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.