From: dual_bereta_r0x <dual_bereta_r0x@arenanetwork.com.br>
To: Dominik Brodowski <linux@dominikbrodowski.de>
Cc: linux-kernel@vger.kernel.org, cpufreq@www.linux.org.uk
Subject: Re: 2.6.2: P4 ClockMod speed
Date: Thu, 26 Feb 2004 01:28:51 +0000 [thread overview]
Message-ID: <403D4BD3.7050703@arenanetwork.com.br> (raw)
In-Reply-To: <20040217090939.GA9935@dominikbrodowski.de>
Dominik Brodowski wrote:
>
> That's not the point: some hardware (e.g. ARM) needs different memory
> settings and different settings of the LCD controller for different
> CPU frequencies, as the Front Side Bus of the CPU is closely related
> to the CPU frequency. On x86, all cpufreq techniques I've
> seen so far do not modify the FSB [*], so memory settings etc. do not need
> to be modified.
>
> Dominik
>
> [*] or scaling the FSB didn't work...
In x86 world, this info is wrong. The *multiplier* is locked inside
processor (Intel P4) or by some "dips" on cpu core (AMD Athlon XP) --
unless you have such as "enginering samples", with didn't have this lock
--, but front-side-bus is changeable via MoBo BIOS. Also, if you just
add 0.5v in your CPU you can made it running faster than designed. The
same applies to memory. That's why we bought DDR533 mems to run in
DDR400 hardwares. We increase FSB and our mems could run with this new FSB.
Again, showing *max* from manufacturer instead of *actual* speed is
wrong. Even if the machine has or not capabilities to run with more/less
power than it has designed for, is not up to the OS decide it. The OS
should run or not, but the user has chosen this path; it must only tell
him what's *really* happening. "Your actual clock differs from
manufacturer. Its *your* fault if any component fail or
malfunctions/bugs arrives because of this."
--
dual_bereta_r0x -- Alexandre Hautequest
ArenaNetwork Lan House & Cyber -- www.arenanetwork.com.br
next prev parent reply other threads:[~2004-02-26 1:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-16 21:34 2.6.2: P4 ClockMod speed Dominik Brodowski
2004-02-16 21:48 ` dual_bereta_r0x
2004-02-16 21:57 ` Bruno Ducrot
2004-02-17 9:09 ` Dominik Brodowski
2004-02-26 1:28 ` dual_bereta_r0x [this message]
2004-03-03 19:12 ` Bruno Ducrot
2004-02-25 17:43 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2004-02-16 19:23 dual_bereta_r0x
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=403D4BD3.7050703@arenanetwork.com.br \
--to=dual_bereta_r0x@arenanetwork.com.br \
--cc=cpufreq@www.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox