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. 16 12月, 2013 2 次提交
    • M
      null_blk: mem garbage on NUMA systems during init · 57053d8c
      Matias Bjorling 提交于
      For NUMA systems, initializing the blk-mq layer and using per node hctx.
      We initialize submit queues to 1, while blk-mq nr_hw_queues is
      initialized to the number of NUMA nodes.
      
      This makes the null_init_hctx function overwrite memory outside of what
      it allocated.  In my case it lead to writing garbage into struct
      request_queue's mq_map.
      Signed-off-by: NMatias Bjorling <m@bjorling.me>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57053d8c
    • S
      radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() · e4158f1b
      Sergey Senozhatsky 提交于
      Since commit ec39f64b ("drm/radeon/dpm: Convert to use
      devm_hwmon_register_with_groups") radeon_hwmon_init() is using
      hwmon_device_register_with_groups(), which sets `rdev' as a device
      private driver_data, while hwmon_attributes_visible() and
      radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
      
      Fix them by using dev_get_drvdata(), in order to avoid this oops:
      
        BUG: unable to handle kernel paging request at 0000000000001e28
        IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon]
        PGD 15057e067 PUD 151a8e067 PMD 0
        Oops: 0000 [#1] PREEMPT SMP
        Call Trace:
          internal_create_group+0x114/0x1d9
          sysfs_create_group+0xe/0x10
          sysfs_create_groups+0x22/0x5f
          device_add+0x34f/0x501
          device_register+0x15/0x18
          hwmon_device_register_with_groups+0xb5/0xed
          radeon_hwmon_init+0x56/0x7c [radeon]
          radeon_pm_init+0x134/0x7e5 [radeon]
          radeon_modeset_init+0x75f/0x8ed [radeon]
          radeon_driver_load_kms+0xc6/0x187 [radeon]
          drm_dev_register+0xf9/0x1b4 [drm]
          drm_get_pci_dev+0x98/0x129 [drm]
          radeon_pci_probe+0xa3/0xac [radeon]
          pci_device_probe+0x6e/0xcf
          driver_probe_device+0x98/0x1c4
          __driver_attach+0x5c/0x7e
          bus_for_each_dev+0x7b/0x85
          driver_attach+0x19/0x1b
          bus_add_driver+0x104/0x1ce
          driver_register+0x89/0xc5
          __pci_register_driver+0x58/0x5b
          drm_pci_init+0x86/0xea [drm]
          radeon_init+0x97/0x1000 [radeon]
          do_one_initcall+0x7f/0x117
          load_module+0x1583/0x1bb4
          SyS_init_module+0xa0/0xaf
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alexander Deucher <Alexander.Deucher@amd.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e4158f1b
  7. 15 12月, 2013 2 次提交
  8. 14 12月, 2013 2 次提交
    • J
      dm array: fix a reference counting bug in shadow_ablock · ed9571f0
      Joe Thornber 提交于
      An old array block could have its reference count decremented below
      zero when it is being replaced in the btree by a new array block.
      
      The fix is to increment the old ablock's reference count just before
      inserting a new ablock into the btree.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.9+
      ed9571f0
    • J
      dm space map: disallow decrementing a reference count below zero · 5b564d80
      Joe Thornber 提交于
      The old behaviour, returning -EINVAL if a ref_count of 0 would be
      decremented, was removed in commit f722063e ("dm space map: optimise
      sm_ll_dec and sm_ll_inc").  To fix this regression we return an error
      code from the mutator function pointer passed to sm_ll_mutate() and have
      dec_ref_count() return -EINVAL if the old ref_count is 0.
      
      Add a DMERR to reflect the potential seriousness of this error.
      
      Also, add missing dm_tm_unlock() to sm_ll_mutate()'s error path.
      
      With this fix the following dmts regression test now passes:
       dmtest run --suite cache -n /metadata_use_kernel/
      
      The next patch fixes the higher-level dm-array code that exposed this
      regression.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.12+
      5b564d80
  9. 13 12月, 2013 14 次提交
  10. 12 12月, 2013 7 次提交