Overheating attributed to Freebsd --sysctl variables not available--

nw1 network101 at covad.net
Tue Nov 4 16:00:42 PST 2003

Jud, (see below)
----- Original Message ----- 
From: "Jud" <judmarc at fastmail.fm>
To: "nw1" <network101 at covad.net>
Cc: "freebsd-questions" <freebsd-questions at freebsd.org>
Sent: Tuesday, November 04, 2003 3:17 PM
Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--

> On Tue, 4 Nov 2003 14:05:02 -0500, "nw1" <network101 at covad.net> said:
> [snip]
> > > > I'm interested in those missing sysctl variables I posted @
> > > >
> > > > Using a Third party
> > > > application/script to fix something that was natively working or under
> > > > control, I don't
> > > > think, is the way to go and causes another level of complexity.
> [snip]
> > No problem, I am interested in any and all *sane/reasonable feedback.  I
> > haven't been to
> > much a fan of using third party applications to fix something the
> > original code or
> > hardware should be able to handle.
> FVCool isn't a "third party application" as I understand the term.
> Perhaps a portion of the README file will make things clearer:

I understand better now (FVCool).  Thanks for taking the time to explain that FVCool is
not a "third party application".  I'm still questioning the difference in behavior --not
only between the two (2) OS's when idling, --overheating in FreeBSD, and *not overheating
in the non FreeBSD OS. whatsoever.

> "As is well known AMD's Athlon/Duron is a 'hot' CPU.  It really produces
> a lot of heat.  This is mainly because it consumes a lot of electric
> power.  However, there is an another reason: Generally CPU goes into
> power-save mode when it is in the idle state, but in almost all the
> mother boards this is prohibited in the case of Athlon/Duron mother
> boards in their original BIOS settings.  This software changes the PCI
> configuration data of the chipset (north bridge), and allow Athlon/Duron
> to go into power-save mode.  The principle is very simple if you have
> information.  Actually, you can do exactly the same thing as this
> software
> manually by using the 'pciconf' command in FreeBSD.
>   "Why mother board vendors release their products with such BIOS
>   settings?

What's the reason? <nothing here>

> Well, there is a reason: There is a possibility to get the system
> unstable
> and/or even to hang or crash the system.  Therefore, this software is
> somewhat dangerous in this respect, and I will not take any
> responsibilities for problems caused by using this software.  Please
> check the original Martin Peters's VCool web site for learning more of
> technical details:
>      http://vcool.occludo.net/"
> So what FVCool does is utilize the 'pciconf' command to encourage AMD
> CPUs to go into power-save mode when idle, a function most motherboard
> manufacturers turn off for the stability reasons mentioned by FVCool's
> author.  As the documentation says, you can manually make these changes
> with the 'pciconf' command, but why not save typing by installing the
> port and running the 'fvcool' command, or run it automatically with a
> script?
> Based on the names of the sysctls you're after, I'd speculate they may
> operate in much (or even exactly) the same way.  That is why I wondered,
> in response to your advice to Paul Mather, whether those sysctl settings
> would work with Intel CPUs.

My suggestion to *Paul Mather was in fact a blind suggestion only based on the settings to
lower the usage of the cpu and not raise;  had it been the other way around, I'm not sure
I would have recommended he set those knobs to '1'.

The following fact/issue, i think, still remains outstanding; Using the setup I originally
posted, we can do somethings within the non FreeBSD OS that will rival a looping 'make
buildworld | buildkernel, utilizing both cpu's for encoding purposes while playing a
quake3, utII game and the like, never overheating or exhibit any instability.

Please don't take that above statement as a "this OS is better than your OS".

What I've understood from this particular posting is this:
the motherboards used for the AMD Athlon/Duron(s) have a default BIOS setting --not
allowing the processors to go into 'Power Saving Mode' --while intel based --default BIOS
settings: *do allow 'Power Saving Mode' for the processor(s). y/n?

That seems to be just a bit disturbing.  If we could for the purposes of this paragraph
alone, suspend the notion of *over heating while idling*...  As someone stated earlier in
the thread, what about these cpu's under heavy load within FreeBSD? <-- in our case,
without the air-conditioner on;--> will overheat and shutdown  I have put these cpu's
under heavy load in a non FreeBSD environment and the hardware refuses to break down,
overheat or shutdown

-- Unsuspend the notion of *over heating while idling*...  --

Should we turn our air-conditioner off and set:
machdep.apm_suspend_delay: 1
machdep.apm_standby_delay: 1
and let this dual AMD idle, the machine will overheat and shutdown in a matter of hours.
Once the room is at a tempurature warm enough to make the machine shutdown, the only way
to keep that machine on for more than five (5) to Twenty (20) minutes is to turn the
air-conditioner on and leave it on.

Should we turn our air-conditioner off and set:
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0

Run a script to loop:
make buildworld && make buildkernel KERNCONF=<MY_KERN>
The machine seems to run like a champ without overheating/shutting down.


I hear all of what you're saying here, however, if we leave apm out of this altogether,
whether inTel, AMD or any other processor, shouldn't the processor(s), dual or not, be
able to run full-throttle or, idle without overheating/ shutting down?
> Jud
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

More information about the freebsd-questions mailing list