FuSi Amilo 1667G stops when powerd is running in hadp/adp mode

[Ian Smith]

On Mon, 26 Apr 2010, Joerg Wunsch wrote:
 > As Andriy Gapon wrote:
 > 
 > > on 23/04/2010 12:17 Joerg Wunsch said the following:
 > > > dev.cpu.0.freq_levels: 2000/25000 1875/23437 1800/20900 1687/19593 1600/17500
 > > > 1500/16406 1400/15312 1300/14218 1200/13125 1100/12031 1000/10937 900/9843
 > > > 800/7900 750/7406 700/6912 650/6418 600/5925 550/5431 500/4937 450/4443
 > > > 400/3950 350/3456 300/2962 250/2468 200/1975 150/1481 100/987 50/493
 > 
 > > You seem to have far too many levels here.
 > 
 > > I think that you need to check for cpufreq drivers you have attached
 > > to your cpu and disable the one(s) that cause problem.
 > 
 > Well, it seems real that Turion-based machines can offer that many CPU
 > frequency levels.  Another dualcore Turion machine offers these:
 > 
 > dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 
 > 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 
 > 398/11076 298/8307 199/5538 99/2769
 > 
 > Not quite that many as the machine above, but still an impressive
 > list.

Some, maybe a lot of those freqs are throttling, provided by relative 
cpufreq driver/s, providing some set of 7/8 downto 1/8 of base freq(s) 
provided by (in your case) the powernow absolute driver.

Your dmesg will show whether eg acpi_throttle is enabled.  If it is and 
no other relative driver takes over (as p4tcc would on many Intels), 
then acpi_throttle will jump in and generate lots of such freqs.

I don't know about Turions at all, but we're seeing dual and quad core 
Intels that seem to get no benefit and apparently real detriment by 
enabling throttling nowadays, especially in hope of saving power/heat.  
Or rather, possible detriment by not disabling it as it defaults on.

For Intels, advice has been to add to loader.conf:
  hint.p4tcc.0.disabled=1
  hint.acpi_throttle.0.disabled=1
(per cpu) in loader.conf to retain just the absolute frequency set.

Might be worth at least seeing what absolute frequencies yours has?

As for bin/136354 and bin/145063, personally I preferred a patch adding 
debug.cpufreq.highest to the existing debug.cpufreq.lowest, allowing 
more dynamic min/max range setting by sysctl rather than having to
restart powerd with new parameters, but it was said to be poor policy.

 > It seems I managed it to finally fix the machine above, thanks to
 > anyone for suggestions.  I updated the BIOS to the latest version
 > (1.07) where the reports I found in the Internet suggested that
 > Windows 7 failed to set the CPU frequency away from the default 800
 > MHz one with any prior version.  This by itself didn't really solve
 > the issue at hand, so I continued to upgrade the machine's kernel from
 > FreeBSD 8.0-RELEASE to RELENG_8.  Also, I modularized the kernel, and
 > recompiled the cpufreq module with *just* the powernow driver in it.

But you still have all those freqs?  And no acpi_throttle in dmesg?  I'm 
wondering whether this can be controlled just by the hints, with GENERIC 
or other kernels having cpufreq as standard?

 > I cannot tell for sure which of the three things did fix it, but I can
 > now run it with "powerd -a hadp -b adp", and it ran for 12 h that way
 > (including the nightly cron jobs).

Sounds good, but still better to know what did the trick, for next time.

cheers, Ian