1. 09 Jun, 2009 1 commit
  2. 26 May, 2009 1 commit
    • Mathieu Desnoyers's avatar
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call · 42a06f21
      Mathieu Desnoyers authored
      * Rafael J. Wysocki (rjw@sisk.pl) wrote:
      > This message has been generated automatically as a part of a report
      > of regressions introduced between 2.6.28 and 2.6.29.
      > The following bug entry is on the current list of known regressions
      > introduced between 2.6.28 and 2.6.29.  Please verify if it still should
      > be listed and let me know (either way).
      > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13186
      > Subject		: cpufreq timer teardown problem
      > Submitter	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Date		: 2009-04-23 14:00 (24 days old)
      > References	: http://marc.info/?l=linux-kernel&m=124049523515036&w=4
      > Handled-By	: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      > Patch		: http://patchwork.kernel.org/patch/19754/
      > 		  http://patchwork.kernel.org/patch/19753/
      The patches linked above depend on the following patch to remove
      circular locking dependency :
      cpufreq: remove rwsem lock from CPUFREQ_GOV_STOP call
      (the following issue was faced when using cancel_delayed_work_sync() in the
      timer teardown (which fixes a race).
      * KOSAKI Motohiro (kosaki.motohiro@jp.fujitsu.com) wrote:
      > Hi
      > my box output following warnings.
      > it seems regression by commit 7ccc7608b836e58fbacf65ee4f8eefa288e86fac.
      > A: work -> do_dbs_timer()  -> cpu_policy_rwsem
      > B: store() -> cpu_policy_rwsem -> cpufreq_governor_dbs() -> work
      Hrm, I think it must be due to my attempt to fix the timer teardown race
      in ondemand governor mixed with new locking behavior in 2.6.30-rc.
      The rwlock seems to be taken around the whole call to
      cpufreq_governor_dbs(), when it should be only taken around accesses to
      the locked data, and especially *not* around the call to
      Reverting my fix attempt would put the teardown race back in place
      (replacing the cancel_delayed_work_sync by cancel_delayed_work).
      Instead, a proper fix would imply modifying this critical section :
      cpufreq.c: __cpufreq_remove_dev()
              if (cpufreq_driver->target)
                      __cpufreq_governor(data, CPUFREQ_GOV_STOP);
      To make sure the __cpufreq_governor() callback is not called with rwsem
      held. This would allow execution of cancel_delayed_work_sync() without
      being nested within the rwsem.
      Applies on top of the 2.6.30-rc5 tree.
      Required to remove circular dep in teardown of both conservative and
      ondemande governors so they can use cancel_delayed_work_sync().
      CPUFREQ_GOV_STOP does not modify the policy, therefore this locking seemed
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Greg KH <greg@kroah.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: "Rafael J. Wysocki" <rjw@sisk.pl>
      CC: Ben Slusky <sluskyb@paranoiacs.org>
      CC: Chris Wright <chrisw@sous-sol.org>
      CC: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  3. 09 Mar, 2009 1 commit
    • Dave Jones's avatar
      Revert "[CPUFREQ] Disable sysfs ui for p4-clockmod." · 129f8ae9
      Dave Jones authored
      This reverts commit e088e4c9
      Removing the sysfs interface for p4-clockmod was flagged as a
      regression in bug 12826.
      Course of action:
       - Find out the remaining causes of overheating, and fix them
         if possible. ACPI should be doing the right thing automatically.
         If it isn't, we need to fix that.
       - mark p4-clockmod ui as deprecated
       - try again with the removal in six months.
      It's not really feasible to printk about the deprecation, because
      it needs to happen at all the sysfs entry points, which means adding
      a lot of strcmp("p4-clockmod".. calls to the core, which.. bleuch.
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  4. 25 Feb, 2009 2 commits
  5. 06 Jan, 2009 1 commit
  6. 05 Dec, 2008 2 commits
    • Mike Chan's avatar
      [CPUFREQ] Fix on resume, now preserves user policy min/max. · 187d9f4e
      Mike Chan authored
      Previously driver resume would always set the current policy min/max with
      the cpuinfo min/max, defined by user_policy.min/max. Resulting in a reset
      of policy settings when policy.min/max != cpuinfo.min/max when coming out
      of suspend. Now user_policy is saved as the policy instead of cpuinfo to
      preserve what the user actually set.
      Signed-off-by: default avatarMike Chan <mike@android.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
    • Matthew Garrett's avatar
      [CPUFREQ] Disable sysfs ui for p4-clockmod. · e088e4c9
      Matthew Garrett authored
      p4-clockmod has a long history of abuse.   It pretends to be a CPU
      frequency scaling driver, even though it doesn't actually change
      the CPU frequency, but instead just modulates the frequency with
      The biggest misconception is that when running at the lower 'frequency'
      p4-clockmod is saving power.  This isn't the case, as workloads running
      slower take longer to complete, preventing the CPU from entering deep C states.
      However p4-clockmod does have a purpose.  It can prevent overheating.
      Having it hooked up to the cpufreq interfaces is the wrong way to achieve
      cooling however. It should instead be hooked up to ACPI.
      This diff introduces a means for a cpufreq driver to register with the
      cpufreq core, but not present a sysfs interface.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  7. 09 Oct, 2008 2 commits
  8. 30 Jul, 2008 1 commit
  9. 09 Jun, 2008 1 commit
  10. 06 Jun, 2008 1 commit
  11. 29 May, 2008 1 commit
    • Lothar Waßmann's avatar
      [CPUFREQ] fix double unlock of cpu_policy_rwsem in drivers/cpufreq/cpufreq.c · dca02613
      Lothar Waßmann authored
      In drivers/cpufreq/cpufreq.c the function cpufreq_add_dev() takes the
      error exit 'err_out_unregister' from different places once with the
      'cpu_policy_rwsem' lock held, once with the lock released:
      |		if (ret)
      |			goto err_out_unregister;
      |	}
      |	policy->governor = NULL; /* to assure that the starting sequence is
      |				  * run in cpufreq_set_policy */
      |	/* set default policy */
      |	ret = __cpufreq_set_policy(policy, &new_policy);
      |	policy->user_policy.policy = policy->policy;
      |	policy->user_policy.governor = policy->governor;
      |	unlock_policy_rwsem_write(cpu);
      |	if (ret) {
      |		dprintk("setting policy failed\n");
      |		goto err_out_unregister;
      |	}
      This leads to the following error message in case of a failing
      __cpufreq_set_policy() call:
      [ BUG: bad unlock balance detected! ]
      swapper/1 is trying to release lock (&per_cpu(cpu_policy_rwsem, cpu)) at:
      [<c01b4564>] unlock_policy_rwsem_write+0x30/0x40
      but there are no more locks to release!
      other info that might help us debug this:
      1 lock held by swapper/1:
       #0:  (sysdev_drivers_lock){--..}, at: [<c018fd18>] sysdev_driver_register+0x74/0x130
      stack backtrace:
      [<c002f588>] (dump_stack+0x0/0x14) from [<c00692fc>] (print_unlock_inbalance_bug+0xc8/0x104)
      [<c0069234>] (print_unlock_inbalance_bug+0x0/0x104) from [<c006b7ac>] (lock_release_non_nested+0xc4/0x19c)
       r6:00000028 r5:c3c1ab80 r4:c01b4564
      [<c006b6e8>] (lock_release_non_nested+0x0/0x19c) from [<c006b9e0>] (lock_release+0x15c/0x18c)
       r8:60000013 r7:00000001 r6:c01b4564 r5:c0541bb4 r4:c3c1ab80
      [<c006b884>] (lock_release+0x0/0x18c) from [<c0061ba0>] (up_write+0x24/0x30)
       r8:c0541b80 r7:00000000 r6:ffffffea r5:c3c34828 r4:c0541b8c
      [<c0061b7c>] (up_write+0x0/0x30) from [<c01b4564>] (unlock_policy_rwsem_write+0x30/0x40)
      [<c01b4534>] (unlock_policy_rwsem_write+0x0/0x40) from [<c01b4c40>] (cpufreq_add_dev+0x324/0x398)
      [<c01b491c>] (cpufreq_add_dev+0x0/0x398) from [<c018fd64>] (sysdev_driver_register+0xc0/0x130)
      [<c018fca4>] (sysdev_driver_register+0x0/0x130) from [<c01b3574>] (cpufreq_register_driver+0xbc/0x174)
      Signed-off-by: default avatarLothar Waßmann <LW@KARO-electronics.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  12. 23 May, 2008 1 commit
  13. 19 May, 2008 1 commit
  14. 28 Apr, 2008 6 commits
  15. 05 Mar, 2008 3 commits
    • Sam Ravnborg's avatar
      [CPUFREQ] fix section mismatch warnings · f6ebef30
      Sam Ravnborg authored
      Fix the following warnings:
      WARNING: vmlinux.o(.text+0xfe6711): Section mismatch in reference from the function cpufreq_unregister_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
      WARNING: vmlinux.o(.text+0xfe68af): Section mismatch in reference from the function cpufreq_register_driver() to the variable .cpuinit.data:cpufreq_cpu_notifier
      WARNING: vmlinux.o(.exit.text+0xc4fa): Section mismatch in reference from the function cpufreq_stats_exit() to the variable .cpuinit.data:cpufreq_stat_cpu_notifier
      The warnings were casued by references to unregister_hotcpu_notifier()
      from normal functions or exit functions.
      This is flagged by modpost as a potential error because
      it does not know that for the non HOTPLUG_CPU
      scenario the unregister_hotcpu_notifier() is a nop.
      Silence the warning by replacing the __initdata
      annotation with a __refdata annotation.
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarDave Jones <davej@codemonkey.org.uk>
    • Dave Jones's avatar
      [CPUFREQ] Fix missing cpufreq_cpu_put() call in ->store · a07530b4
      Dave Jones authored
      refactor to use gotos instead of explicit exit paths
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
    • Dave Jones's avatar
      [CPUFREQ] Fix missing cpufreq_cpu_put() call in ->show · 0db4a8a9
      Dave Jones authored
      refactor to use gotos instead of explicit exit paths
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  16. 21 Feb, 2008 1 commit
    • Balaji Rao's avatar
      cpufreq: fix kobject reference count handling · 7ab47050
      Balaji Rao authored
      The cpufreq core should not take an extra kobject reference count for no
      reason, and then refuse to release it.  This has been reported as
      keeping machines from properly powering down all the way.
      Signed-off-by: default avatarBalaji Rao <balajirrao@gmail.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Yi Yang <yi.y.yang@intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Frans Pop <elendil@planet.nl>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  17. 07 Feb, 2008 2 commits
    • Venki Pallipadi's avatar
      [CPUFREQ] Eliminate cpufreq_userspace scaling_setspeed deadlock · 9e76988e
      Venki Pallipadi authored
      Eliminate cpufreq_userspace scaling_setspeed deadlock.
      Luming Yu recently uncovered yet another cpufreq related deadlock.
      One thread that continuously switches the governors and the other thread that
      repeatedly cats the contents of cpufreq directory causes both these threads to
      go into a deadlock.
      Detailed examination of the deadlock showed the exact flow before the deadlock
      Thread 1			Thread 2
      ________			________
      				cats files under /sys/devices/.../cpufreq/
      Set governor to userspace
        Adds a new sysfs entry for
      				cats files under /sys/devices/.../cpufreq/
      Set governor to performance
        Holds cpufreq_rw_sem in write
        Sends a STOP notify to
        userspace governor
      				cat /sys/devices/.../cpufreq/scaling_setspeed
      				  Gets a handle on the above sysfs entry with
      				  Blocks while trying to get cpufreq_rw_sem
      				  in read mode
        Remove a sysfs entry for
          Blocks on sysfs_deactivate
          while waiting for earlier
          get_active (on other thread)
          to drain
      At this point both threads go into deadlock and any other thread that tries to
      do anything with sysfs cpufreq will also block.
      There seems to be no easy way to avoid this deadlock as long as
      cpufreq_userspace adds/removes the sysfs entry under same kobject as cpufreq.
      Below patch moves scaling_setspeed to cpufreq.c, keeping it always and calling
      back the governor on read/write. This is the cleanest fix I could think of,
      even though adding two callbacks in governor structure just for this seems
      Note that the change makes scaling_setspeed under /sys/.../cpufreq permanent
      and returns <unsupported> when governor is not userspace.
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
    • Joe Perches's avatar
      [CPUFREQ] drivers/cpufreq: Add missing "space" · a4a9df58
      Joe Perches authored
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  18. 30 Jan, 2008 1 commit
    • Yi Yang's avatar
      cpufreq: fix obvious condition statement error · 53391fa2
      Yi Yang authored
      The function __cpufreq_set_policy in file drivers/cpufreq/cpufreq.c
      has a very obvious error:
              if (policy->min > data->min && policy->min > policy->max) {
                      ret = -EINVAL;
                      goto error_out;
      This condtion statement is wrong because it returns -EINVAL only if
      policy->min is greater than policy->max (in this case,
      "policy->min > data->min" is true for ever.). In fact, it should
      return -EINVAL as well if policy->max is less than data->min.
      The correct condition should be:
      	if (policy->min > data->max || policy->max < data->min) {
      The following test result testifies the above conclusion:
      Before applying this patch:
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
      2394000 1596000
      [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      [root@yangyi-dev /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      -bash: echo: write error: Invalid argument
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      [root@yangyi-dev /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]#
      After applying this patch:
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
      2394000 1596000
      [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      [root@localhost /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
      [root@localhost /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      -bash: echo: write error: Invalid argument
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]# echo "1596000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]# echo "2394000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
      [root@localhost /]
      Signed-off-by: default avatarYi Yang <yi.y.yang@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  19. 25 Jan, 2008 2 commits
  20. 18 Dec, 2007 1 commit
  21. 12 Oct, 2007 1 commit
  22. 10 Oct, 2007 1 commit
    • Andi Kleen's avatar
      [CPUFREQ] Don't take semaphore in cpufreq_quick_get() · 9eb59573
      Andi Kleen authored
      I don't see any reason to take an expensive lock in cpufreq_quick_get()
      Reading policy->cur is a single atomic operation and after
      the lock is dropped again the state could change any time anyways.
      So don't take the lock in the first place.
      This also makes this function interrupt safe which is useful
      for some code of mine.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
  23. 04 Oct, 2007 4 commits
  24. 13 Jul, 2007 2 commits