[kernel] r11851 - dists/trunk/linux-2.6/debian/patches/bugfix/all

[Maximilian Attems]

Author: maks
Date: Thu Jul 17 08:17:56 2008
New Revision: 11851

Log:
x86-acpi-sleep-x61s.patch add patch desc

Modified:
   dists/trunk/linux-2.6/debian/patches/bugfix/all/x86-acpi-sleep-x61s.patch

Modified: dists/trunk/linux-2.6/debian/patches/bugfix/all/x86-acpi-sleep-x61s.patch
==============================================================================
--- dists/trunk/linux-2.6/debian/patches/bugfix/all/x86-acpi-sleep-x61s.patch	(original)
+++ dists/trunk/linux-2.6/debian/patches/bugfix/all/x86-acpi-sleep-x61s.patch	Thu Jul 17 08:17:56 2008
@@ -1,8 +1,43 @@
-From: H. Peter Anvin <hpa at zytor.com>
+commit 3bf2e77453a87c22eb57ed4926760ac131c84459
+Author: H. Peter Anvin <hpa at zytor.com>
+Date:   Sun Jul 13 21:18:02 2008 -0700
 
-fixes regression concering 4b4f7280 see
-http://bugzilla.kernel.org/show_bug.cgi?id=11064
-http://marc.info/?l=linux-kernel&m=121584459809675&w=4
+    x86, suspend, acpi: enter Big Real Mode
+    
+    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
+    fixees 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: "H. Peter Anvin" <hpa at zytor.com>
+    Signed-off-by: Ingo Molnar <mingo at elte.hu>
+
+    regression concering 4b4f7280 see
+    http://bugzilla.kernel.org/show_bug.cgi?id=11064
+    http://marc.info/?l=linux-kernel&m=121584459809675&w=4
 
 diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
 index 36af01f..130711f 100644