1. 01 10月, 2014 1 次提交
  2. 25 9月, 2014 1 次提交
    • R
      Revert "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()" · 5c4dd348
      Rafael J. Wysocki 提交于
      Revert commit 6efde38f (PM / Hibernate: Iterate over set bits
      instead of PFNs in swsusp_free()) that introduced a NULL pointer
      dereference during system resume from hibernation:
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
      PGD b39c2067 PUD b39c1067 PMD 0
      Oops: 0000 [#1] SMP
      Modules linked in: <irrelevant list of modules>
      CPU: 1 PID: 4898 Comm: s2disk Tainted: G         C     3.17-rc5-amd64 #1 Debian 3.17~rc5-1~exp1
      Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
      task: ffff88023155ea40 ti: ffff8800b3b14000 task.ti: ffff8800b3b14000
      RIP: 0010:[<ffffffff810a8cc1>]  [<ffffffff810a8cc1>]
      swsusp_free+0x21/0x190
      RSP: 0018:ffff8800b3b17ea8  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8800b39bab00 RCX: 0000000000000001
      RDX: ffff8800b39bab10 RSI: ffff8800b39bab00 RDI: 0000000000000000
      RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
      R10: ffff8800b39bab10 R11: 0000000000000246 R12: ffffea0000000000
      R13: ffff880232f485a0 R14: ffff88023ac27cd8 R15: ffff880232927590
      FS:  00007f406d83b700(0000) GS:ffff88023bc80000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000000 CR3: 00000000b3a62000 CR4: 00000000000007e0
      Stack:
       ffff8800b39bab00 0000000000000010 ffff880232927590 ffffffff810acb4a
       ffff8800b39bab00 ffffffff811a955a ffff8800b39bab10 0000000000000000
       ffff88023155f098 ffffffff81a6b8c0 ffff88023155ea40 0000000000000007
      Call Trace:
       [<ffffffff810acb4a>] ? snapshot_release+0x2a/0xb0
       [<ffffffff811a955a>] ? __fput+0xca/0x1d0
       [<ffffffff81080627>] ? task_work_run+0x97/0xd0
       [<ffffffff81012d89>] ? do_notify_resume+0x69/0xa0
       [<ffffffff8151452a>] ? int_signal+0x12/0x17
      Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 41 54 48 8b 05 ba 62 9c 00 49 bc 00 00 00 00 00 ea ff ff 48 8b 3d a1 62 9c 00 55 53 <48> 8b 10 48 89 50 18 48 8b 52 20 48 c7 40 28 00 00 00 00 c7 40
      RIP  [<ffffffff810a8cc1>] swsusp_free+0x21/0x190
       RSP <ffff8800b3b17ea8>
      CR2: 0000000000000000
      ---[ end trace f02be86a1ec0cccb ]---
      
      due to forbidden_pages_map being NULL in swsusp_free().
      
      Fixes: 6efde38f "PM / Hibernate: Iterate over set bits instead of PFNs in swsusp_free()"
      Reported-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5c4dd348
  3. 22 9月, 2014 1 次提交
  4. 09 9月, 2014 2 次提交
  5. 03 9月, 2014 1 次提交
  6. 01 9月, 2014 1 次提交
  7. 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
  8. 29 7月, 2014 6 次提交
  9. 23 7月, 2014 3 次提交
  10. 21 7月, 2014 1 次提交
  11. 17 7月, 2014 1 次提交
  12. 15 7月, 2014 2 次提交
  13. 17 6月, 2014 2 次提交
  14. 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
  15. 01 6月, 2014 1 次提交
  16. 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
  17. 20 5月, 2014 1 次提交
  18. 17 5月, 2014 1 次提交
  19. 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
  20. 10 5月, 2014 1 次提交
  21. 07 5月, 2014 1 次提交
  22. 06 5月, 2014 1 次提交
  23. 01 5月, 2014 1 次提交
  24. 28 4月, 2014 1 次提交
  25. 22 4月, 2014 1 次提交
  26. 08 4月, 2014 1 次提交
  27. 12 3月, 2014 2 次提交