1. 30 1月, 2008 1 次提交
  2. 19 10月, 2007 7 次提交
  3. 30 7月, 2007 2 次提交
    • R
      Introduce CONFIG_SUSPEND for suspend-to-Ram and standby · 296699de
      Rafael J. Wysocki 提交于
      Introduce CONFIG_SUSPEND representing the ability to enter system sleep
      states, such as the ACPI S3 state, and allow the user to choose SUSPEND
      and HIBERNATION independently of each other.
      
      Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has
      been chosen and the kernel is intended for SMP systems.
      
      Also, introduce CONFIG_PM_SLEEP which is automatically selected if
      CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the
      code needed for both suspend and hibernation.
      
      The top-level power management headers and the ACPI code related to
      suspend and hibernation are modified to use the new definitions (the
      changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce
      the number of ifdefs).
      
      There are many other files in which CONFIG_PM can be replaced with
      CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in
      the future.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      296699de
    • R
      Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION · b0cb1a19
      Rafael J. Wysocki 提交于
      Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid
      confusion (among other things, with CONFIG_SUSPEND introduced in the
      next patch).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0cb1a19
  4. 27 7月, 2007 1 次提交
  5. 20 7月, 2007 2 次提交
    • R
      PM: introduce hibernation and suspend notifiers · b10d9117
      Rafael J. Wysocki 提交于
      Make it possible to register hibernation and suspend notifiers, so that
      subsystems can perform hibernation-related or suspend-related operations that
      should not be carried out by device drivers' .suspend() and .resume()
      routines.
      
      [akpm@linux-foundation.org: build fixes]
      [akpm@linux-foundation.org: cleanups]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b10d9117
    • R
      swsusp: introduce restore platform operations · a634cc10
      Rafael J. Wysocki 提交于
      At least on some machines it is necessary to prepare the ACPI firmware for the
      restoration of the system memory state from the hibernation image if the
      "platform" mode of hibernation has been used.  Namely, in that cases we need
      to disable the GPEs before replacing the "boot" kernel with the "frozen"
      kernel (cf.  http://bugzilla.kernel.org/show_bug.cgi?id=7887).  After the
      restore they will be re-enabled by hibernation_ops->finish(), but if the
      restore fails, they have to be re-enabled by the restore code explicitly.
      
      For this purpose we can introduce two additional hibernation operations,
      called pre_restore() and restore_cleanup() and call them from the restore code
      path.  Still, they should be called if the "platform" mode of hibernation has
      been used, so we need to pass the information about the hibernation mode from
      the "frozen" kernel to the "boot" kernel in the image header.
      
      Apparently, we can't drop the disabling of GPEs before the restore because of
      Bug #7887 .   We also can't do it unconditionally, because the GPEs wouldn't
      have been enabled after a successful restore if the suspend had been done in
      the 'shutdown' or 'reboot' mode.
      
      In principle we could (and probably should) unconditionally disable the GPEs
      before each snapshot creation *and* before the restore, but then we'd have to
      unconditionally enable them after the snapshot creation as well as after the
      restore (or restore failure)   Still, for this purpose we'd need to modify
      acpi_enter_sleep_state_prep() and acpi_leave_sleep_state() and we'd have to
      introduce some mechanism synchronizing the disablind/enabling of the GPEs with
      the device drivers' .suspend()/.resume() routines and with
      disable_/enable_nonboot_cpus().   However, this would have affected the
      suspend (ie.  s2ram) code as well as the hibernation, which I'd like to avoid
      in this patch series.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a634cc10
  6. 10 5月, 2007 1 次提交
    • R
      PM: Separate hibernation code from suspend code · a3d25c27
      Rafael J. Wysocki 提交于
      [ With Johannes Berg <johannes@sipsolutions.net> ]
      
      Separate the hibernation (aka suspend to disk code) from the other suspend
      code.  In particular:
      
       * Remove the definitions related to hibernation from include/linux/pm.h
       * Introduce struct hibernation_ops and a new hibernate() function to hibernate
         the system, defined in include/linux/suspend.h
       * Separate suspend code in kernel/power/main.c from hibernation-related code
         in kernel/power/disk.c and kernel/power/user.c (with the help of
         hibernation_ops)
       * Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Greg KH <greg@kroah.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a3d25c27
  7. 09 5月, 2007 1 次提交
  8. 08 5月, 2007 4 次提交
  9. 07 5月, 2007 1 次提交
  10. 08 12月, 2006 1 次提交
    • R
      [PATCH] swsusp: Improve handling of highmem · 8357376d
      Rafael J. Wysocki 提交于
      Currently swsusp saves the contents of highmem pages by copying them to the
      normal zone which is quite inefficient (eg.  it requires two normal pages
      to be used for saving one highmem page).  This may be improved by using
      highmem for saving the contents of saveable highmem pages.
      
      Namely, during the suspend phase of the suspend-resume cycle we try to
      allocate as many free highmem pages as there are saveable highmem pages.
      If there are not enough highmem image pages to store the contents of all of
      the saveable highmem pages, some of them will be stored in the "normal"
      memory.  Next, we allocate as many free "normal" pages as needed to store
      the (remaining) image data.  We use a memory bitmap to mark the allocated
      free pages (ie.  highmem as well as "normal" image pages).
      
      Now, we use another memory bitmap to mark all of the saveable pages
      (highmem as well as "normal") and the contents of the saveable pages are
      copied into the image pages.  Then, the second bitmap is used to save the
      pfns corresponding to the saveable pages and the first one is used to save
      their data.
      
      During the resume phase the pfns of the pages that were saveable during the
      suspend are loaded from the image and used to mark the "unsafe" page
      frames.  Next, we try to allocate as many free highmem page frames as to
      load all of the image data that had been in the highmem before the suspend
      and we allocate so many free "normal" page frames that the total number of
      allocated free pages (highmem and "normal") is equal to the size of the
      image.  While doing this we have to make sure that there will be some extra
      free "normal" and "safe" page frames for two lists of PBEs constructed
      later.
      
      Now, the image data are loaded, if possible, into their "original" page
      frames.  The image data that cannot be written into their "original" page
      frames are loaded into "safe" page frames and their "original" kernel
      virtual addresses, as well as the addresses of the "safe" pages containing
      their copies, are stored in one of two lists of PBEs.
      
      One list of PBEs is for the copies of "normal" suspend pages (ie.  "normal"
      pages that were saveable during the suspend) and it is used in the same way
      as previously (ie.  by the architecture-dependent parts of swsusp).  The
      other list of PBEs is for the copies of highmem suspend pages.  The pages
      in this list are restored (in a reversible way) right before the
      arch-dependent code is called.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8357376d
  11. 26 9月, 2006 3 次提交
    • R
      [PATCH] swsusp: Use memory bitmaps during resume · 940864dd
      Rafael J. Wysocki 提交于
      Make swsusp use memory bitmaps to store its internal information during the
      resume phase of the suspend-resume cycle.
      
      If the pfns of saveable pages are saved during the suspend phase instead of
      the kernel virtual addresses of these pages, we can use them during the resume
      phase directly to set the corresponding bits in a memory bitmap.  Then, this
      bitmap is used to mark the page frames corresponding to the pages that were
      saveable before the suspend (aka "unsafe" page frames).
      
      Next, we allocate as many page frames as needed to store the entire suspend
      image and make sure that there will be some extra free "safe" page frames for
      the list of PBEs constructed later.  Subsequently, the image is loaded and, if
      possible, the data loaded from it are written into their "original" page
      frames (ie.  the ones they had occupied before the suspend).
      
      The image data that cannot be written into their "original" page frames are
      loaded into "safe" page frames and their "original" kernel virtual addresses,
      as well as the addresses of the "safe" pages containing their copies, are
      stored in a list of PBEs.  Finally, the list of PBEs is used to copy the
      remaining image data into their "original" page frames (this is done
      atomically, by the architecture-dependent parts of swsusp).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      940864dd
    • R
      [PATCH] swsusp: clean up suspend header · dcbb5a54
      Rafael J. Wysocki 提交于
      Remove some things that are no longer used or defined elsewhere from suspend.h
      and make the inline version of software_suspend() return the right error code.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dcbb5a54
    • R
      [PATCH] Disable CPU hotplug during suspend · e3920fb4
      Rafael J. Wysocki 提交于
      The current suspend code has to be run on one CPU, so we use the CPU
      hotplug to take the non-boot CPUs offline on SMP machines.  However, we
      should also make sure that these CPUs will not be enabled by someone else
      after we have disabled them.
      
      The functions disable_nonboot_cpus() and enable_nonboot_cpus() are moved to
      kernel/cpu.c, because they now refer to some stuff in there that should
      better be static.  Also it's better if disable_nonboot_cpus() returns an
      error instead of panicking if something goes wrong, and
      enable_nonboot_cpus() has no reason to panic(), because the CPUs may have
      been enabled by the userland before it tries to take them online.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e3920fb4
  12. 26 6月, 2006 1 次提交
  13. 23 6月, 2006 1 次提交
  14. 26 4月, 2006 1 次提交
  15. 08 2月, 2006 1 次提交
  16. 04 2月, 2006 1 次提交
  17. 07 1月, 2006 2 次提交
  18. 31 10月, 2005 2 次提交
  19. 28 10月, 2005 1 次提交
  20. 10 10月, 2005 1 次提交
    • R
      [PATCH] x86_64: Set up safe page tables during resume · 3dd08325
      Rafael J. Wysocki 提交于
      The following patch makes swsusp avoid the possible temporary corruption
      of page translation tables during resume on x86-64.  This is achieved by
      creating a copy of the relevant page tables that will not be modified by
      swsusp and can be safely used by it on resume.
      
      The problem is that during resume on x86-64 swsusp may temporarily
      corrupt the page tables used for the direct mapping of RAM.  If that
      happens, a page fault occurs and cannot be handled properly, which leads
      to the solid hang of the affected system.  This leads to the loss of the
      system's state from before suspend and may result in the loss of data or
      the corruption of filesystems, so it is a serious issue.  Also, it
      appears to happen quite often (for me, as often as 50% of the time).
      
      The problem is related to the fact that (at least) one of the PMD
      entries used in the direct memory mapping (starting at PAGE_OFFSET)
      points to a page table the physical address of which is much greater
      than the physical address of the PMD entry itself.  Moreover,
      unfortunately, the physical address of the page table before suspend
      (i.e.  the one stored in the suspend image) happens to be different to
      the physical address of the corresponding page table used during resume
      (i.e.  the one that is valid right before swsusp_arch_resume() in
      arch/x86_64/kernel/suspend_asm.S is executed).  Thus while the image is
      restored, the "offending" PMD entry gets overwritten, so it does not
      point to the right physical address any more (i.e.  there's no page
      table at the address pointed to by it, because it points to the address
      the page table has been at during suspend).  Consequently, if the PMD
      entry is used later on, and it _is_ used in the process of copying the
      image pages, a page fault occurs, but it cannot be handled in the normal
      way and the system hangs.
      
      In principle we can call create_resume_mapping() from
      swsusp_arch_resume() (ie.  from suspend_asm.S), but then the memory
      allocations in create_resume_mapping(), resume_pud_mapping(), and
      resume_pmd_mapping() must be made carefully so that we use _only_
      NosaveFree pages in them (the other pages are overwritten by the loop in
      swsusp_arch_resume()).  Additionally, we are in atomic context at that
      time, so we cannot use GFP_KERNEL.  Moreover, if one of the allocations
      fails, we should free all of the allocated pages, so we need to trace
      them somehow.
      
      All of this is done in the appended patch, except that the functions
      populating the page tables are located in arch/x86_64/kernel/suspend.c
      rather than in init.c.  It may be done in a more elegan way in the
      future, with the help of some swsusp patches that are in the works now.
      
      [AK: move some externs into headers, renamed a function]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3dd08325
  21. 26 6月, 2005 1 次提交
  22. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4