1. 07 1月, 2014 1 次提交
  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. 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
  4. 31 10月, 2013 1 次提交
  5. 26 10月, 2013 2 次提交
  6. 22 10月, 2013 2 次提交
  7. 17 10月, 2013 1 次提交
  8. 16 10月, 2013 2 次提交
  9. 02 10月, 2013 1 次提交
  10. 11 9月, 2013 1 次提交
  11. 10 8月, 2013 1 次提交
  12. 23 7月, 2013 1 次提交
  13. 15 7月, 2013 1 次提交
    • P
      cpufreq: delete __cpuinit usage from all cpufreq files · 2760984f
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      This removes all the drivers/cpufreq uses of the __cpuinit macros
      from all C files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [v2: leave 2nd lines of args misaligned as requested by Viresh]
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: cpufreq@vger.kernel.org
      Cc: linux-pm@vger.kernel.org
      Acked-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      2760984f
  14. 22 5月, 2013 1 次提交
  15. 14 5月, 2013 1 次提交
  16. 12 5月, 2013 5 次提交
  17. 10 4月, 2013 1 次提交
  18. 09 4月, 2013 1 次提交
  19. 25 3月, 2013 3 次提交
  20. 07 3月, 2013 2 次提交
  21. 16 2月, 2013 1 次提交
  22. 12 2月, 2013 1 次提交
  23. 09 2月, 2013 1 次提交
    • D
      cpufreq/x86: Add P-state driver for sandy bridge. · 93f0822d
      Dirk Brandewie 提交于
      Add a P-state driver for the Intel Sandy bridge processor. In cpufreq
      terminology this driver implements a  scaling driver with an internal
      governor.
      
      When built into the the kernel this driver will be the preferred
      scaling driver for Sandy bridge processors.
      
      In addition to the interfaces provided by the cpufreq subsystem for
      controlling scaling drivers. The user may control the behavior of the
      driver via three sysfs files located in
      "/sys/devices/system/cpu/intel_pstate".
      
        max_perf_pct: limits the maximum P state that will be requested by
        the driver stated as a percentage of the avail performance.
      
        min_perf_pct: limits the minimum P state that will be  requested by
        the driver stated as a percentage of the avail performance.
      
        no_turbo: limits the driver to selecting P states below the turbo
        frequency range.
      Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      93f0822d