Fanless Aspire One

A kernel module means that kernel must be build to use that module or will be simple as now, just download a file and put it to run on boot time?

 

should not be to hard to build it separate and make a package from it in a PPA on launchpad.

Probably just as easy to use the script + init script and package that + put it in a ppa repository.

 

I forgot the line to read the temperature.

Code:

sudo perl -we 'use POSIX; sysopen (IOPORTS, "/dev/port", O_RDWR); binmode IOPORTS; sub inb {my $res; sysseek IOPORTS, $_[0], 0; sysread IOPORTS, $res, 1; return unpack("C",$res);} sub outb {sysseek IOPORTS, $_[1], 0; syswrite IOPORTS, pack("C",$_[0]), 1;} sub wait_write {my $i = 0; while ((inb($_[0]) & 0x02) && ($i < 10000)) {sleep(0.01);$i++;} return -($i == 10000);} sub wait_read {my $i = 0; while (!(inb($_[0]) & 0x01) && ($i < 10000)) {sleep(0.01);$i++;} return -($i == 10000);} sub wait_write_ec {wait_write(0x66);} sub wait_read_ec {wait_read(0x66);} sub read_ec {if (!wait_write_ec()) {outb(0x80, 0x66);} if (!wait_write_ec()) {outb($_[0], 0x62);} if (!wait_read_ec()) {inb(0x62);}} printf("%d\n", read_ec(0x58)); close(IOPORTS);'

 

making a ppa (whatever's in it) for ubuntu is ok for - probably most of us, but it doesn't help people wanting to stay with Linpus. I suppose as long as there is also a downloadable tarball they can just unpack and run an install script on that just automates the instructions I gave already.

I'm not enthusiastic about the one-line acer-ec implementation; I think I prefer we keep the separate script as it makes things much easier when it comes to extending the functionality - both of acer_ec.pl and of acerfand. The perl script is useful in its own right for debugging.

It occurred to me that probably the Right Language to write the whole thing in is python, not least because there's all sorts of stuff that'll probably make it easier to gui-ise things later. But I'm not a python coder. (I write Java for a living, but Java is so very much the Wrong Language for this occasion!)

The problems with getting it to work on boot: Is anyone else having that problem apart from casainho?

While working on it the main problems with that I was having was that /usr/local/bin is not in the path during the running of rc.local. Hence supplying the whole path, and hence the acerfand script internally tries to find acer_ec.pl and should return an error if it can't. It looks first in $PATH, then in the same directory acerfand is in.

casainho: When I said look in vc-8, that's Virtual Console 8, which is where some of the boot process including /etc/rc.local is logged. alt-ctrl-f8. Then alt-ctrl-f7 to get back to the desktop (but if you're running ume-launcher from netbook remix, it'll probably be unhappy. Just restart it. )

 

Agree here.

I am not sure if python is the way to go.. perl is perfect for the basic script.

I have been testing the script with lower bound @ 55 top at 60. This all works fine. Tried converting some flac's to ogg's (to save space on my sd card) it nicely turned on at 60 degrees, not going above 65. When the conversion was done, it dropped and turned the fan off again. Just perfect.

 

Yes. If we continue using it as it is, let's just leave it. I'm talking about if we want to develop something more self-contained and packaged. I have a deep and abiding loathing for perl though; it's the archetypal write-only language. :-D

With the default settings (60-70) it just never turned the fan on, with the 'powersave' cpufreq governer - even streaming video. It shot up over 70 nice and quickly though when I switched to 'ondemand'. Then I was sure the script worked (after I'd uploaded it!)

 

yeah I use the ondemand schedular.
in theory it should use less power on average, because the cpu can go back to sleep faster.. though I think it is somewhat to slow for that .

I'm happy with these results.. the power usage goes between 8.7 and 9.7W and little noise. perfect. Now only to fix the constant migrating of jobs from cpu to cpu (so it has to wake up less). I tried taking one "cpu" offline but that actually increased power usage (also turning off irqbalancing didn't help).

 

Me too. I mean, whatever else goes on here to tighten and neaten up the deployment, as far as I'm concerned the problem's solved, really.

Um, there is only one real CPU, and one core. The apparent apperance of two in system monitor/cpuinfo et al, is basically an illusion of hyperthreading. I'm surprised what you did worked at all, but probably all it did was disable the hyperthreading and make the whole thing less optimal.

 

yeah, I know, thats why I put cpu between quotes..
linux just sees it as 2 cpu's (2 threads, or how you want to call it) and does actually move the task from one "cpu" to another.
This moving is costly, and I would want to avoid it. the less wake ups, the less power used.

 

Attention on this message -- looks like processor can be undervoltage and will go less 10 degrees!! :It's important for a fanless system to drop 10 degrees -- can someone test it? I am not used to build kernel and patches (last time I wasn't able to build it :-( ):
viewtopic.php?f=7&t=1338&p=8931#p9538

Rachel, thank you for that vc-8 info. I saw that were an error running rc.local. The problem seems to be this lines (and others)... If I run them as sudo, I get an error on permissions, but If i run them as root, all is ok -- can be this problem?? -- sorry, it's a bit off topic. I commented that lines and now the acerfand runs oks at boottime

 

It is very very very quick and dirty,

Code:

#! /bin/bash -e
#### BEGIN INIT INFO
# Provides:          acerfan
# Required-Start:    $syslog $time $local_fs 
# Required-Stop:     $syslog $time $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      S 0 1 6
# Short-Description: Custom fan control for the Acer Aspire One
# Description:       Debian init script for the acerfand, a custom fan control
#                    script for Acer Aspire One
### END INIT INFO
#
# Author:	     [email][email protected][/email]	
#
set -e

PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin
# is this allowed?
DAEMON=`which acerfand`

test -x $DAEMON || exit 0

. /lib/lsb/init-functions

case "$1" in
    start)
	log_daemon_msg "Starting Acer Aspire One fan control" "acerfand"
	$DAEMON
	log_end_msg $?
    ;;
  stop)
	log_daemon_msg "Stopping Acer Aspire One fan control" "acerfand"
	pid=`pgrep acerfand`
	if test -n "$pid" ; then
		kill $pid;
	fi
	log_end_msg $?
    ;;
  force-reload|restart)
    $0 stop
    $0 start
    ;;
  *)
    echo "Usage: /etc/init.d/acerfan {start|stop|restart|force-reload}"
    exit 1
    ;;
esac

exit 0

Place this in /etc/init.d/acerfan
(don't call it acerfand as the detection code in the acerfand script will fail.)
then do update-rc acerfan defaults.

 

Qball, can you please explain why should we install this file? -- I don't understand what I get by doing it... - thanks

 

It nicely starts the acerfand script on startup, and stops it again when shutting down.

 

So we don't need to put acerfand on rc.local? just that? -- If so, I will apply this just next time, since on rc.local is working nicely now.

 

rc.local is fine too.
I just prefer it this way.

 

rc.local is, properly speaking, the place where you as the user/sysadmin put your own private modifications - especially, as with this, where you're only concerned about it getting started and don't need support for all the other behaviours, restarting, reloading, getting status, et al... They're the changes made to be specific to a particular machine. Hence the "local". (similarly /usr/local is where the user would install applications that aren't part of the distribution. Typically the distribution puts nothing there - indeed, looking in my /usr/local/bin all it has is the madwifi stuff built from source, and the acer_ec/acerfan stuff. It's no coincidence that if you get a source tarball of most applications, they will install, by default, into /usr/local.)

If it's a system service, especially one provided by the distribution, it should be handled by an init script. There's a reason why, by default, the rc.local script is empty.

Essentially, rc.local is fine for us as users, but if we wanted to make a neatly distributable package - for ubuntu and linpus - that users can install with a click, it would be appropriate to make it with a proper init script. We don't want to have to script adding something automatically to rc.local, nor would we, at that point, want to tell the user to make that change.

It just depends how hard we want to try to make a neat package out of it. TBH I'm not sure we do; this is probably only going to be a transient solution for a transient problem with a minority of units, and I wouldn't be surprised if newer units just don't have the problem.

I think it might just be sufficient to bring the bits together into a single install script that can be downloaded and run, which will then write or fetch acer_ec.pl and acerfand and poke the line into rc.local.

casainho; probably in your case the best advantage of the init script would have been that acerfand wouldn't have been prevented from starting by problems with the other stuff in rc.local.

 

Big thanks to everyone involved in making this soft hack possible !

My one is now perfectly silent, just the way I wanted it to be :')

 

Seems odd. If they're in rc.local they should be running as root; so their failure during boot is probably not related to permissions. It does make sense that they fail when run as sudo; the command (echo ...) is run as root, but the attempt to write (> file) is done as you, and you can't write there.

Anyway, as mentioned before I managed to sidestep this problem by not putting those lines into my rc.local at all, but rather re-enabling the option to set cpufreq policy in the gnome power manager. This seems the better way to do it, not least because it lets me set a different policy depending on whether I'm on AC power or on battery (in my case I now have ondemand when on mains, and powersave when on battery).

To do it, you need to run the gconf editor. Go to Preferences and Main Menu. In the "System Tools" menu, check the "Configuration Editor" item, to make it visible in the main menu (and thus also in ume-launcher). Then you can run the configuration editor. In apps->gnome-power-manager->ui, select "cpufreq_show". Now you can run the gnome power manager ("Power Management" in Preferences) and set your computer speed policy.

(Those of course are the English translations of the names of things )

I can't really see the logic in the decision, presumably by ubuntu, to hide the cpufreq policy options in the power manager by default, but there y'go.

 

Because of this sentence: "I was able to undervolt the processor quite a bit at 1600mhz and during a stress test the temperature of the processor dropped by over 10 degrees C over stock voltage.", I did build(were my first time ) the latest kernel available on kernel.org and applied the phc patch.

Now I need to find the lowest possible values of voltage to have a stable system -- I would like to save that "10 degrees", energy, will for sure also help in battery run time

Are anyone working with phc?



And does anyone knows what all this 8 states means?:

Code:

root@cas-laptop:/home/cas# cat /proc/acpi/processor/CPU0/throttling 
state count:             8
active state:            T0
state available: T0 to T7
states:
   *T0:                  100%
    T1:                  87%
    T2:                  75%
    T3:                  62%
    T4:                  50%
    T5:                  37%
    T6:                  25%
    T7:                  12%

 

you can do the throttle with stock kernel too. only resulting in a slower machine.. (and looks like it runs even a bit hotter).