1. 09 5月, 2012 2 次提交
  2. 24 4月, 2012 1 次提交
  3. 07 7月, 2011 1 次提交
    • K
      x86, suspend: Restore MISC_ENABLE MSR in realmode wakeup · 7a313666
      Kees Cook 提交于
      Some BIOSes will reset the Intel MISC_ENABLE MSR (specifically the
      XD_DISABLE bit) when resuming from S3, which can interact poorly with
      ebba638a. In 32bit PAE mode, this can
      lead to a fault when EFER is restored by the kernel wakeup routines,
      due to it setting the NX bit for a CPU that (thanks to the BIOS reset)
      now incorrectly thinks it lacks the NX feature. (64bit is not affected
      because it uses a common CPU bring-up that specifically handles the
      XD_DISABLE bit.)
      
      The need for MISC_ENABLE being restored so early is specific to the S3
      resume path. Normally, MISC_ENABLE is saved in save_processor_state(),
      but this happens after the resume header is created, so just reproduce
      the logic here. (acpi_suspend_lowlevel() creates the header, calls
      do_suspend_lowlevel, which calls save_processor_state(), so the saved
      processor context isn't available during resume header creation.)
      
      [ hpa: Consider for stable if OK in mainline ]
      Signed-off-by: NKees Cook <kees.cook@canonical.com>
      Link: http://lkml.kernel.org/r/20110707011034.GA8523@outflux.netSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@kernel.org> 2.6.38+
      7a313666
  4. 18 5月, 2011 1 次提交
  5. 25 2月, 2011 2 次提交
  6. 18 2月, 2011 1 次提交
  7. 07 2月, 2011 1 次提交
  8. 05 2月, 2011 1 次提交
  9. 26 10月, 2010 2 次提交
  10. 21 10月, 2010 1 次提交
  11. 28 8月, 2010 1 次提交
  12. 25 7月, 2010 1 次提交
  13. 19 7月, 2010 1 次提交
  14. 12 5月, 2010 1 次提交
  15. 31 12月, 2009 1 次提交
  16. 17 11月, 2009 1 次提交
  17. 12 11月, 2009 1 次提交
  18. 13 6月, 2009 1 次提交
  19. 17 1月, 2009 1 次提交
  20. 16 1月, 2009 2 次提交
  21. 19 12月, 2008 1 次提交
  22. 17 10月, 2008 1 次提交
  23. 11 10月, 2008 2 次提交
  24. 18 8月, 2008 1 次提交
    • D
      x86: fix i486 suspend to disk CR4 oops · e532c06f
      David Fries 提交于
      arch/x86/power/cpu_32.c __save_processor_state calls read_cr4()
      only a i486 CPU doesn't have the CR4 register.  Trying to read it
      produces an invalid opcode oops during suspend to disk.
      
      Use the safe rc4 reading op instead. If the value to be written is
      zero the write is skipped.
      
      arch/x86/power/hibernate_asm_32.S
      done: swapped the use of %eax and %ecx to use jecxz for
      the zero test and jump over store to %cr4.
      restore_image: s/%ecx/%eax/ to be consistent with done:
      
      In addition to __save_processor_state, acpi_save_state_mem,
      efi_call_phys_prelog, and efi_call_phys_epilog had checks added
      (acpi restore was in assembly and already had a check for
      non-zero).  There were other reads and writes of CR4, but MCE and
      virtualization shouldn't be executed on a i486 anyway.
      Signed-off-by: NDavid Fries <david@fries.net>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e532c06f
  25. 15 8月, 2008 1 次提交
  26. 25 7月, 2008 1 次提交
  27. 18 7月, 2008 2 次提交
    • H
      x86: unify and correct the GDT_ENTRY() macro · f910d134
      H. Peter Anvin 提交于
      Impact: None (cleanup only)
      
      Merge the GDT_ENTRY() macro between arch/x86/boot/pm.c and
      arch/x86/kernel/acpi/sleep.c and put the new one in
      <asm-x86/segment.h>.
      
      While we're at it, correct the bitmasks for the limit and flags.  The
      new version relies on using ULL constants in order to cause type
      promotion rather than explicit casts; this avoids having to include
      <linux/types.h> in <asm-x86/segments.h>.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      f910d134
    • H
      x86: unify and correct the GDT_ENTRY() macro · 4fdf08b5
      H. Peter Anvin 提交于
      Merge the GDT_ENTRY() macro between arch/x86/boot/pm.c and
      arch/x86/kernel/acpi/sleep.c and put the new one in
      <asm-x86/segment.h>.
      
      While we're at it, correct the bitmasks for the limit and flags.  The
      new version relies on using ULL constants in order to cause type
      promotion rather than explicit casts; this avoids having to include
      <linux/types.h> in <asm-x86/segments.h>.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      4fdf08b5
  28. 15 7月, 2008 2 次提交
    • H
      x86, suspend, acpi: correct and add comments about Big Real Mode · 065cb3df
      H. Peter Anvin 提交于
      Explain that we set up the descriptors for Big Real Mode, and why we
      do so.  In particular, one system that is known to fail without it is
      the Lenovo X61.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      065cb3df
    • H
      x86, suspend, acpi: enter Big Real Mode · 3bf2e774
      H. Peter Anvin 提交于
      The explanation for recent video BIOS suspend quirk failures is that
      the VESA BIOS expects to be entered in Big Real Mode (*.limit = 0xffffffff)
      instead of ordinary Real Mode (*.limit = 0xffff).
      
      This patch changes the segment descriptors to Big Real Mode instead.
      
      The segment descriptor registers (what Intel calls "segment cache") is
      always active.  The only thing that changes based on CR0.PE is how it is
      *loaded* and the interpretation of the CS flags.
      
      The segment descriptor registers contain of the following sub-registers:
      selector (the "visible" part), base, limit and flags.  In protected mode
      or long mode, they are loaded from descriptors (or fs.base or gs.base can
      be manipulated directly in long mode.)  In real mode, the only thing
      changed by a segment register load is the selector and the base, where the
      base <- selector << 4.  In particular, *the limit and the flags are not
      changed*.
      
      As far as the handling of the CS flags: a code segment cannot be writable
      in protected mode, whereas it is "just another segment" in real mode, so
      there is some kind of quirk that kicks in for this when CR0.PE <- 0.  I'm
      not sure if this is accomplished by actually changing the cs.flags register
      or just changing the interpretation; it might be something that is
      CPU-specific.  In particular, the Transmeta CPUs had an explicit "CS is
      writable if you're in real mode" override, so even if you had loaded CS
      with an execute-only segment it'd be writable (but not readable!) on return
      to real mode.  I'm not at all sure if that is how other CPUs behave.
      Signed-off-by: N"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3bf2e774
  29. 08 7月, 2008 2 次提交
  30. 05 7月, 2008 1 次提交
  31. 13 6月, 2008 1 次提交
    • R
      Suspend-related patches for 2.6.27 · d8f3de0d
      Rafael J. Wysocki 提交于
      ACPI PM: Add possibility to change suspend sequence
      
      There are some systems out there that don't work correctly with
      our current suspend/hibernation code ordering.  Provide a workaround
      for these systems allowing them to pass 'acpi_sleep=old_ordering' in
      the kernel command line so that it will use the pre-ACPI 2.0 ("old")
      suspend code ordering.
      
      Unfortunately, this requires us to add a platform hook to the
      resuming of devices for recovering the platform in case one of the
      device drivers' .suspend() routines returns error code.  Namely,
      ACPI 1.0 specifies that _PTS should be called before suspending
      devices, but _WAK still should be called before resuming them in
      order to undo the changes made by _PTS.  However, if there is an
      error during suspending devices, they are automatically resumed
      without returning control to the PM core, so the _WAK has to be
      called from within device_resume() in that cases.
      
      The patch also reorders and refactors the ACPI suspend/hibernation
      code to avoid duplication as far as reasonably possible.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      d8f3de0d
  32. 17 4月, 2008 1 次提交
    • P
      x86: move suspend wakeup code to C · e44b7b75
      Pavel Machek 提交于
      Move wakeup code to .c, so that video mode setting code can be shared
      between boot and wakeup. Remove nasty assembly code in 64-bit case by
      re-using trampoline code. Stack setup was fixed to clear high 16bits
      of %esp, maybe that fixes some machines.
      
      .c code sharing and morse code was done H. Peter Anvin, Sam Ravnborg
      reviewed kbuild related stuff, and it seems okay to him. Rafael did
      some cleanups.
      
      [rjw:
      * Made the patch stop breaking compilation on x86-32
      * Added arch/x86/kernel/acpi/sleep.h
      * Got rid of compiler warnings in arch/x86/kernel/acpi/sleep.c
      * Fixed 32-bit compilation on x86-64 systems
      * Added include/asm-x86/trampoline.h and fixed the non-SMP
        compilation on 64-bit x86
      * Removed arch/x86/kernel/acpi/sleep_32.c which was not used
      * Fixed some breakage caused by the integration of smpboot.c done
        under us in the meantime]
      Signed-off-by: NPavel Machek <pavel@suse.cz>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e44b7b75