Bug 219852

See http://fedoraproject.org/wiki/Bugs/FC6Common
Check that you have the 686 kernel installed, and not the 586 one.

I had the 586 kernel installed at first. The ondemand module would not load. I
removed it and installed the 686 kernel. With this kernel, the ondemand module
loads but it only works when the laptop is battery powered.

The problem seems to be caused by the Intel Centrino 1.73GHz processor since the
bug also happens on a Sony Vaio FJ-170B :

http://www.fedoraforum.org/forum/showthread.php?t=134958

The ondemand frequency scaling worked under the 2.6.17 and under kernels.

I am having the same problem, the governor seems to be working only when on
battery. In fc5 it worked with AC as well.

When it is AC powered top shows no more than 50% idle, when I plug it off it's
>90% idle. Using top I can not trace down the process which loads the processor,
the only sure thing is that it's the same in init modes 5 and 3, so it does not
seem to be X or gnome stuff.

I've installed all the updates available today, no luck. :(

How do I find out which process is hogging the cpu when running on AC?

(In reply to comment #4)
> When it is AC powered top shows no more than 50% idle, when I plug it off it's
> >90% idle. Using top I can not trace down the process which loads the processor,
> the only sure thing is that it's the same in init modes 5 and 3, so it does not
> seem to be X or gnome stuff.
> 
> I've installed all the updates available today, no luck. :(
> 
> How do I find out which process is hogging the cpu when running on AC?
> 


This is perhaps not the same bug, my proc is idle on AC and battery and still
the governor does not work.

Not sure if this helps somehow, but the last kernel that worked for me was 
2.6.18-1.2200 and also that one can still change frequency manually via the 
CPU scaling applet in the gnome panel.

(In reply to comment #4)
> When it is AC powered top shows no more than 50% idle, when I plug it off it's
> >90% idle. Using top I can not trace down the process which loads the processor,
> the only sure thing is that it's the same in init modes 5 and 3, so it does not
> seem to be X or gnome stuff.
> 
> I've installed all the updates available today, no luck. :(
> 
> How do I find out which process is hogging the cpu when running on AC?

Here attached are vmlinux oprofile reports and diffs for when it runs under AC
and BC. The profiles are likely to be rather noisy, as they were collected in
rc.3 mode, however, they do consitently show some noticable differencies in the
number of samples in acpi* functions.

Here follows a piece of the results, please see the attached file for full details.

[max@k-pax tmp]$ cat /proc/version 
Linux version 2.6.18-1.2868.fc6 (brewbuilder.redhat.com) (gcc
version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Fri Dec 15 17:32:54 EST 2006
[max@k-pax tmp]$ uname -a
Linux k-pax 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:32:54 EST 2006 i686 i686 i386
GNU/Linux

[root@k-pax tmp]# opreport -l
/usr/lib/debug/lib/modules/2.6.18-1.2868.fc6/vmlinux { archive:./ac9 } {
archive:./bc9 }
CPU: PIII, speed 1862 MHz (estimated)
Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit
mask of 0x00 (No unit mask) count 100000
samples  %        diff %    symbol name
3196     29.9784  -38.3373  acpi_processor_idle
1912     17.9345  +21.7536  acpi_os_read_port
1000      9.3800  -14.4553  timer_interrupt
612       5.7405  +1897.2807 acpi_os_write_port
448       4.2022  -50.9787  acpi_pm_read
435       4.0803  +159.2942 _raw_spin_lock
353       3.3111  +172.6689 _raw_spin_unlock
135       1.2663  +++       apic_timer_interrupt
119       1.1162  +142.7251 do_timer
97        0.9099  -31.5541  ide_inb
82        0.7692  +++       hrtimer_run_queues
81        0.7598  -34.7294  ide_outb
80        0.7504  +30.5412  irq_entries_start
79        0.7410  +2478.1892 rebalance_tick
70        0.6566  +315.3584 _spin_lock_irqsave
63        0.5909  +++       send_IPI_mask_bitmask
59        0.5534  +220.9138 _spin_unlock_irqrestore
56        0.5253  +7210.3086 do_softirq
53        0.4971  +2206.2283 __do_softirq
47        0.4409  +457.7671 acpi_hw_register_read
45        0.4221  +319.5968 schedule
43        0.4033  +5513.2727 acpi_set_register
41        0.3846  +++       raise_softirq
41        0.3846  +154.8662 run_timer_softirq
40        0.3752  +100.8327 __do_IRQ
33        0.3095  +258.9884 acpi_hw_low_level_read
33        0.3095  -44.7710  delay_tsc
32        0.3002  -11.1209  kmem_cache_free
31        0.2908  +124.8210 cpu_idle
31        0.2908  +152.9236 handle_IRQ_event
27        0.2533  -2.0941   page_fault
23        0.2157  +150.2040 do_IRQ
23        0.2157  +++       scheduler_tick
23        0.2157  +++       smp_apic_timer_interrupt
21        0.1970  +149.2151 common_interrupt
21        0.1970  -14.3323  do_wp_page
21        0.1970  +291.6237 find_busiest_group
21        0.1970  +2641.3657 softlockup_tick
20        0.1876  +226.3531 hweight32
20        0.1876  +190.0916 restore_nocheck
19        0.1782  +2380.2833 _spin_lock_irq
19        0.1782  -24.8399  ide_outsw
19        0.1782  +++       update_process_times
18        0.1688  +++       account_system_time
18        0.1688  -21.6753  cfb_imageblit
17        0.1595  +58.5143  blk_rq_map_sg
17        0.1595  -14.6461  i8042_interrupt
17        0.1595  +454.8002 irq_exit
16        0.1501  -5.0609   __handle_mm_fault
16        0.1501  +16.0366  acpi_ns_delete_namespace_by_owner
16        0.1501  +39.2440  end_buffer_async_write
16        0.1501  +16.0366  kmem_cache_alloc
13        0.1219  -26.2158  __might_sleep
13        0.1219  +++       _local_bh_enable
13        0.1219  +30.5412  radix_tree_tag_clear
13        0.1219  +748.5180 run_posix_cpu_timers
12        0.1126  -2.0941   ide_outbsync
12        0.1126  +++       profile_tick
12        0.1126  +1466.4947 rcu_pending
11        0.1032  +59.5504  __make_request
11        0.1032  +1335.9535 _spin_unlock_irq
11        0.1032  +2.5681   acpi_get_register
11        0.1032  +30.5412  acpi_ns_get_parent_node
11        0.1032  +2.5681   kmem_cache_zalloc
11        0.1032  +187.1907 ll_back_merge_fn
10        0.0938  +1205.4123 __rcu_pending
10        0.0938  +18.6738  __switch_to
10        0.0938  +1205.4123 acpi_hw_register_write
10        0.0938  +117.5687 bio_init
10        0.0938  +63.1765  dec_zone_page_state
10        0.0938  -18.4117  ide_insw
10        0.0938  +45.0458  radix_tree_tag_set

Created attachment 144425 [details]
ac vs bc vmlinux profile

(In reply to comment #5)
> (In reply to comment #4)
> > When it is AC powered top shows no more than 50% idle, when I plug it off it's
> > >90% idle. Using top I can not trace down the process which loads the processor,
> > the only sure thing is that it's the same in init modes 5 and 3, so it does not
> > seem to be X or gnome stuff.
> > 
> > I've installed all the updates available today, no luck. :(
> > 
> > How do I find out which process is hogging the cpu when running on AC?
> > 
> 
> 
> This is perhaps not the same bug, my proc is idle on AC and battery and still
> the governor does not work.

How much idle does top show when on AC?

(In reply to comment #9)

My mistake, sorry :

AC powered :
Cpu(s): 54.3%us, 14.3%sy,  0.0%ni, 25.7%id,  0.0%wa,  2.9%hi,  2.9%si,  0.0%st

Battery powered :
Cpu(s):  6.6%us,  2.6%sy,  0.0%ni, 89.4%id,  0.0%wa,  0.7%hi,  0.7%si,  0.0%st

Have the same Problem on a Sony Vaio VGN315H. Makes me very unhappy with core 6 ...

I found a workaround that works at least on the Sony Vaio FJ170B.

The problem appears to be with the power management built into the kernel but
the cpuspeed daemon DOES work.  The start-up script checks to see if cpu
frequency scaling in the kernel is handling frequency scaling and in the case of
these systems it assumes it does and does NOT start frequency scaling.

The workaround is to make a small change to /etc/init.d/cpuspeed is to trick it
into starting cpuspeed.  Right around line 60 add the "drv=broken" line and
cpuspeed will start when the service is started and frequency scaling will work
like it did back in Fedora Core 5.

                [ ! -f ${cpu0freqd}/scaling_driver ] && return 0

                drv=`cat ${cpu0freqd}/scaling_driver`

drv=broken      # This will force /usr/sbin/cpuspeed to start
                case "$drv" in
                centrino|powernow-k8)

(In reply to comment #12)
> I found a workaround that works at least on the Sony Vaio FJ170B.
> 
> The problem appears to be with the power management built into the kernel but
> the cpuspeed daemon DOES work.  The start-up script checks to see if cpu
> frequency scaling in the kernel is handling frequency scaling and in the case of
> these systems it assumes it does and does NOT start frequency scaling.

This might be a different issue.

The problem seems to be that cpu utilization is high when running on AC, and it
seems that it is acpi code that is hogging the cpu. As the cpu usage is high the
governor does not deem it necessary to lower the frequency. When running on BC
the cpu usage is low and the governor does its job just fine.

You're right, there might be more than one issue.  Mine is similar to the issue
the original reporter has.

On my Vaio at least even if the CPU is completely idle the CPU frequency always
stays at the highest frequency whenever on AC power.  This laptop runs hot so
with the CPU always high the fan is contantly running and making a lot of noise.  

It works fine on battery.

The Workaround, Gregory mentioned, works for me fine too. Thx.

I have the same Problem on my Asus A6VA. 
When i made the Workaround from Comment #12 cpu scaling works. But top shows
this on idle:
Cpu(s): 53.8%us, 10.3%sy,  0.0%ni, 35.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

The workaround works, but it is less effifcient than the kernel power management
: it is much less responsive on my computer.

New Version of cpuspeed - cpuspeed-1.2.1-1.43.fc6 - disables above mentioned
workaround ... so, the update was a functional downgrade ... :-( 

I found a solution for the problem.:-)
I add "nosmp irqpoll" to the boot parameters. Top show now this on idle
Cpu(s):  2.0%us,  0.3%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Workaround from comment #19 works fine :)
Since then I get a "Disabling IRQ #6" at boot time but it has no consequences.

Workaround from comment #19 works not so fine for me. Governor works correct but
automount and/or printing are disfunctional.

:-(

(Yes, i have a sony-notebook :-( )

@ Peter Schultz
can you test if your printer and automount works with nosmp acpi=noirq.

@ Alex

Have tried. Scaling works :) but wlan (ipw2200) disabled ... :-( So, not
functional at all ....

@ Alex

Have tried. Scaling works :) but wlan (ipw2200) disabled ... :-( So, not
functional at all ....

This problem is present on my laptop also (the CPU is a Pentium M740, infacts)

[root@parity ~]# uname --all
Linux parity 2.6.19-1.2911.6.5.fc6 #1 SMP Sun Mar 4 16:41:13 EST 2007 i686 i686
i386 GNU/Linux
[root@parity ~]# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.73GHz
stepping        : 8
cpu MHz         : 1729.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up est tm2
bogomips        : 3492.33

Same in the new kernel also:

[root@parity ~]# uname --all
Linux parity 2.6.20-1.2925.fc6 #1 SMP Sat Mar 10 19:15:16 EST 2007 i686 i686
i386 GNU/Linux

I found this on the Kernel Bugzilla.
http://bugzilla.kernel.org/show_bug.cgi?id=8193

the failure is because of the smp kernel which is integrated into the kernel, 
and so the notebooks choose a false mode for it.. when you deactivate smp in 
the kernel and compile it new the problem is solved.

I think this should also work on Fedora but I didn't test it.

I tried Alex's suggestion and it worked for me.
Laptop: Sony Vaio FJ1S Centrino Laptop

I followed the guide in

http://www.howtoforge.com/kernel_compilation_fedora

for making  a new kernel rpm under FC6

I disabled SMP in the kernel and the ondemand governor now works fine with AC
power connected.

I did make the same steps as Dave Maxwell disabling the SMP in the kernel
compilation... and the on demand governor works again. 

However, one should fix this bug: not every people can recompile a kernel.

Just FTR, this bug does not bite my Asus M6A laptop with FC7-test4's kernel 
anymore.

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

I am now using Fedora 8 on the same notebook (ASUS M5Ae). CPU scaling is working
fine.