1. 27 2月, 2017 2 次提交
  2. 08 2月, 2017 1 次提交
  3. 13 9月, 2016 1 次提交
  4. 13 8月, 2016 1 次提交
  5. 22 7月, 2016 1 次提交
    • C
      PM / hibernate: Introduce test_resume mode for hibernation · fe12c00d
      Chen Yu 提交于
      test_resume mode is to verify if the snapshot data
      written to swap device can be successfully restored
      to memory. It is useful to ease the debugging process
      on hibernation, since this mode can not only bypass
      the BIOSes/bootloader, but also the system re-initialization.
      
      To avoid the risk to break the filesystm on persistent storage,
      this patch resumes the image with tasks frozen.
      
      For example:
      echo test_resume > /sys/power/disk
      echo disk > /sys/power/state
      
      [  187.306470] PM: Image saving progress:  70%
      [  187.395298] PM: Image saving progress:  80%
      [  187.476697] PM: Image saving progress:  90%
      [  187.554641] PM: Image saving done.
      [  187.558896] PM: Wrote 594600 kbytes in 0.90 seconds (660.66 MB/s)
      [  187.566000] PM: S|
      [  187.589742] PM: Basic memory bitmaps freed
      [  187.594694] PM: Checking hibernation image
      [  187.599865] PM: Image signature found, resuming
      [  187.605209] PM: Loading hibernation image.
      [  187.665753] PM: Basic memory bitmaps created
      [  187.691397] PM: Using 3 thread(s) for decompression.
      [  187.691397] PM: Loading and decompressing image data (148650 pages)...
      [  187.889719] PM: Image loading progress:   0%
      [  188.100452] PM: Image loading progress:  10%
      [  188.244781] PM: Image loading progress:  20%
      [  189.057305] PM: Image loading done.
      [  189.068793] PM: Image successfully loaded
      Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NChen Yu <yu.c.chen@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe12c00d
  6. 16 7月, 2016 1 次提交
    • R
      x86 / hibernate: Use hlt_play_dead() when resuming from hibernation · 406f992e
      Rafael J. Wysocki 提交于
      On Intel hardware, native_play_dead() uses mwait_play_dead() by
      default and only falls back to the other methods if that fails.
      That also happens during resume from hibernation, when the restore
      (boot) kernel runs disable_nonboot_cpus() to take all of the CPUs
      except for the boot one offline.
      
      However, that is problematic, because the address passed to
      __monitor() in mwait_play_dead() is likely to be written to in the
      last phase of hibernate image restoration and that causes the "dead"
      CPU to start executing instructions again.  Unfortunately, the page
      containing the address in that CPU's instruction pointer may not be
      valid any more at that point.
      
      First, that page may have been overwritten with image kernel memory
      contents already, so the instructions the CPU attempts to execute may
      simply be invalid.  Second, the page tables previously used by that
      CPU may have been overwritten by image kernel memory contents, so the
      address in its instruction pointer is impossible to resolve then.
      
      A report from Varun Koyyalagunta and investigation carried out by
      Chen Yu show that the latter sometimes happens in practice.
      
      To prevent it from happening, temporarily change the smp_ops.play_dead
      pointer during resume from hibernation so that it points to a special
      "play dead" routine which uses hlt_play_dead() and avoids the
      inadvertent "revivals" of "dead" CPUs this way.
      
      A slightly unpleasant consequence of this change is that if the
      system is hibernated with one or more CPUs offline, it will generally
      draw more power after resume than it did before hibernation, because
      the physical state entered by CPUs via hlt_play_dead() is higher-power
      than the mwait_play_dead() one in the majority of cases.  It is
      possible to work around this, but it is unclear how much of a problem
      that's going to be in practice, so the workaround will be implemented
      later if it turns out to be necessary.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=106371Reported-by: NVarun Koyyalagunta <cpudebug@centtech.com>
      Original-by: NChen Yu <yu.c.chen@intel.com>
      Tested-by: NChen Yu <yu.c.chen@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      406f992e
  7. 10 7月, 2016 2 次提交
  8. 28 6月, 2016 1 次提交
  9. 26 6月, 2016 1 次提交
    • K
      x86/KASLR, x86/power: Remove x86 hibernation restrictions · 65fe935d
      Kees Cook 提交于
      With the following fix:
      
        70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code passes control to the image kernel")
      
      ... there is no longer a problem with hibernation resuming a
      KASLR-booted kernel image, so remove the restriction.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux PM list <linux-pm@vger.kernel.org>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160613221002.GA29719@www.outflux.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      65fe935d
  10. 23 3月, 2016 1 次提交
    • L
      PM / sleep: Clear pm_suspend_global_flags upon hibernate · 27614273
      Lukas Wunner 提交于
      When suspending to RAM, waking up and later suspending to disk,
      we gratuitously runtime resume devices after the thaw phase.
      This does not occur if we always suspend to RAM or always to disk.
      
      pm_complete_with_resume_check(), which gets called from
      pci_pm_complete() among others, schedules a runtime resume
      if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during
      a suspend-to-RAM cycle. It is cleared at the beginning of
      the suspend-to-RAM cycle but not afterwards and it is not
      cleared during a suspend-to-disk cycle at all. Fix it.
      
      Fixes: ef25ba04 (PM / sleep: Add flags to indicate platform firmware involvement)
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Cc: 4.4+ <stable@vger.kernel.org> # 4.4+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      27614273
  11. 16 3月, 2016 1 次提交
  12. 14 10月, 2015 1 次提交
  13. 25 6月, 2015 1 次提交
  14. 03 11月, 2014 1 次提交
  15. 28 10月, 2014 1 次提交
  16. 17 7月, 2014 1 次提交
  17. 17 6月, 2014 2 次提交
  18. 07 6月, 2014 1 次提交
    • T
      PM / sleep: trace events for suspend/resume · bb3632c6
      Todd E Brandt 提交于
      Adds trace events that give finer resolution into suspend/resume. These
      events are graphed in the timelines generated by the analyze_suspend.py
      script. They represent large areas of time consumed that are typical to
      suspend and resume.
      
      The event is triggered by calling the function "trace_suspend_resume"
      with three arguments: a string (the name of the event to be displayed
      in the timeline), an integer (case specific number, such as the power
      state or cpu number), and a boolean (where true is used to denote the start
      of the timeline event, and false to denote the end).
      
      The suspend_resume trace event reproduces the data that the machine_suspend
      trace event did, so the latter has been removed.
      Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bb3632c6
  19. 17 5月, 2014 1 次提交
  20. 10 5月, 2014 1 次提交
  21. 01 5月, 2014 1 次提交
  22. 28 4月, 2014 1 次提交
  23. 01 3月, 2014 1 次提交
  24. 06 1月, 2014 1 次提交
    • B
      PM / hibernate: Call platform_leave() in suspend path too · 362e77d1
      Bjørn Mork 提交于
      Since create_image() only executes platform_leave() if in_suspend is
      not set, enable_nonboot_cpus() is run by it with EC transactions
      blocked (on ACPI systems) in the image creation code path (that is,
      for in_suspend set), which may cause CPU online to fail for the CPUs
      in question.  In particular, this causes the acpi_cpufreq driver's
      initialization to fail for those CPUs on some systems with the
      following dmesg:
      
       cpufreq: adding CPU 1
       acpi_cpufreq_cpu_init
       cpufreq: FREQ: 1401000 - CPU: 0
       ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20130725/evregion-287)
       ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPC_.EC__.LPMD] (Node ffff88023249ab28), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Error: Method parse/execution failed [\_PR_.CPU0._PPC] (Node ffff88023270e3f8), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Error: Method parse/execution failed [\_PR_.CPU1._PPC] (Node ffff88023270e290), AE_BAD_PARAMETER (20130725/psparse-536)
       ACPI Exception: AE_BAD_PARAMETER, Evaluating _PPC (20130725/processor_perflib-140)
       cpufreq: initialization failed
       CPU1 is up
      
      To fix this problem, modify create_image() to execute platform_leave()
      unconditionally.  [rjw: This shouldn't lead to any significant side
      effects on ACPI systems.]
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      [rjw: Changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      362e77d1
  25. 30 11月, 2013 1 次提交
  26. 25 10月, 2013 1 次提交
  27. 31 8月, 2013 2 次提交
    • R
      PM / hibernate / memory hotplug: Rework mutual exclusion · 942f4015
      Rafael J. Wysocki 提交于
      Since all of the memory hotplug operations have to be carried out
      under device_hotplug_lock, they won't need to acquire pm_mutex if
      device_hotplug_lock is held around hibernation.
      
      For this reason, make the hibernation code acquire
      device_hotplug_lock after freezing user space processes and
      release it before thawing them.  At the same tim drop the
      lock_system_sleep() and unlock_system_sleep() calls from
      lock_memory_hotplug() and unlock_memory_hotplug(), respectively.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      942f4015
    • R
      PM / hibernate: Create memory bitmaps after freezing user space · 8fd37a4c
      Rafael J. Wysocki 提交于
      The hibernation core uses special memory bitmaps during image
      creation and restoration and traditionally those bitmaps are
      allocated before freezing tasks, because in the past GFP_KERNEL
      allocations might not work after all tasks had been frozen.
      
      However, this is an anachronism, because hibernation_snapshot()
      now calls hibernate_preallocate_memory() which allocates memory
      for the image upfront anyway, so the memory bitmaps may be
      allocated after freezing user space safely.
      
      For this reason, move all of the create_basic_memory_bitmaps()
      calls after freeze_processes() and all of the corresponding
      free_basic_memory_bitmaps() calls before thaw_processes().
      
      This will allow us to hold device_hotplug_lock around hibernation
      without the need to worry about freezing issues with user space
      processes attempting to acquire it via sysfs attributes after the
      creation of memory bitmaps and before the freezing of tasks.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      8fd37a4c
  28. 07 8月, 2013 1 次提交
  29. 19 7月, 2012 1 次提交
    • L
      Make wait_for_device_probe() also do scsi_complete_async_scans() · eea03c20
      Linus Torvalds 提交于
      Commit a7a20d10 ("sd: limit the scope of the async probe domain")
      make the SCSI device probing run device discovery in it's own async
      domain.
      
      However, as a result, the partition detection was no longer synchronized
      by async_synchronize_full() (which, despite the name, only synchronizes
      the global async space, not all of them).  Which in turn meant that
      "wait_for_device_probe()" would not wait for the SCSI partitions to be
      parsed.
      
      And "wait_for_device_probe()" was what the boot time init code relied on
      for mounting the root filesystem.
      
      Now, most people never noticed this, because not only is it
      timing-dependent, but modern distributions all use initrd.  So the root
      filesystem isn't actually on a disk at all.  And then before they
      actually mount the final disk filesystem, they will have loaded the
      scsi-wait-scan module, which not only does the expected
      wait_for_device_probe(), but also does scsi_complete_async_scans().
      
      [ Side note: scsi_complete_async_scans() had also been partially broken,
        but that was fixed in commit 43a8d39d ("fix async probe
        regression"), so that same commit a7a20d10 had actually broken
        setups even if you used scsi-wait-scan explicitly ]
      
      Solve this problem by just moving the scsi_complete_async_scans() call
      into wait_for_device_probe().  Everybody who wants to wait for device
      probing to finish really wants the SCSI probing to complete, so there's
      no reason not to do this.
      
      So now "wait_for_device_probe()" really does what the name implies, and
      properly waits for device probing to finish.  This also removes the now
      unnecessary extra calls to scsi_complete_async_scans().
      Reported-and-tested-by: NArtem S. Tashkinov <t.artem@mailcity.com>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <jbottomley@parallels.com>
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: linux-scsi <linux-scsi@vger.kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eea03c20
  30. 01 7月, 2012 2 次提交
  31. 19 5月, 2012 1 次提交
  32. 29 3月, 2012 2 次提交
  33. 05 3月, 2012 1 次提交
  34. 10 2月, 2012 1 次提交