On Sun, 2013-12-22 at 16:51 +1100, Ian Smith wrote:
On Sat, 21 Dec 2013 18:01:35 -0500, ito wrote:
Hello Ian,
At 50 through 62C the dev.cpu.0.freq: 1298
at 70C , 1135
back up to 1298
Right, 1135 / 1298 ~= .875 = 7/8, so yes that's your 1.3GHz CPU dropping
down one step for thermal control.
OK
dev.cpu.0.freq_levels: 1298/-1 1298/-1 973/-1 811/-1
649/-1 486/-1 324/-1 162/-1
Also directly below that:
dev.p4tcc.0.freq_settings: 1/-1 8750/-1 7500/-1 6250/-1 5000/-1
3750/-1 2500/-1 1250/-1
I suppose that is the 8 (freq_levels) you where referring to. Further I
infer that this -1 means that the BIOS has set them or does set them.
Yes, but here the -1 indicates for freq_levels that power consumption in
milliwatts at that freq is unknown, likely the same for p4tcc settings.
Ok.
I set hw.acpi.thermal.tz0._PSV: 70C
Trying find / acpi to see it work.
While doing the above (find) the fan is on but not full out.
find(1) works disk harder than CPU as a rule, though here that command
gets xorg about 70% busy, and keeps going for ages after hitting ^C, as
it lists each file on the disk :) Maybe useful: find / -name *acpi*
OK, I will keep that in mind
find / -name *acpi*
From below:
PS, is this the exact command?
dd if=/dev/random of=/dev/null
No, no. I was careful to be precise, and yes a mistyped dd can be
dangerous, and redirected to a file could indeed fill your disk.
Fortunately that one doesn't work, invalid filename. see dd(1).
OK
so dd if=/dev/urandom of=/dev/null
I see:
if=FILE read from file instead of stdin
/dev/urandom, kernels random number generator
of=FILE write to FILE instead of stdout
/dev/null, data sink
:
I am reluctant to type anything like dd: anything: I'm not really that
confident with the command line.
Without your redirection it just reads from /dev/random, burning CPU,
discarding the output, until you hit ^C .. perfectly safe.
:
After setting the PSV value it does not go above 71 when rendering
animation with blender.
Yeah rendering will busy the CPU (and GPU too) pretty well. Good, so
we know passive cooling works (in case your fan ever really packs up).
The passive cooling seems to work pretty well. :0
I will try cleaning it again, but I think I remember that I thought
cleaning would fix it before.
Unless you live in an extraordinarily dust-free environment, this needs
doing with some regularity anyway. I did mine the other day, as summer
ambient temperatures over 30C are becoming normal here (happy solstice!)
I did a quick cleaning but did not want to take it apart at the moment.
However, I noticed in the past that a thorough cleaning only helped but
did not solve noise.
At the temperatures you've quoted, apart from annoying fan noise, it
doesn't seem broken to me. How warm does it run just idling (versus
what ambient temperature where you are)?
Yeah, thats the thing this is an old computer and all but it still works
+stock+ more or less. That is one of the few things that is actually
bothersome, the fan that is.
I do not have AC but the window is often open, it is winter here. I
would guess between 60-70 degrees Fahrenheit (15-21C).
I looked at acpi_thermal, have to digest it.
Found the source online for freebsd acpi.
It'll be on your disk if you installed sources.
I did not install the sources, although I did find acpiio.h
in /usr/include/dev/acpica/ so I may try the find command you mentioned
(find -name *acpi*) and see what else I can find.
And as I mentioned I can find it online.
So I guess that I could adjust the throttling, through the process that
the machine uses to save power??
I wouldn't worry about that. Are you not running powerd(8)? As Kevin
Oberman often points out, p4tcc is for thermal control - as we've just
exercised - but cpufreq(4), controlled by powerd, is the way to save
power when you don't need the CPU running at maximum frequency, which is
likely most times. Running it slower when idle _greatly_ reduces heat.
Powerd is the first thing that was mentioned on the FreeBSD forums. I
tried it but possibly did not configure it properly.
It did not seem to fix the fan issue and as I said above the computer
works fine otherwise; no emergency shut down's or slow downs really to
speak of.
I don't really work this computer that hard so I am not demanding too
much out of it. Which is why I thought maybe the 'normal' operation of
the CPU could be curtailed.
-
---/etc/rc.conf--
snip-
powerd_enable=YES
powerd_flags=-a adp -b min -i 30
--snip--
---
--
--I am trying powerd -i 30 to see where it gets me.
cheers, Ian
Thanks a bunch,
eg
___
freebsd-acpi@freebsd.org mailing
