TECRA A9-S9017 -- Idles too hot -- Hardware Support

[Ian Smith]

On Tue, 26 Aug 2008, freebsd_user at guice.ath.cx wrote:
 > For those just starting to follow this thread, you can somewhat start at the
 > begining here: In-Reply-To: <489E9531.2090200 at guice.ath.cx>
 > -
 > -
 > Here's more data to append onto my last message; In-Reply-To:
 > <20080826002657.B14827 at sola.nimnet.asn.au> --  in response to your:
 > <quote>
 > > However we need some empirical data about what it's doing.  Showing
 > > your /var/run/dmesg.boot and 'sysctl hw.acpi' output would be a good start.
 > ></quote>
 > 
 > With respects to 'powered' we ran in to a speed bump or two (2).
 > 
 > IAN:
 > > (if it's running) then run 'powerd -v' which runs in foreground and says 
 > > exactly what it's doing re shifting CPU frequency under various loads.
 > > 
 > 
 > freebsd_user:
 > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd stop
 > powerd not running?

Right, it wasn't running because cpufreq isn't loaded, as below.

Check 'kldstat -v | grep cpufreq' 

 > Tue Aug 26 03:30:40 EDT 2008 -->
 > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd -v
 > /etc/rc.d/powerd: unknown directive '-v'.
 > Usage: /etc/rc.d/powerd
 > [fast|force|one](start|stop|restart|rcvar|status|poll)

No, I'd have said; not /etc/rc.d/powerd, but just 'powerd -v'

% which powerd
/usr/sbin/powerd

The idea is to start powerd manually, with -v switch, in foreground in 
its own window or vty, as shown in powerd(4)

 > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v
 > Starting powerd.
 > powerd: lookup freq: No such file or directory

Yes; it won't even startup without finding the cpu freq sysctls.

I'm surprised that powerd failing to start hasn't been logged in 
/var/log/messages every time you've tried .. ?

 > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd
 > root     9190  0.0  0.0   372   208  p3  R+    3:32AM   0:00.00 grep -i
 > powerd
 > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd
 > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v
 > Starting powerd.
 > powerd: lookup freq: No such file or directory
 > Tue Aug 26 03:30:40 EDT 2008 --> ps auxww | grep -i powerd
 > Tue Aug 26 03:30:40 EDT 2008 --> /etc/rc.d/powerd start -v
 > Starting powerd.
 > powerd: lookup freq: No such file or directory
 > 
 > Now I'm curious about the contents of /etc/rc.d/powerd ...

Curious is good :)

 > powerd_poststop()
 > {
 >         sysctl dev.cpu.0.freq=`sysctl -n dev.cpu.0.freq_levels |
 >             sed -e 's:/.*::'` > /dev/null
 > }

That'll be to reset dev.cpu.0.freq to its highest speed after quitting.

 > which prompts me to look at the following 'sysctl' ...
 > 
 > Tue Aug 26 03:30:40 EDT 2008 --> sysctl dev.cpu
 > dev.cpu.0.%desc: ACPI CPU
 > dev.cpu.0.%driver: cpu
 > dev.cpu.0.%location: handle=\_PR_.CPU0
 > dev.cpu.0.%pnpinfo: _HID=none _UID=0
 > dev.cpu.0.%parent: acpi0
 > dev.cpu.0.cx_supported: C1/157
 > dev.cpu.0.cx_lowest: C1
 > dev.cpu.0.cx_usage: 100.00%

Yep, and all the freq stuff is missing.  Refer previous message.

 > Tue Aug 26 03:30:40 EDT 2008 --> sysctl -a |grep -i freq
 > kern.acct_chkfreq: 15
 > debug.cpufreq.lowest: 0
 > debug.cpufreq.verbose: 0
 > machdep.tsc_freq: 2194521505
 > machdep.i8254_freq: 1193182
 > machdep.acpi_timer_freq: 3579545
 > Tue Aug 26 03:30:40 EDT 2008 -->
 > 
 > Unless I've missed or mistyped something, the file /etc/rc.d/powerd is
 > trying to set a variable (dev.cpu.0.freq=) using the value(s) of "sysctl dev.cpu.0.freq_levels".

Right.  See /usr/src/usr.sbin/powerd/powerd.c to see what/how it does.

 > Once again unless I've missed or mistyped something, and please correct me if I'm wrong,"sysctl
 > dev.cpu.0.freq_levels" doesn't seem to exist within the machine.

Yes, that's the (possibly but not necessarily whole) problem.

 > If UPGRADING from 6.3-p3 to 7.X will save us all some time with the issues stated in this
 > thread, then so be it.  I don't mind trouble-shooting or customizing issues such
 > as this, but it may be a bit much given my mobile nature.

I can't tell if upgrading would help.  Try the GENERIC kernel first - or 
at least one having cpufreq, but perhaps you left out something else you 
didn't know was necessary?  Unsure whether you can just kldload cpufreq 
in /boot/loader.conf with your current kernel, but it's an easy  test.

 > Time permiting I'll get to your next suggetion shown; just below this
 > line:
 > 
 > > It's also useful to watch the temperature(s) directly over the time, see ug
 > > acpi_thermal(4) and try logging those sysctls periodically in a script.

All good for debugging, but with cpufreq, maybe it will just go? :)

[..]

cheers, Ian