Re: Power tools on amd64

[Marko SchÃtz Schmuck <MarkoSchuetz%web.de@localhost>]

At Sun, 12 Sep 2010 14:12:16 +0200,
hans dinsen-hansen wrote:
> 
> Dear list
> 
> I am running amd64 rel 5.0.1 (binary, GENERIC kernel) on my laptop, and
> just to-day my fortune cookie said:
> "X windows:
>       ... ...
>       Power tools for Power Fools.
>       ... ..."
> 
> Being a fool, I took a look into /etc/rc.d/apmd and /etc/powerd/scripts;
> they refer to the programs like e.g. /usr/sbin/apm{,d} which are missing.
> 
> The manuals say that these programs belong to the i386 release.
> The options to GENERIC say:
> " ... ...
> options       COMPAT_NETBSD32
> ... ... "
> 
> My question is:  Can I just load missing binaries like the pair
> /usr/sbin/apm{,d} from a distribution of i386, rel. 5.0.1, or will I run
> into trouble with shared libraries?

I'm running amd64 on a laptop as well.

This is actually my primary machine and sometimes gets fairly high
loads. 

I had setup /etc/powerd/scripts/sensor_temperature critically high
temperature, then restart estd with parameters to let the laptop cool
down, and when normal temperature was reached te stop estd and restart
it allowing higher frequencies.

Then I noticed that rarely the temperature would keep rising beyond
the critical temperature. Sometimes leading to the machine powering
off. It turned out that the event notifications (invocations of
sensor_temperature) were sometimes not happening in the same sequence
as the events.

For example:

May  3 13:41:08 prpad root: /etc/powerd/scripts/sensor_temperature: (coretemp1) 
critical limit exceeded [cpu1 temperature]
May  3 13:41:10 prpad root: /etc/powerd/scripts/sensor_temperature: (coretemp1) 
critical limit exceeded [cpu1 temperature]
May  3 13:41:10 prpad root: /etc/powerd/scripts/sensor_temperature: (coretemp0) 
normal state entered [cpu0 temperature]

If the "normal state entered" event was somehow delayed estd would
actually be running allowing frequencies to go up and since the last
event actually happening was a "critical limit exceeded" there would
not be another such event.

I did not look into the code that delivers these events or consider
how to avoid the re-orderings (since we're starting shell scripts, I
don't see a straightforward way to safeguard against such
re-ordering).

Instead I decided to re-check every time an event is delivered what
the current temperature is (/etc/powerd/scripts/envsys-check)

#!/bin/sh

STAT0="`/usr/sbin/envstat -d coretemp0 | tail -1`"
CORETEMP0="`echo $STAT0 |sed -e "s|cpu[[:digit:]] 
temperature:[[:space:]]*\([[:digit:]]*\)\..*|\1|"`"
CRITTEMP0="`echo $STAT0 |sed -e "s|cpu[[:digit:]] 
temperature:[[:space:]]*[[:digit:]]*\.[[:digit:]]*[[:space:]]*\([[:digit:]]*\)\..*|\1|"`"

STAT1="`/usr/sbin/envstat -d coretemp1 | tail -1`"
CORETEMP1="`echo $STAT1 |sed -e "s|cpu[[:digit:]] 
temperature:[[:space:]]*\([[:digit:]]*\)\..*|\1|"`"
CRITTEMP1="`echo $STAT1 |sed -e "s|cpu[[:digit:]] 
temperature:[[:space:]]*[[:digit:]]*\.[[:digit:]]*[[:space:]]*\([[:digit:]]*\)\..*|\1|"`"

if [ $CORETEMP0 -le $CRITTEMP0 -a $CORETEMP1 -le $CRITTEMP1 ] ; then
    logger -p notice "non-critical $CORETEMP0 <= $CRITTEMP0 and $CORETEMP1 <= 
$CRITTEMP1"
    echo "estd_flags=\"-l 35 -h 50 -b -M 1200\"" >/etc/rc.conf.d/estd
    /etc/rc.d/estd onestop
    pkill -f sbin/estd
    rm -f /var/run/estd.pid
    /etc/rc.d/estd onestart
else
    logger -p notice "critical $CORETEMP0 > $CRITTEMP0 or $CORETEMP1 > 
$CRITTEMP1"
    echo "estd_flags=\"-l 99 -h 100 -b -M 600\"" >/etc/rc.conf.d/estd
    /etc/rc.d/estd onestop
    pkill -f sbin/estd
    rm -f /var/run/estd.pid
    /etc/rc.d/estd onestart
fi

This doesn't prevent the possibility of the system ending up and
staying in the critical temperature state, but it already makes it
less likely. So I also have cron call /etc/powerd/scripts/envsys-check
once a minute to catch the few times when the laptop would otherwise
stay in the critical temperature state.

Best regards,

Marko

Attachment: pgpUJuR7W47Bv.pgp
Description: PGP signature