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_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
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 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
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 Gateway Solo 450 laptop. If I didn't know better, I'd think
that Gateway engineered (pah!) this system so it would run Windows
okay and that's it as far as they're concerned. ;-) FWIW, attached
at the end of this message is a copy of /var/run/dmesg.boot in case
anyone can suggest something to help.
Cheers,
Paul.
PS: I'm glad I'm only borrowing this laptop and didn't buy it!! The
owner of the laptop only uses Windows, so this is only a problem for
me running FreeBSD.
e-mail: [EMAIL PROTECTED]
Without music to decorate it, time is just a bunch of boring production
deadlines or dates by which bills must be paid
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 board that over heated; then 2nd ide channel went down, when we used micron ram!?! and micron was fine in board until the overheat then any other brand ram worked) tyan has a three year warranty use it! BUT my bet is there is a change in the chipset and you wont get the sysctl mibs anyway. you try the newest BIOS flash? good luck if you want to ensure you get a new board, flex it until you stretch a trace or two. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL
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]
