Re: 2.6.2: P4 ClockMod speed

[Bruno Ducrot <ducrot@poupinou.org>]

On Thu, Feb 26, 2004 at 01:28:51AM +0000, dual_bereta_r0x wrote:
> 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."
> 

The problem is that you can not trust /proc/cpuinfo when you compile
with SMP.  Go UP and that should be ok.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.