1. 25 9月, 2012 6 次提交
  2. 28 7月, 2012 2 次提交
  3. 26 7月, 2012 1 次提交
  4. 25 7月, 2012 2 次提交
  5. 24 7月, 2012 1 次提交
  6. 18 7月, 2012 3 次提交
  7. 17 7月, 2012 8 次提交
  8. 14 7月, 2012 7 次提交
  9. 13 7月, 2012 1 次提交
    • T
      cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression · c4686c71
      Thomas Renninger 提交于
      Commit d640113f introduced a regression on SMP
      systems where the processor core with ACPI id zero is disabled
      (typically should be the case because of hyperthreading).
      The regression got spread through stable kernels.
      On 3.0.X it got introduced via 3.0.18.
      
      Such platforms may be rare, but do exist.
      Look out for a disabled processor with acpi_id 0 in dmesg:
      ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled)
      
      This problem has been observed on a:
      HP Proliant BL280c G6 blade
      
      This patch restricts the introduced workaround to platforms
      with nr_cpu_ids <= 1.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      c4686c71
  10. 11 7月, 2012 2 次提交
    • J
      ACPI / PM: Leave Bus Master Arbitration enabled for suspend/resume · dc332fdf
      Jonathan Nieder 提交于
      This is an old suspend/resume lockup fix:
      
      	commit 2780cc4660e1
      	Author: Len Brown <len.brown@intel.com>
      	Date:   Thu Dec 23 13:43:30 2004 -0500
      
      	    [ACPI] Fix suspend/resume lockup issue
      	    by leaving Bus Master Arbitration enabled.
      	    The ACPI spec mandates it be disabled only for C3.
      
      	    http://bugzilla.kernel.org/show_bug.cgi?id=3599Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      
      The bug snuck back in in commit 2feec47d (ACPICA: ACPI 5: Support
      for new FADT SleepStatus, SleepControl registers, 2012-02-14),
      presumably by copy/pasting a copy of the code without that fix for the
      legacy case.
      
      On affected machines, after that commit, the machine locks up hard on
      resume from suspend.  The same fix as seven years ago still works.
      
      Addresses <https://bugzilla.kernel.org/show_bug.cgi?id=43641>.
      Reported-bisected-and-tested-by: NOctavio Alvarez <alvarezp@alvarezp.com>
      Reported-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
      Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      dc332fdf
    • P
      PM / cpuidle: System resume hang fix with cpuidle · 8651f97b
      Preeti U Murthy 提交于
      On certain bios, resume hangs if cpus are allowed to enter idle states
      during suspend [1].
      
      This was fixed in apci idle driver [2].But intel_idle driver does not
      have this fix. Thus instead of replicating the fix in both the idle
      drivers, or in more platform specific idle drivers if needed, the
      more general cpuidle infrastructure could handle this.
      
      A suspend callback in cpuidle_driver could handle this fix. But
      a cpuidle_driver provides only basic functionalities like platform idle
      state detection capability and mechanisms to support entry and exit
      into CPU idle states. All other cpuidle functions are found in the
      cpuidle generic infrastructure for good reason that all cpuidle
      drivers, irrepective of their platforms will support these functions.
      
      One option therefore would be to register a suspend callback in cpuidle
      which handles this fix. This could be called through a PM_SUSPEND_PREPARE
      notifier. But this is too generic a notfier for a driver to handle.
      
      Also, ideally the job of cpuidle is not to handle side effects of suspend.
      It should expose the interfaces which "handle cpuidle 'during' suspend"
      or any other operation, which the subsystems call during that respective
      operation.
      
      The fix demands that during suspend, no cpus should be allowed to enter
      deep C-states. The interface cpuidle_uninstall_idle_handler() in cpuidle
      ensures that. Not just that it also kicks all the cpus which are already
      in idle out of their idle states which was being done during cpu hotplug
      through a CPU_DYING_FROZEN callbacks.
      
      Now the question arises about when during suspend should
      cpuidle_uninstall_idle_handler() be called. Since we are dealing with
      drivers it seems best to call this function during dpm_suspend().
      Delaying the call till dpm_suspend_noirq() does no harm, as long as it is
      before cpu_hotplug_begin() to avoid race conditions with cpu hotpulg
      operations. In dpm_suspend_noirq(), it would be wise to place this call
      before suspend_device_irqs() to avoid ugly interactions with the same.
      
      Ananlogously, during resume.
      
      References:
      [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674075.
      [2] http://marc.info/?l=linux-pm&m=133958534231884&w=2Reported-and-tested-by: NDave Hansen <dave@linux.vnet.ibm.com>
      Signed-off-by: NPreeti U Murthy <preeti@linux.vnet.ibm.com>
      Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8651f97b
  11. 06 7月, 2012 1 次提交
  12. 01 7月, 2012 6 次提交