Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
The answers below are right, even if this vars are out, the machine
should still work, or it has faulty hardware.
OS's like Windows 95,98,ME don't do idle calls unless you install
something like rain on them, so they would always trash such a machine.
In addition, if you would have the machine build with idle (c1) calls,
and where running a long compile/code job (8+ hours), then it would
crash also, that kinda defeats buying a powerfull processor...
On Tue, 2003-11-04 at 20:26, nw1 wrote:
> Paul mather,
> Thanks for your response ...
> See comments below (annotated)
> - Original Message -
> From: "Paul Mather" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> 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_del
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
annotated below
- Original Message -
From: "Technical Director" <[EMAIL PROTECTED]>
To: "Paul Mather" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 04, 2003 12:32 PM
Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
>
> > => 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. :-)
>
> Considering the high demand for consumer's purchasing 'their' products, a
> mishap like "My server can't run at high cpu due to it crashing" is part
> and parcel to shooting yourself in the foot as a manufactuer.
I'm not sure if your addressing the original poster of this thread (me) or Paul, who
has a
similar problem.
>
> If you buy a MB/PROC that cooks just by operating as a server, which in
> most cases what FreeBSD will be used for, and you know that it 'may'
> crash or lockup due to heat, don't use FreeBSD.
>
> - or -
>
> Buy hardware that won't cook out.
>
I disagree with both of your suggestions above.
Just dropping an item, in this case the OS, because its contributing to a specific
problem
is not my idea of building or refining. Up until this point, I thought it was more an
AMD
issue until I heard from *Paul Mather --who uses intel based hardware. Paul Mathers'
issue, with his *laptop seems to be more severe than my overheating with the *server.
Yes = there are some tricks more knowledgable people in the community can do to work
around issues such as this, but I'm hoping to bring the issue to the attention of
whomever
needs to see this in order to get a permenant fix. Having to set the following to '0':
machdep.apm_suspend_delay: 0
machdep.apm_standby_delay: 0
just for the machine to *not overheat while idling --doesn't seem correct.
The issue at hand may very well be explainable in its current state, but after hearing
from *Paul Mather and working closely with a lead tech @ AMD and Tyan; I'm confident
I'm
in one of the correct forum to discuss this.
Personally; I shouldn't have to buy my way out of this problem, and I will not leave
FreeBSD for another OS becaue of this. :-) Lets find out what we can do to remedy this
within FreeBSD instead of pushing people away from the project.
> R.
>
> PS
>
> Have you both tried to run 4.#-[CURRENT/STABLE/RELEASE] to see if the
> problem goes away?
>
> > 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. :-(
> >
> > 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). 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. :-)
> >
> > 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.
> >
> > So, I'm wondering if there's some sysctl or other knob that can be set
> > in FreeBSD that will ameliorate this problem. (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
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
Paul mather,
Thanks for your response ...
See comments below (annotated)
- Original Message -
From: "Paul Mather" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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 Gate
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
On Tue, 4 Nov 2003 00:07:14 -0500 "nw1" <[EMAIL PROTECTED]> wrote: > This does make absolute sense, but this isn't a publicly accessable > machine, so it would rarely reach that max_load to cause it to > overheat as its doing now, provided, I can find someone to answer the > second outstanding question; Where are those sysctl variables that i > was previously able to set? They are no longer available You know, it's a good question - just for kicks, I tried this on my two FreeBSD machines: FreeBSD 4.9-RC #1: Wed Oct 15 08:12:11 PDT 2003: # apm apm: can't open /dev/apm: Device not configured # sysctl machdep.apm_standby_delay machdep.apm_standby_delay: 1 FreeBSD 4.9-STABLE #1: Sat Nov 1 09:16:30 PST 2003: # apm APM version: 1.2 APM Management: disabled AC Line status: unknown (... etc ...) # sysctl machdep.apm_standby_delay sysctl: unknown oid 'machdep.apm_standby_delay' ...which is a bit odd, to say the least. If anything, I would've expected the machine that doesn't have APM support compiled in to the kernel, to be the one with no understanding of APM-related sysctls. But, it's the other way around. Maybe something changed in the last two weeks? But you're running 4.8-RELEASE-p13 - I'd expect that to be (essentially) older than either of my installations... Anyway, those two oids don't seem to be documented under sysctl(8). And googling on them doesn't yield a lot. I really have no idea, I just thought I'd throw this out there as another data point. (This issue seems to be generating more heat than light, if you'll pardon the pun :) -Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Overheating attributed to Freebsd --sysctl variablesnotavailable--
Annotated below. - Original Message - From: "Technical Director" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 03, 2003 11:07 PM Subject: Re: Overheating attributed to Freebsd --sysctl variablesnotavailable-- > > Forgive me for saying: > No need to ask for forgiveness. I'm looking for honest feedback. :) I have been working with both Tyan and AMD to resolve this, the issue is still here, --more below. > 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. I'm kind of stuck on FreeBSD. Not interested in moving on to another *nix or any other OS for that matter. > > 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. This has been done. Both the machine with the heat issue and his sister (18" apart) run neck and neck with respect to the hardware monitor readings, temperatures and such, and neither box, as you put it; "bakes out on me/us" <-- this has been tested overnight in a warm environment, the same environment that the OS runs in normally except for this test, we cut the air-conditioner off. This issue I'm dealing with only happens when Freebsd is loaded and the air conditioner is off. > > 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. > We would rather change hardware than leave FreeBSD --at this point. > 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. This does make absolute sense, but this isn't a publicly accessable machine, so it would rarely reach that max_load to cause it to overheat as its doing now, provided, I can find someone to answer the second outstanding question; Where are those sysctl variables that i was previously able to set? They are no longer available > > I doubt hardware manufactuers put out equipment that can't run at 100% at > least. > > My 2 cents. Your "2-cents" makes perfect sense, but as I posted above, I would rather replace either/ or both the motherboard and both processors. Before doing so, I had to hear what the community at large thinks about this. Thank you. :-) > > R. > > On Mon, 3 Nov 2003, nw1 wrote: > > > Both the board(s) and the processors were RMA'd. > > Both boards and all four (4) processors were swapped around between > both OS's and the > > problem remains using the hardware with the FreeBSD OS. The latest > BIOS is installed. > > > > We also have a newly purchased board (S-2466), the same thing occurs. > > > > Details @ http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > - Original Message - > > From: "jon" <[EMAIL PROTECTED]> > > To: "nw1" <[EMAIL PROTECTED]> > > Sent: Monday, November 03, 2003 10:00 PM > > Subject: Re: Overheating attributed to Freebsd --sysctl variables notavailable-- > > > > > > > On Mon, 2003-11-03 at 19:57, nw1 wrote: > > > > > What version of FreeBSD are you using? > > > > > Did you compile amp into the kernel? > > > > > > > > I think you're not understanding what I posted @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing > > > > > > > > The first line has what version I'm running. The entire document @ > > > > http://69.3.136.141/freebsd/installation/sysctl_variables_missing implies; this was a > > > > running system with no serious issues; meaning; the sysctl items I'm speaking > > > > of were > > in > > > > fact available and working. > > > > > > i can say from prior experience w/ hardware, if you system has > > > overheated you dont know where you stand (you may have damaged all kinds > > > of stuff, we had a b
