1. 09 9月, 2014 2 次提交
  2. 03 9月, 2014 1 次提交
  3. 07 8月, 2014 1 次提交
    • L
      PM / hibernate: avoid unsafe pages in e820 reserved regions · 84c91b7a
      Lee, Chun-Yi 提交于
      When the machine doesn't well handle the e820 persistent when hibernate
      resuming, then it may cause page fault when writing image to snapshot
      buffer:
      
      [   17.929495] BUG: unable to handle kernel paging request at ffff880069d4f000
      [   17.933469] IP: [<ffffffff810a1cf0>] load_image_lzo+0x810/0xe40
      [   17.933469] PGD 2194067 PUD 77ffff067 PMD 2197067 PTE 0
      [   17.933469] Oops: 0002 [#1] SMP
      ...
      
      The ffff880069d4f000 page is in e820 reserved region of resume boot
      kernel:
      
      [    0.000000] BIOS-e820: [mem 0x0000000069d4f000-0x0000000069e12fff] reserved
      ...
      [    0.000000] PM: Registered nosave memory: [mem 0x69d4f000-0x69e12fff]
      
      So snapshot.c mark the pfn to forbidden pages map. But, this
      page is also in the memory bitmap in snapshot image because it's an
      original page used by image kernel, so it will also mark as an
      unsafe(free) page in prepare_image().
      
      That means the page in e820 when resuming mark as "forbidden" and
      "free", it causes get_buffer() treat it as an allocated unsafe page.
      Then snapshot_write_next() return this page to load_image, load_image
      writing content to this address, but this page didn't really allocated
      . So, we got page fault.
      
      Although the root cause is from BIOS, I think aggressive check and
      significant message in kernel will better then a page fault for
      issue tracking, especially when serial console unavailable.
      
      This patch adds code in mark_unsafe_pages() for check does free pages in
      nosave region. If so, then it print message and return fault to stop whole
      S4 resume process:
      
      [    8.166004] PM: Image loading progress:   0%
      [    8.658717] PM: 0x6796c000 in e820 nosave region: [mem 0x6796c000-0x6796cfff]
      [    8.918737] PM: Read 2511940 kbytes in 1.04 seconds (2415.32 MB/s)
      [    8.926633] PM: Error -14 resuming
      [    8.933534] PM: Failed to load hibernation image, recovering.
      Reviewed-by: NTakashi Iwai <tiwai@suse.de>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      [rjw: Subject]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      84c91b7a
  4. 29 7月, 2014 6 次提交
  5. 23 7月, 2014 3 次提交
  6. 21 7月, 2014 1 次提交
  7. 17 7月, 2014 1 次提交
  8. 15 7月, 2014 2 次提交
  9. 17 6月, 2014 2 次提交
  10. 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
  11. 01 6月, 2014 1 次提交
  12. 26 5月, 2014 3 次提交
    • R
      PM / sleep: Introduce command line argument for sleep state enumeration · 0399d4db
      Rafael J. Wysocki 提交于
      On some systems the platform doesn't support neither
      PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
      only available system sleep state.  However, some user space frameworks
      only use the "mem" and (sometimes) "standby" sleep state labels, so
      the users of those systems need to modify user space in order to be
      able to use system suspend at all and that is not always possible.
      
      For this reason, add a new kernel command line argument,
      relative_sleep_states, allowing the users of those systems to change
      the way in which the kernel assigns labels to system sleep states.
      Namely, for relative_sleep_states=1, the "mem", "standby" and "freeze"
      labels will enumerate the available system sleem states from the
      deepest to the shallowest, respectively, so that "mem" is always
      present in /sys/power/state and the other state strings may or may
      not be presend depending on what is supported by the platform.
      
      Update system sleep states documentation to reflect this change.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0399d4db
    • R
      PM / sleep: Use valid_state() for platform-dependent sleep states only · 43e8317b
      Rafael J. Wysocki 提交于
      Use the observation that, for platform-dependent sleep states
      (PM_SUSPEND_STANDBY, PM_SUSPEND_MEM), a given state is either
      always supported or always unsupported and store that information
      in pm_states[] instead of calling valid_state() every time we
      need to check it.
      
      Also do not use valid_state() for PM_SUSPEND_FREEZE, which is always
      valid, and move the pm_test_level validity check for PM_SUSPEND_FREEZE
      directly into enter_state().
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      43e8317b
    • R
      PM / sleep: Add state field to pm_states[] entries · 27ddcc65
      Rafael J. Wysocki 提交于
      To allow sleep states corresponding to the "mem", "standby" and
      "freeze" lables to be different from the pm_states[] indexes of
      those strings, introduce struct pm_sleep_state, consisting of
      a string label and a state number, and turn pm_states[] into an
      array of objects of that type.
      
      This modification should not lead to any functional changes.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      27ddcc65
  13. 20 5月, 2014 1 次提交
  14. 17 5月, 2014 1 次提交
  15. 16 5月, 2014 1 次提交
    • R
      ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state · 1f0b6386
      Rafael J. Wysocki 提交于
      The "freeze" sleep state suffers from the same issue that was
      addressed by commit ad07277e (ACPI / PM: Hold acpi_scan_lock over
      system PM transitions) for ACPI sleep states, that is, things break
      if ->remove() is called for devices whose system resume callbacks
      haven't been executed yet.
      
      It also can be addressed in the same way, by holding the ACPI scan
      lock over the "freeze" sleep state and PM transitions to and from
      that state, but ->begin() and ->end() platform operations for the
      "freeze" sleep state are needed for this purpose.
      
      This change has been tested on Acer Aspire S5 with Thunderbolt.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1f0b6386
  16. 10 5月, 2014 1 次提交
  17. 07 5月, 2014 1 次提交
  18. 06 5月, 2014 1 次提交
  19. 01 5月, 2014 1 次提交
  20. 28 4月, 2014 1 次提交
  21. 22 4月, 2014 1 次提交
  22. 08 4月, 2014 1 次提交
  23. 12 3月, 2014 2 次提交
  24. 11 3月, 2014 1 次提交
  25. 01 3月, 2014 3 次提交