This CPU seems not to have the Enhanced Intel SpeedStep (http://ark.intel.com/Product.aspx?id=43517), thus the kernel is probably right because the high transition latency can affect the CPU performance under ondemand governor. AFAIK you should be able to use the userspace governor and control the frequencies by hand or by user space daemon.

Please, what is your:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency

The PowerTOP could be patched not to suggest ondemand in such cases.

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

@Jaroslav:

Which userspace daemon should I use then?

Here is the output:

[root@xxx ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
ondemand conservative userspace performance 

[root@xxx ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency 
10000001


[root@box ~]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D410   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.670
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3332.96
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D410   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.670
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3332.83
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Thanks for helping me out.

Created attachment 492841 [details]
Proposed patch

With the attached patch it shouldn't suggest ondemand governor if it is not supported or the cpu transition latency is higher than the ondemand governor max_transition_latency (10ms).

Please test this patch, the experimental build with this patch applied:
https://brewweb.devel.redhat.com/taskinfo?taskID=3264418

For cpufreq switching on your system you can use e.g. cpuspeed daemon:
# yum install cpuspeed
# chkconfig cpuspeed on
And change your default governor in /etc/sysconfig/cpuspeed to:
GOVERNOR=userspace

I just installed i686 version of your RPM and I can confirm this helped.

Your patch works just great.

ps - the cpuspeed runs fine too

Many thanks :-)

Created attachment 766551 [details]
powertop-2.X: proposed fix

It doesn't seem to be fixed in powertop-2.X. Proposed fix sent upstream.

I can confirm it does work now, although I see some floods with this message over powertop screen sometimes:

timer_expire_entry event returned no function value?

This is another story, perhaps. Thanks for help! :-D

(In reply to Lukas Zapletal from comment #21)
> I can confirm it does work now, although I see some floods with this message
> over powertop screen sometimes:
> 
> timer_expire_entry event returned no function value?
> 
> This is another story, perhaps. Thanks for help! :-D

Thanks for testing. You need updated kernel, this is tracked by bug 881030.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1575.html