1. 04 8月, 2010 2 次提交
  2. 10 4月, 2010 1 次提交
  3. 01 4月, 2010 1 次提交
    • A
      [CPUFREQ] fix a lockdep warning · 499bca9b
      Amerigo Wang 提交于
      There is no need to do sysfs_remove_link() or kobject_put() etc.
      when policy_rwsem_write is held, move them after releasing the lock.
      
      This fixes the lockdep warning:
      
      halt/4071 is trying to acquire lock:
       (s_active){++++.+}, at: [<c0000000001ef868>] .sysfs_addrm_finish+0x58/0xc0
      
      but task is already holding lock:
       (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [<c0000000004cd6ac>] .lock_policy_rwsem_write+0x84/0xf4
      Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      499bca9b
  4. 08 3月, 2010 1 次提交
  5. 25 11月, 2009 2 次提交
    • T
      [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface · e2f74f35
      Thomas Renninger 提交于
      This interface is mainly intended (and implemented) for ACPI _PPC BIOS
      frequency limitations, but other cpufreq drivers can also use it for
      similar use-cases.
      
      Why is this needed:
      
      Currently it's not obvious why cpufreq got limited.
      People see cpufreq/scaling_max_freq reduced, but this could have
      happened by:
        - any userspace prog writing to scaling_max_freq
        - thermal limitations
        - hardware (_PPC in ACPI case) limitiations
      
      Therefore export bios_limit (in kHz) to:
        - Point the user that it's the BIOS (broken or intended) which limits
          frequency
        - Export it as a sysfs interface for userspace progs.
          While this was a rarely used feature on laptops, there will appear
          more and more server implemenations providing "Green IT" features like
          allowing the service processor to limit the frequency. People want
          to know about HW/BIOS frequency limitations.
      
      All ACPI P-state driven cpufreq drivers are covered with this patch:
        - powernow-k8
        - powernow-k7
        - acpi-cpufreq
      
      Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
      via _PPC, exposed by bios_limit:
      # echo 2200000 >cpu2/cpufreq/scaling_max_freq
      # cat cpu*/cpufreq/scaling_max_freq
      2600000
      2600000
      2200000
      2200000
      # #scaling_max_freq shows general user/thermal/BIOS limitations
      
      # cat cpu*/cpufreq/bios_limit
      2600000
      2600000
      2800000
      2800000
      # #bios_limit only shows the HW/BIOS limitation
      
      CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
      CC: Len Brown <lenb@kernel.org>
      CC: davej@codemonkey.org.uk
      CC: linux@dominikbrodowski.net
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e2f74f35
    • A
      [CPUFREQ] make internal cpufreq_add_dev_* static · cf3289d0
      Alex Chiang 提交于
      No need to export these symbols; make them static.
      
      	cpufreq_add_dev_policy
      	cpufreq_add_dev_symlink
      	cpufreq_add_dev_interface
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      cf3289d0
  6. 18 11月, 2009 2 次提交
    • P
      [CPUFREQ] Fix stale cpufreq_cpu_governor pointer · 90e41bac
      Prarit Bhargava 提交于
      Dave,
      
      Attached is an update of my patch against the cpufreq fixes branch.
      
      Before applying the patch I compiled and booted the tree to see if the panic
      was still there -- to my surprise it was not.  This is because of the conversion
      of cpufreq_cpu_governor to a char[].
      
      While the panic is kaput, the problem of stale data continues and my patch is
      still valid.  It is possible to end up with the wrong governor after hotplug
      events because CPUFREQ_DEFAULT_GOVERNOR is statically linked to a default,
      while the cpu siblings may have had a different governor assigned by a user.
      
      ie) the patch is still needed in order to keep the governors assigned
      properly when hotplugging devices
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      90e41bac
    • D
      [CPUFREQ] Fix use after free on governor restore · e77b89f1
      Dmitry Monakhov 提交于
      Currently on governer backup/restore path we storing governor's pointer.
      This is wrong because one may unload governor's module after cpu goes
      offline. As result use-after-free will take place on restored cpu.
      It is not easy to exploit this bug, but still we have to close this
      issue ASAP. Issue was introduced by following commit
      084f3493
      
      ##TESTCASE##
      #!/bin/sh -x
      modprobe acpi_cpufreq
      # Any non default governor, in may case it is "ondemand"
      modprobe cpufreq_ondemand
      echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
      rmmod acpi_cpufreq
      rmmod cpufreq_ondemand
      modprobe acpi_cpufreq  # << use-after-free here.
      Signed-off-by: NDmitry Monakhov <dmonakhov@openvz.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e77b89f1
  7. 29 10月, 2009 1 次提交
    • T
      percpu: make percpu symbols in cpufreq unique · f1625066
      Tejun Heo 提交于
      This patch updates percpu related symbols in cpufreq such that percpu
      symbols are unique and don't clash with local symbols.  This serves
      two purposes of decreasing the possibility of global percpu symbol
      collision and allowing dropping per_cpu__ prefix from percpu symbols.
      
      * drivers/cpufreq/cpufreq.c: s/policy_cpu/cpufreq_policy_cpu/
      * drivers/cpufreq/freq_table.c: s/show_table/cpufreq_show_table/
      * arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: s/drv_data/acfreq_data/
        					      s/old_perf/acfreq_old_perf/
      
      Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
      which cause name clashes" patch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      f1625066
  8. 02 9月, 2009 9 次提交
    • M
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) · 395913d0
      Mathieu Desnoyers 提交于
      remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)
      
      commit	42a06f21
      
      Missed a call site for CPUFREQ_GOV_STOP to remove the rwlock taken around the
      teardown. To make a long story short, the rwlock write-lock causes a circular
      dependency with cancel_delayed_work_sync(), because the timer handler takes the
      read lock.
      
      Note that all callers to __cpufreq_set_policy are taking the rwsem. All sysfs
      callers (writers) hold the write rwsem at the earliest sysfs calling stage.
      
      However, the rwlock write-lock is not needed upon governor stop.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      CC: rjw@sisk.pl
      CC: mingo@elte.hu
      CC: Shaohua Li <shaohua.li@intel.com>
      CC: Pekka Enberg <penberg@cs.helsinki.fi>
      CC: Dave Young <hidave.darkstar@gmail.com>
      CC: "Rafael J. Wysocki" <rjw@sisk.pl>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      CC: trenn@suse.de
      CC: sven.wegener@stealer.net
      CC: cpufreq@vger.kernel.org
      Signed-off-by: NDave Jones <davej@redhat.com>
      395913d0
    • T
      [CPUFREQ] Introduce global, not per core: /sys/devices/system/cpu/cpufreq · 8aa84ad8
      Thomas Renninger 提交于
      Currently everything in the cpufreq layer is per core based.
      This does not reflect reality, for example ondemand on conservative
      governors have global sysfs variables.
      
      Introduce a global cpufreq directory and add the kobject to the governor
      struct, so that governors can easily access it.
      The directory is initialized in the cpufreq_core_init initcall and thus will
      always be created if cpufreq is compiled in, even if no cpufreq driver is
      active later.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      8aa84ad8
    • T
      [CPUFREQ] Bail out of cpufreq_add_dev if the link for a managed CPU got created · 4bfa042c
      Thomas Renninger 提交于
      Doing:
      echo 0 >cpu1/online
      echo 1 >cpu1/online
      
      on a managed CPU will result in:
      Jul 22 15:15:37 linux kernel: [   80.013864] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xcf/0xe6()
      Jul 22 15:15:37 linux kernel: [   80.013866] Hardware name: To Be Filled By O.E.M.
      Jul 22 15:15:37 linux kernel: [   80.013868] sysfs: cannot create duplicate filename '/devices/system/cpu/cpu1/cpufreq'
      Jul 22 15:15:37 linux kernel: [   80.013870] Modules linked in: powernow_k8
      Jul 22 15:15:37 linux kernel: [   80.013874] Pid: 5750, comm: bash Not tainted 2.6.31-rc2 #40
      Jul 22 15:15:37 linux kernel: [   80.013876] Call Trace:
      Jul 22 15:15:37 linux kernel: [   80.013879]  [<ffffffff8112ebda>] ? sysfs_add_one+0xcf/0xe6
      Jul 22 15:15:37 linux kernel: [   80.013884]  [<ffffffff81041926>] warn_slowpath_common+0x77/0xa4
      Jul 22 15:15:37 linux kernel: [   80.013888]  [<ffffffff810419a0>] warn_slowpath_fmt+0x3c/0x3e
      Jul 22 15:15:37 linux kernel: [   80.013891]  [<ffffffff8112ebda>] sysfs_add_one+0xcf/0xe6
      Jul 22 15:15:37 linux kernel: [   80.013894]  [<ffffffff8112f213>] create_dir+0x58/0x87
      Jul 22 15:15:37 linux kernel: [   80.013898]  [<ffffffff8112f27a>] sysfs_create_dir+0x38/0x4f
      Jul 22 15:15:37 linux kernel: [   80.013902]  [<ffffffff811ffb8a>] kobject_add_internal+0x11f/0x1de
      Jul 22 15:15:37 linux kernel: [   80.013905]  [<ffffffff811ffd21>] kobject_add_varg+0x41/0x4e
      Jul 22 15:15:37 linux kernel: [   80.013908]  [<ffffffff811ffd7a>] kobject_init_and_add+0x4c/0x57
      Jul 22 15:15:37 linux kernel: [   80.013913]  [<ffffffff810667bc>] ? mark_lock+0x22/0x228
      Jul 22 15:15:37 linux kernel: [   80.013918]  [<ffffffff813e8a3b>] cpufreq_add_dev_interface+0x40/0x1e4
      ...
      
      This bug slipped in by git commit:
      150b06f7f223cfd0f808737a5243cceca8ea47fa
      
      When splitting up cpufreq_add_dev, the whole cpufreq_add_dev function
      is not left anymore, only cpufreq_add_dev_policy.
      This patch should reconstruct the identical functionality again as it
      was before the split.
      
      CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      4bfa042c
    • D
      [CPUFREQ] Factor out policy setting from cpufreq_add_dev · ecf7e461
      Dave Jones 提交于
      Signed-off-by: NDave Jones <davej@redhat.com>
      ecf7e461
    • D
      909a694e
    • D
      19d6f7ec
    • D
      [CPUFREQ] cleanup up -ENOMEM handling in cpufreq_add_dev · 059019a3
      Dave Jones 提交于
      Signed-off-by: NDave Jones <davej@redhat.com>
      059019a3
    • D
      [CPUFREQ] Reduce scope of cpu_sys_dev in cpufreq_add_dev · 54e6fe16
      Dave Jones 提交于
      Signed-off-by: NDave Jones <davej@redhat.com>
      54e6fe16
    • D
      [CPUFREQ] Re-enable cpufreq suspend and resume code · ce6c3997
      Dominik Brodowski 提交于
      Commit 4bc5d341 is broken and causes regressions:
      
      (1) cpufreq_driver->resume() and ->suspend() were only called on
      __powerpc__, but you could set them on all architectures. In fact,
      ->resume() was defined and used before the PPC-related commit
      42d4dc3f complained about in 4bc5d341.
      
      (2) Therfore, the resume functions in acpi_cpufreq and speedstep-smi
      would never be called.
      
      (3) This means speedstep-smi would be unusuable after suspend or resume.
      
      The _real_ problem was calling cpufreq_driver->get() with interrupts
      off, but it re-enabling interrupts on some platforms. Why is ->get()
      necessary?
      
      Some systems like to change the CPU frequency behind our
      back, especially during BIOS-intensive operations like suspend or
      resume. If such systems also use a CPU frequency-dependant timing loop,
      delays might be off by large factors. Therefore, we need to ascertain
      as soon as possible that the CPU frequency is indeed at the speed we
      think it is. You can do this two ways: either setting it anew, or trying
      to get it. The latter is what was done, the former also has the same IRQ
      issue.
      
      So, let's try something different: defer the checking to after interrupts
      are re-enabled, by calling cpufreq_update_policy() (via schedule_work()).
      Timings may be off until this later stage, so let's watch out for
      resume regressions caused by the deferred handling of frequency changes
      behind the kernel's back.
      Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      ce6c3997
  9. 05 8月, 2009 3 次提交
    • D
      [CPUFREQ] Make cpufreq suspend code conditional on powerpc. · 4bc5d341
      Dave Jones 提交于
      The suspend code runs with interrupts disabled, and the powerpc workaround we
      do in the cpufreq suspend hook calls the drivers ->get method.
      
      powernow-k8's ->get does an smp_call_function_single
      which needs interrupts enabled
      
      cpufreq's suspend/resume code was added in 42d4dc3f to work around
      a hardware problem on ppc powerbooks.  If we make all this code
      conditional on powerpc, we avoid the issue above.
      Signed-off-by: NDave Jones <davej@redhat.com>
      4bc5d341
    • T
      [CPUFREQ] Fix a kobject reference bug related to managed CPUs · d5194dec
      Thomas Renninger 提交于
      The first offline/online cycle is successful, the second not.
      Doing:
      echo 0 >cpu1/online
      echo 1 >cpu1/online
      echo 0 >cpu1/online
      
      The last command will trigger:
      Jul 22 14:39:50 linux kernel: [  593.210125] ------------[ cut here ]------------
      Jul 22 14:39:50 linux kernel: [  593.210139] WARNING: at lib/kref.c:43 kref_get+0x23/0x2b()
      Jul 22 14:39:50 linux kernel: [  593.210144] Hardware name: To Be Filled By O.E.M.
      Jul 22 14:39:50 linux kernel: [  593.210148] Modules linked in: powernow_k8
      Jul 22 14:39:50 linux kernel: [  593.210158] Pid: 378, comm: kondemand/2 Tainted: G        W  2.6.31-rc2 #38
      Jul 22 14:39:50 linux kernel: [  593.210163] Call Trace:
      Jul 22 14:39:50 linux kernel: [  593.210171]  [<ffffffff812008e8>] ? kref_get+0x23/0x2b
      Jul 22 14:39:50 linux kernel: [  593.210181]  [<ffffffff81041926>] warn_slowpath_common+0x77/0xa4
      Jul 22 14:39:50 linux kernel: [  593.210190]  [<ffffffff81041962>] warn_slowpath_null+0xf/0x11
      Jul 22 14:39:50 linux kernel: [  593.210198]  [<ffffffff812008e8>] kref_get+0x23/0x2b
      Jul 22 14:39:50 linux kernel: [  593.210206]  [<ffffffff811ffa19>] kobject_get+0x1a/0x22
      Jul 22 14:39:50 linux kernel: [  593.210214]  [<ffffffff813e815d>] cpufreq_cpu_get+0x8a/0xcb
      Jul 22 14:39:50 linux kernel: [  593.210222]  [<ffffffff813e87d1>] __cpufreq_driver_getavg+0x1d/0x67
      Jul 22 14:39:50 linux kernel: [  593.210231]  [<ffffffff813ea18f>] do_dbs_timer+0x158/0x27f
      Jul 22 14:39:50 linux kernel: [  593.210240]  [<ffffffff810529ea>] worker_thread+0x200/0x313
      ...
      
      The output continues on every do_dbs_timer ondemand freq checking poll.
      This regression was introduced by git commit:
      3f4a782b
      
      The policy is released when the cpufreq device is removed in:
      __cpufreq_remove_dev():
      	/* if this isn't the CPU which is the parent of the kobj, we
      	 * only need to unlink, put and exit
      	 */
      
      Not creating the symlink is not sever at all.
      As long as:
      sysfs_remove_link(&sys_dev->kobj, "cpufreq");
      handles it gracefully that the symlink did not exist.
      Possibly no error should be returned at all, because ondemand
      governor would still provide the same functionality.
      Userspace in userspace gov case might be confused if the link
      is missing.
      
      Resolves http://bugzilla.kernel.org/show_bug.cgi?id=13903
      
      CC: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      d5194dec
    • P
      [CPUFREQ] Do not set policy for offline cpus · 42c74b84
      Prarit Bhargava 提交于
      Suspend/Resume fails on multi socket, multi core systems because the cpufreq
      code erroneously sets the per_cpu policy_cpu value when a logical cpu is
      offline.
      
      This most notably results in missing sysfs files that are used to set the
      cpu frequencies of the various cpus.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      42c74b84
  10. 09 7月, 2009 1 次提交
  11. 07 7月, 2009 2 次提交
  12. 09 6月, 2009 1 次提交
  13. 27 5月, 2009 1 次提交
    • M
      [CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call · 42a06f21
      Mathieu Desnoyers 提交于
      * 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
      dbs_timer_exit().
      
      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);
      
              unlock_policy_rwsem_write(cpu);
      
      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
      unneeded.
      Signed-off-by: NMathieu 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: NDave Jones <davej@redhat.com>
      42a06f21
  14. 10 3月, 2009 1 次提交
    • D
      Revert "[CPUFREQ] Disable sysfs ui for p4-clockmod." · 129f8ae9
      Dave Jones 提交于
      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: NDave Jones <davej@redhat.com>
      129f8ae9
  15. 25 2月, 2009 2 次提交
  16. 06 1月, 2009 1 次提交
  17. 06 12月, 2008 2 次提交
    • M
      [CPUFREQ] Fix on resume, now preserves user policy min/max. · 187d9f4e
      Mike Chan 提交于
      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: NMike Chan <mike@android.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      187d9f4e
    • M
      [CPUFREQ] Disable sysfs ui for p4-clockmod. · e088e4c9
      Matthew Garrett 提交于
      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
      wait-states.
      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: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      e088e4c9
  18. 10 10月, 2008 2 次提交
  19. 31 7月, 2008 1 次提交
  20. 10 6月, 2008 1 次提交
  21. 07 6月, 2008 1 次提交
  22. 30 5月, 2008 1 次提交
    • L
      [CPUFREQ] fix double unlock of cpu_policy_rwsem in drivers/cpufreq/cpufreq.c · dca02613
      Lothar Waßmann 提交于
      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)
       r4:c3c34884
      [<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: NLothar Waßmann <LW@KARO-electronics.de>
      Signed-off-by: NDave Jones <davej@redhat.com>
      dca02613
  23. 24 5月, 2008 1 次提交