Date: Tue, 04 Nov 2003 15:58:21 -0400 From: "Jud" <judmarc@fastmail.fm> To: "nw1" <network101@covad.net>, "Paul Mather" <paul@gromit.dlib.vt.edu> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Overheating attributed to Freebsd --sysctlvariablesnotavailable-- Message-ID: <20031104195821.4641E7984F@server2.messagingengine.com> In-Reply-To: <00a901c3a309$92dc7360$0300a8c0@install> References: <20031104051850.832E216A4D0@hub.freebsd.org> <00a901c3a309$92dc7360$0300a8c0@install>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Nov 2003 14:26:40 -0500, "nw1" <network101@covad.net> said:
> Paul mather,
> Thanks for your response ...
> See comments below (annotated)
> ----- Original Message -----
> From: "Paul Mather" <paul@gromit.dlib.vt.edu>
> To: <freebsd-questions@freebsd.org>
> Sent: Tuesday, November 04, 2003 9:45 AM
> Subject: Re: Overheating attributed to Freebsd --sysctl
> variablesnotavailable--
>
>
> > On Mon, 3 Nov 2003 21:07:45 -0700 (MST), Technical Director <trodat@ultratrends.com>
> wrote:
> >
> > => Forgive me for saying:
> > =>
> > => If this system is borked with FreeBSD due to the cpu's not cycling
> > => 'down', then use a different operating system. FreeBSD is not responsible
> > => for your trouble if you can solve the problem by moving on. Doing so and
> > => solving the problem is more important than holding the OS and the
> > => contributors to it accountable to something so seemingly far fetched.
> > =>
> > => One way to test overall integrity of your hardware is to boot to bios and
> > => leave it. Does it bake out on you? Then there is definitely something
> > => wrong with your hardware, perhaps a fan is spinning less rpms than when
> > => new.
> > =>
> > => In my humble opinion this is probably not associated with the OS, but,
> > => that doesn't solve 'your' problem. So besides seeing it for myself I can't
> > => see an absolute need to use FreeBSD, in your words the problem, and not
> > => use some other [$]NIX.
> > =>
> > => One last thing, if your CPU's are baking out and crashing, are you not
> > => nervous that under load this will happen no matter what the OS? Tweaking
> > => system variables will not help you if your server is working ultra-hard,
> > => at some point you will reach a mark that your system should still be able
> > => to do which currently it can't.
> > =>
> > => I doubt hardware manufactuers put out equipment that can't run at 100% at
> > => least.
> >
> > FWIW, I doubt the accuracy of that last paragraph, and don't think
> > this is "so seemingly far fetched" at all. :-)
> >
> > I have a related problem. In my case, it's a borrowed laptop on which
> > I installed FreeBSD 5.1-CURRENT (quite a while ago, but last
> > {build,install}{kernel,world} was circa July 2003). Also installed on
> > the system is Windows 2000 Professional. The related problem I have
> > is that I can fairly easily get the laptop to power off due to
> > thermally-initiated shutdown using FreeBSD (complete with "current
> > temperature has exceeded system limits" type messages on the console
> > beforehand), but can't seem to do so via Win2K. :-(
>
> These are the same two (2) operating systems I am using. FreeBSD will
> cause my AMD-MP's
> to overheat while only idling --depending on the room temperature.
> >
> > Now I know that in a sense this is apples and oranges, because I don't
> > do precisely the same things under both operating systems. But, it
> > seems that high-CPU/system activity under FreeBSD will ultimately lead
> > to a thermal shutdown, but not on Win2K (no so far as I've been able
> > to manage, anyway).
>
> Exactly what I'm experiencing unless and until I set the following:
>
> machdep.apm_suspend_delay: 0
> machdep.apm_standby_delay: 0
>
> If i have the above two (2) lines set to:
> machdep.apm_suspend_delay: 1
> machdep.apm_standby_delay: 1
>
> Its just a matter of time before one or more of the processors overheat
> and the box shuts
> down --without notice.
> >This is inconvenient, to say the least. For
> > example, a FreeBSD buildworld or buildkernel will not complete; it'll
> > get part way through before the machine becomes too hot and shuts
> > itself down. Similarly, building "big" ports like Mozilla won't
> > complete, which makes portupgrade a bit of fun. Needless to say, this
> > system doesn't get updated much. :-)
>
> You may want to try and set those above variables to '0'
> machdep.apm_suspend_delay: 0
> machdep.apm_standby_delay: 0
>
> >
> > Now I'm not saying the machine doesn't become physically hot when
> > running Win2K, too. It does (e.g., when playing CPU-intensive games,
> > etc.). But somehow, Win2K is able to manage things so that the system
> > does not become so hot that the shutdown kicks in.
> >
> Same here
>
> > So, I'm wondering if there's some sysctl or other knob that can be set
> > in FreeBSD that will ameliorate this problem.
>
> Once again try:
> machdep.apm_suspend_delay: 0
> machdep.apm_standby_delay: 0
>
> >(I thought
> > laptop/mobile CPUs generally were able to step down to lower clock
> > speeds to conserve power/run cooler, for example.) If I could do
> > system rebuilds and port builds without having to restart that'd be a
> > big improvement! :-)
> >
>
> > Unlike the original poster, this is an Intel-based system, not Athlon.
> > It's a Gateway Solo 450 laptop.
> This is strange, in comparison to my setup. The machine that's giving
> this overheat
> problem is the build_box (AMD-MP). we have client machines that are all
> intel based; P72,
> P200 and a 1Ghz processor <-- these machines mount via NFS to the problem
> machine and
> installworld and kernel using the same src, as the NFS mount implies,
> --none of the client
> machines needs the following variables/knobs set:
> machdep.apm_suspend_delay: 0
> machdep.apm_standby_delay: 0
> as those intel based machines never overheat or exhibit and instability.
> Granted,
> currently those intel based machines don't do any real work (compiling),
> however, but it
> wasn't always like that. Before the build box went online as the NFS
> server those intel
> based clients did their own building and never overheated. On the flip
> side of the coin,
> the current problem machine sits idle when it overheats subsequently
> shutting down.
>
>
> Paul, your situation seems more severe than ours. Try those variables I
> showed above for
> a temporary fix. They may help.
Not sure if the CPU suspend stuff works with non-AMD CPUs. Anyone know?
Jud
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031104195821.4641E7984F>