1. 07 6月, 2013 3 次提交
  2. 05 6月, 2013 5 次提交
    • G
      cpufreq: cpufreq-cpu0: use the exact frequency for clk_set_rate() · 0ca68436
      Guennadi Liakhovetski 提交于
      clk_set_rate() isn't supposed to accept approximate frequencies, instead
      a supported frequency should be obtained from clk_round_rate() and then
      used to set the clock.
      Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0ca68436
    • M
      cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work() · 2f7021a8
      Michael Wang 提交于
      Jiri Kosina <jkosina@suse.cz> and Borislav Petkov <bp@alien8.de>
      reported the warning:
      
      [   51.616759] ------------[ cut here ]------------
      [   51.621460] WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule+0x58/0x60()
      [   51.629638] Modules linked in: ext2 vfat fat loop snd_hda_codec_hdmi usbhid snd_hda_codec_realtek coretemp kvm_intel kvm snd_hda_intel snd_hda_codec crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hwdep snd_pcm aesni_intel sb_edac aes_x86_64 ehci_pci snd_page_alloc glue_helper snd_timer xhci_hcd snd iTCO_wdt iTCO_vendor_support ehci_hcd edac_core lpc_ich acpi_cpufreq lrw gf128mul ablk_helper cryptd mperf usbcore usb_common soundcore mfd_core dcdbas evdev pcspkr processor i2c_i801 button microcode
      [   51.675581] CPU: 0 PID: 244 Comm: kworker/1:1 Tainted: G        W    3.10.0-rc1+ #10
      [   51.683407] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A08 01/24/2013
      [   51.690901] Workqueue: events od_dbs_timer
      [   51.695069]  0000000000000009 ffff88043a2f5b68 ffffffff8161441c ffff88043a2f5ba8
      [   51.702602]  ffffffff8103e540 0000000000000033 0000000000000001 ffff88043d5f8000
      [   51.710136]  00000000ffff0ce1 0000000000000001 ffff88044fc4fc08 ffff88043a2f5bb8
      [   51.717691] Call Trace:
      [   51.720191]  [<ffffffff8161441c>] dump_stack+0x19/0x1b
      [   51.725396]  [<ffffffff8103e540>] warn_slowpath_common+0x70/0xa0
      [   51.731473]  [<ffffffff8103e58a>] warn_slowpath_null+0x1a/0x20
      [   51.737378]  [<ffffffff81025628>] native_smp_send_reschedule+0x58/0x60
      [   51.744013]  [<ffffffff81072cfd>] wake_up_nohz_cpu+0x2d/0xa0
      [   51.749745]  [<ffffffff8104f6bf>] add_timer_on+0x8f/0x110
      [   51.755214]  [<ffffffff8105f6fe>] __queue_delayed_work+0x16e/0x1a0
      [   51.761470]  [<ffffffff8105f251>] ? try_to_grab_pending+0xd1/0x1a0
      [   51.767724]  [<ffffffff8105f78a>] mod_delayed_work_on+0x5a/0xa0
      [   51.773719]  [<ffffffff814f6b5d>] gov_queue_work+0x4d/0xc0
      [   51.779271]  [<ffffffff814f60cb>] od_dbs_timer+0xcb/0x170
      [   51.784734]  [<ffffffff8105e75d>] process_one_work+0x1fd/0x540
      [   51.790634]  [<ffffffff8105e6f2>] ? process_one_work+0x192/0x540
      [   51.796711]  [<ffffffff8105ef22>] worker_thread+0x122/0x380
      [   51.802350]  [<ffffffff8105ee00>] ? rescuer_thread+0x320/0x320
      [   51.808264]  [<ffffffff8106634a>] kthread+0xea/0xf0
      [   51.813200]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
      [   51.819644]  [<ffffffff81623d5c>] ret_from_fork+0x7c/0xb0
      [   51.918165] nouveau E[     DRM] GPU lockup - switching to software fbcon
      [   51.930505]  [<ffffffff81066260>] ? flush_kthread_worker+0x150/0x150
      [   51.936994] ---[ end trace f419538ada83b5c5 ]---
      
      It was caused by the policy->cpus changed during the process of
      __gov_queue_work(), in other word, cpu offline happened.
      
      Use get/put_online_cpus() to prevent the offline from happening while
      __gov_queue_work() is running.
      
      [rjw: The problem has been present since recent commit 031299b3
      (cpufreq: governors: Avoid unnecessary per cpu timer interrupts)]
      
      References: https://lkml.org/lkml/2013/6/5/88Reported-by: NBorislav Petkov <bp@alien8.de>
      Reported-and-tested-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NMichael Wang <wangyun@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f7021a8
    • A
      ACPI / scan: do not match drivers against objects having scan handlers · 9f29ab11
      Aaron Lu 提交于
      With the introduction of ACPI scan handlers, an ACPI device object
      with an ACPI scan handler attached to it must not be bound to an ACPI
      driver any more.  Therefore it doesn't make sense to match those
      ACPI device objects against a newly registered ACPI driver in
      acpi_bus_match(), so make that function return 0 if the device
      object passed to it has an ACPI scan handler attached.
      
      This also addresses a regression related to a broken ACPI table in
      the BIOS, where it has defined a _ROM method under the PCI root
      bridge object.  This causes the video module to treat that object
      as a display controller device (since only display devices are
      supposed to have a _ROM method defined according to the ACPI spec).
      As a result, the ACPI video driver binds to the PCI root bridge
      object and overwrites the previously assigned driver_data field of
      it, causing subsequent calls to acpi_get_pci_dev() to fail.
      
      [rjw: Subject and changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=58091Reported-by: NJason Cassell <bluesloth600@gmail.com>
      Reported-and-bisected-by: NDmitry S. Demin <dmitryy.demin@gmail.com>
      Cc: 3.9+ <stable@kernel.org>
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9f29ab11
    • W
      ACPI / APEI: fix error return code in ghes_probe() · a98d4f64
      Wei Yongjun 提交于
      Fix to return a negative error code in the acpi_gsi_to_irq() and
      request_irq() error handling case instead of 0, as done elsewhere
      in this function.
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a98d4f64
    • R
      acpi-cpufreq: set current frequency based on target P-State · 8673b83b
      Ross Lagerwall 提交于
      Commit 4b31e774 (Always set P-state on initialization) fixed bug
      #4634 and caused the driver to always set the target P-State at
      least once since the initial P-State may not be the desired one.
      Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target()
      routine if target_freq == policy->cur) caused a regression in
      this behavior.
      
      This fixes the regression by setting policy->cur based on the CPU's
      target frequency rather than the CPU's current reported frequency
      (which may be different).  This means that the P-State will be set
      initially if the CPU's target frequency is different from the
      governor's target frequency.
      
      This fixes an issue where setting the default governor to
      performance wouldn't correctly enable turbo mode on all cores.
      Signed-off-by: NRoss Lagerwall <rosslagerwall@gmail.com>
      Reviewed-by: NLen Brown <len.brown@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 3.8+ <stable@vger.kernel.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8673b83b
  3. 02 6月, 2013 5 次提交
  4. 01 6月, 2013 27 次提交