Skip to content
  1. Aug 05, 2009
    • Thomas Renninger's avatar
      [CPUFREQ] Fix a kobject reference bug related to managed CPUs · d5194dec
      Thomas Renninger authored
      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: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      d5194dec
    • Prarit Bhargava's avatar
      [CPUFREQ] Do not set policy for offline cpus · 42c74b84
      Prarit Bhargava authored
      
      
      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: default avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      42c74b84
    • Pallipadi, Venkatesh's avatar
      [CPUFREQ] Fix NULL pointer dereference regression in conservative governor · 26d204af
      Pallipadi, Venkatesh authored
      
      
      Commit ee88415c
      introduced this regression when it removed enable bit in cpu_dbs_info_s.
      That added a possibility of dbs_cpufreq_notifier getting called for a
      CPU that is not yet managed by conservative governor. That will happen
      as the transition notifier is set as soon as one CPU switches to
      conservative governor and other CPUs can get a NULL pointer dereference
      without the enable bit check. Add the enable bit back again.
      
      Reported-by: default avatarLermytte Christophe <Christophe.Lermytte@thomson.net>
      Signed-off-by: default avatarVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      26d204af
  2. Aug 03, 2009
  3. Aug 02, 2009
  4. Aug 01, 2009