1. 06 1月, 2014 4 次提交
  2. 31 12月, 2013 1 次提交
    • R
      intel_pstate: Fail initialization if P-state information is missing · 98a947ab
      Rafael J. Wysocki 提交于
      If pstate.current_pstate is 0 after the initial
      intel_pstate_get_cpu_pstates(), this means that we were unable to
      obtain any useful P-state information and there is no reason to
      continue, so free memory and return an error in that case.
      
      This fixes the following divide error occuring in a nested KVM
      guest:
      
      Intel P-state driver initializing.
      Intel pstate controlling: cpu 0
      cpufreq: __cpufreq_add_dev: ->get() failed
      divide error: 0000 [#1] SMP
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-0.rc4.git5.1.fc21.x86_64 #1
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      task: ffff88001ea20000 ti: ffff88001e9bc000 task.ti: ffff88001e9bc000
      RIP: 0010:[<ffffffff815c551d>]  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
      RSP: 0000:ffff88001ee03e18  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff88001a454348 RCX: 0000000000006100
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff88001ee03e38 R08: 0000000000000000 R09: 0000000000000000
      R10: ffff88001ea20000 R11: 0000000000000000 R12: 00000c0a1ea20000
      R13: 1ea200001ea20000 R14: ffffffff815c5400 R15: ffff88001a454348
      FS:  0000000000000000(0000) GS:ffff88001ee00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 0000000001c0c000 CR4: 00000000000006f0
      Stack:
       fffffffb1a454390 ffffffff821a4500 ffff88001a454390 0000000000000100
       ffff88001ee03ea8 ffffffff81083e9a ffffffff81083e15 ffffffff82d5ed40
       ffffffff8258cc60 0000000000000000 ffffffff81ac39de 0000000000000000
      Call Trace:
       <IRQ>
       [<ffffffff81083e9a>] call_timer_fn+0x8a/0x310
       [<ffffffff81083e15>] ? call_timer_fn+0x5/0x310
       [<ffffffff815c5400>] ? pid_param_set+0x130/0x130
       [<ffffffff81084354>] run_timer_softirq+0x234/0x380
       [<ffffffff8107aee4>] __do_softirq+0x104/0x430
       [<ffffffff8107b5fd>] irq_exit+0xcd/0xe0
       [<ffffffff81770645>] smp_apic_timer_interrupt+0x45/0x60
       [<ffffffff8176efb2>] apic_timer_interrupt+0x72/0x80
       <EOI>
       [<ffffffff810e15cd>] ? vprintk_emit+0x1dd/0x5e0
       [<ffffffff81757719>] printk+0x67/0x69
       [<ffffffff815c1493>] __cpufreq_add_dev.isra.13+0x883/0x8d0
       [<ffffffff815c14f0>] cpufreq_add_dev+0x10/0x20
       [<ffffffff814a14d1>] subsys_interface_register+0xb1/0xf0
       [<ffffffff815bf5cf>] cpufreq_register_driver+0x9f/0x210
       [<ffffffff81fb19af>] intel_pstate_init+0x27d/0x3be
       [<ffffffff81761e3e>] ? mutex_unlock+0xe/0x10
       [<ffffffff81fb1732>] ? cpufreq_gov_dbs_init+0x12/0x12
       [<ffffffff8100214a>] do_one_initcall+0xfa/0x1b0
       [<ffffffff8109dbf5>] ? parse_args+0x225/0x3f0
       [<ffffffff81f64193>] kernel_init_freeable+0x1fc/0x287
       [<ffffffff81f638d0>] ? do_early_param+0x88/0x88
       [<ffffffff8174b530>] ? rest_init+0x150/0x150
       [<ffffffff8174b53e>] kernel_init+0xe/0x130
       [<ffffffff8176e27c>] ret_from_fork+0x7c/0xb0
       [<ffffffff8174b530>] ? rest_init+0x150/0x150
      Code: c1 e0 05 48 63 bc 03 10 01 00 00 48 63 83 d0 00 00 00 48 63 d6 48 c1 e2 08 c1 e1 08 4c 63 c2 48 c1 e0 08 48 98 48 c1 e0 08 48 99 <49> f7 f8 48 98 48 0f af f8 48 c1 ff 08 29 f9 89 ca c1 fa 1f 89
      RIP  [<ffffffff815c551d>] intel_pstate_timer_func+0x11d/0x2b0
       RSP <ffff88001ee03e18>
      ---[ end trace f166110ed22cc37a ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Reported-and-tested-by: NKashyap Chamarthy <kchamart@redhat.com>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: All applicable <stable@vger.kernel.org>
      98a947ab
  3. 29 12月, 2013 2 次提交
  4. 23 12月, 2013 2 次提交
  5. 22 12月, 2013 4 次提交
    • D
      intel_pstate: Remove periodic P state boost · 91a4cd4f
      Dirk Brandewie 提交于
      Remove the periodic P state boost.  This code required for some corner
      case benchmark tests.  The calculation of the required P state was
      incorrect/inaccurate and would not allow P state increase.
      
      This was fixed by a combination of commits:
        2134ed4d cpufreq / intel_pstate: Change to scale off of max P-state
        d253d2a5 intel_pstate: Improve accuracy by not truncating until final result
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=64271Reported-by: NDoug Smythies <dsmythies@telus.net>
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      91a4cd4f
    • D
      intel_pstate: Add setting voltage value for baytrail P states. · 007bea09
      Dirk Brandewie 提交于
      Baytrail requires setting P state and voltage pairs when adjusting the
      requested P state.  Add function for retrieving the valid voltage
      values and modify *_set_pstate() functions to caluclate the
      appropriate voltage for the requested P state.
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      007bea09
    • J
      cpufreq: Use CONFIG_CPU_FREQ_DEFAULT_* to set initial policy for setpolicy drivers · a27a9ab7
      Jason Baron 提交于
      When configuring a default governor (via CONFIG_CPU_FREQ_DEFAULT_*) with the
      intel_pstate driver, the desired default policy is not properly set. For
      example, setting 'CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE' ends up with the
      'powersave' policy being set.
      
      Fix by configuring the correct default policy, if either 'powersave' or
      'performance' are requested. Otherwise, fallback to what the driver originally
      set via its 'init' routine.
      Signed-off-by: NJason Baron <jbaron@akamai.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a27a9ab7
    • V
      cpufreq: remove sysfs files for CPUs which failed to come back after resume · 42f921a6
      Viresh Kumar 提交于
      There are cases where cpufreq_add_dev() may fail for some CPUs
      during system resume. With the current code we will still have
      sysfs cpufreq files for those CPUs and struct cpufreq_policy
      would be already freed for them. Hence any operation on those
      sysfs files would result in kernel warnings.
      
      Example of problems resulting from resume errors (from Bjørn Mork):
      
      WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
      missing sysfs attribute operations for kobject: (null)
      Modules linked in: [stripped as irrelevant]
      CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
       ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
       ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
      Call Trace:
       [<ffffffff81380b0e>] dump_stack+0x55/0x76
       [<ffffffff81038635>] warn_slowpath_common+0x7c/0x96
       [<ffffffff811823c7>] ? sysfs_open_file+0x77/0x212
       [<ffffffff810386e3>] warn_slowpath_fmt+0x41/0x43
       [<ffffffff81182dec>] ? sysfs_get_active+0x6b/0x82
       [<ffffffff81182382>] ? sysfs_open_file+0x32/0x212
       [<ffffffff811823c7>] sysfs_open_file+0x77/0x212
       [<ffffffff81182350>] ? sysfs_schedule_callback+0x1ac/0x1ac
       [<ffffffff81122562>] do_dentry_open+0x17c/0x257
       [<ffffffff8112267e>] finish_open+0x41/0x4f
       [<ffffffff81130225>] do_last+0x80c/0x9ba
       [<ffffffff8112dbbd>] ? inode_permission+0x40/0x42
       [<ffffffff81130606>] path_openat+0x233/0x4a1
       [<ffffffff81130b7e>] do_filp_open+0x35/0x85
       [<ffffffff8113b787>] ? __alloc_fd+0x172/0x184
       [<ffffffff811232ea>] do_sys_open+0x6b/0xfa
       [<ffffffff811233a7>] SyS_openat+0xf/0x11
       [<ffffffff8138c812>] system_call_fastpath+0x16/0x1b
      
      To fix this, remove those sysfs files or put the associated kobject
      in case of such errors. Also, to make it simple, remove the cpufreq
      sysfs links from all the CPUs (except for the policy->cpu) during
      suspend, as that operation won't result in a loss of sysfs file
      permissions and we can create those links during resume just fine.
      
      Fixes: 5302c3fb ("cpufreq: Perform light-weight init/teardown during suspend/resume")
      Reported-and-tested-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      [rjw: Changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      42f921a6
  6. 10 12月, 2013 1 次提交
    • M
      cpufreq_ at32ap-cpufreq.c: Fix section mismatch · fa1513f6
      Matthias Brugger 提交于
      The function at32_cpufreq_driver_init was marked as __init but will be
      called from inside the cpufreq framework. This lead to the following a
      section mismatch during compilation:
      
      WARNING: drivers/built-in.o(.data+0x2448): Section mismatch in reference
      from the variable at32_driver to the function
      .init.text:at32_cpufreq_driver_init()
      The variable at32_driver references
      the function __init at32_cpufreq_driver_init()
      If the reference is valid then annotate the
      variable with __init* or __refdata (see linux/init.h) or name the
      variable:
      *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
      Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
      fa1513f6
  7. 08 12月, 2013 2 次提交
  8. 07 12月, 2013 2 次提交
  9. 03 12月, 2013 1 次提交
    • B
      cpufreq: fix garbage kobjects on errors during suspend/resume · 2167e239
      Bjørn Mork 提交于
      This is effectively a revert of commit 5302c3fb ("cpufreq: Perform
      light-weight init/teardown during suspend/resume"), which enabled
      suspend/resume optimizations leaving the sysfs files in place.
      
      Errors during suspend/resume are not handled properly, leaving
      dead sysfs attributes in case of failures.  There are are number of
      functions with special code for the "frozen" case, and all these
      need to also have special error handling.
      
      The problem is easy to demonstrate by making cpufreq_driver->init()
      or cpufreq_driver->get() fail during resume.
      
      The code is too complex for a simple fix, with split code paths
      in multiple blocks within a number of functions.  It is therefore
      best to revert the patch enabling this code until the error handling
      is in place.
      
      Examples of problems resulting from resume errors:
      
      WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
      missing sysfs attribute operations for kobject: (null)
      Modules linked in: [stripped as irrelevant]
      CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
       0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
       ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
       ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
      Call Trace:
       [<ffffffff81380b0e>] dump_stack+0x55/0x76
       [<ffffffff81038635>] warn_slowpath_common+0x7c/0x96
       [<ffffffff811823c7>] ? sysfs_open_file+0x77/0x212
       [<ffffffff810386e3>] warn_slowpath_fmt+0x41/0x43
       [<ffffffff81182dec>] ? sysfs_get_active+0x6b/0x82
       [<ffffffff81182382>] ? sysfs_open_file+0x32/0x212
       [<ffffffff811823c7>] sysfs_open_file+0x77/0x212
       [<ffffffff81182350>] ? sysfs_schedule_callback+0x1ac/0x1ac
       [<ffffffff81122562>] do_dentry_open+0x17c/0x257
       [<ffffffff8112267e>] finish_open+0x41/0x4f
       [<ffffffff81130225>] do_last+0x80c/0x9ba
       [<ffffffff8112dbbd>] ? inode_permission+0x40/0x42
       [<ffffffff81130606>] path_openat+0x233/0x4a1
       [<ffffffff81130b7e>] do_filp_open+0x35/0x85
       [<ffffffff8113b787>] ? __alloc_fd+0x172/0x184
       [<ffffffff811232ea>] do_sys_open+0x6b/0xfa
       [<ffffffff811233a7>] SyS_openat+0xf/0x11
       [<ffffffff8138c812>] system_call_fastpath+0x16/0x1b
      
      The failure to restore cpufreq devices on cancelled hibernation is
      not a new bug. It is caused by the ACPI _PPC call failing unless the
      hibernate is completed. This makes the acpi_cpufreq driver fail its
      init.
      
      Previously, the cpufreq device could be restored by offlining the
      cpu temporarily.  And as a complete hibernation cycle would do this,
      it would be automatically restored most of the time.  But after
      commit 5302c3fb the leftover sysfs attributes will block any
      device add action.  Therefore offlining and onlining CPU 1 will no
      longer restore the cpufreq object, and a complete suspend/resume
      cycle will replace it with garbage.
      
      Fixes: 5302c3fb ("cpufreq: Perform light-weight init/teardown during suspend/resume")
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2167e239
  10. 28 11月, 2013 1 次提交
  11. 21 11月, 2013 2 次提交
  12. 16 11月, 2013 1 次提交
  13. 14 11月, 2013 1 次提交
  14. 13 11月, 2013 1 次提交
  15. 08 11月, 2013 1 次提交
  16. 07 11月, 2013 1 次提交
    • A
      intel_pstate: skip the driver if ACPI has power mgmt option · fbbcdc07
      Adrian Huang 提交于
      Do not load the Intel pstate driver if the platform firmware
      (ACPI BIOS) supports the power management alternatives.
      The ACPI BIOS indicates that the OS control mode can be used
      if the _PSS (Performance Supported States) is defined in ACPI
      table. For the OS control mode, the Intel pstate driver will be
      loaded.
      
      HP BIOS has several power management modes (firmware, OS-control and
      so on). For the OS control mode in HP BIOS, the Intel p-state driver
      will be loaded. When the customer chooses the firmware power
      management in HP BIOS, the Intel p-state driver will be ignored.
      
      I put hw_vendor_info vendor_info in case other vendors (Dell, Lenovo...)
      have their firmware power management. Vendors should make sure their
      firmware power management works properly, and they can go for adding
      their vendor info to the variable.
      
      I have verified the patch on HP ProLiant servers.  The patch worked
      correctly.
      Signed-off-by: NAdrian Huang <adrianhuang0701@gmail.com>
      [rjw: Fixed up !CONFIG_ACPI build]
      [Linda Knippers: As Adrian has recently left HP, I retested the
      updated patch on an HP ProLiant server and verified that it is
      behaving correctly.  When the BIOS is configured for OS control for
      power management, the intel_pstate driver loads as expected.  When
      the BIOS is configured to provide the power management, the
      intel_pstate driver does not load and we get the pcc_cpufreq driver
      instead.]
      Signed-off-by: NLinda Knippers <linda.knippers@hp.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fbbcdc07
  17. 01 11月, 2013 1 次提交
  18. 31 10月, 2013 5 次提交
  19. 30 10月, 2013 1 次提交
  20. 26 10月, 2013 6 次提交
新手
引导
客服 返回
顶部