Merge branch 'x86/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'x86/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (821 commits)
  x86: make 64bit hpet_set_mapping to use ioremap too, v2
  x86: get x86_phys_bits early
  x86: max_low_pfn_mapped fix #4
  x86: change _node_to_cpumask_ptr to return const ptr
  x86: I/O APIC: remove an IRQ2-mask hack
  x86: fix numaq_tsc_disable calling
  x86, e820: remove end_user_pfn
  x86: max_low_pfn_mapped fix, #3
  x86: max_low_pfn_mapped fix, #2
  x86: max_low_pfn_mapped fix, #1
  x86_64: fix delayed signals
  x86: remove conflicting nx6325 and nx6125 quirks
  x86: Recover timer_ack lost in the merge of the NMI watchdog
  x86: I/O APIC: Never configure IRQ2
  x86: L-APIC: Always fully configure IRQ0
  x86: L-APIC: Set IRQ0 as edge-triggered
  x86: merge dwarf2 headers
  x86: use AS_CFI instead of UNWIND_INFO
  x86: use ignore macro instead of hash comment
  x86: use matching CFI_ENDPROC
  ...

16 files changed, 168 insertions, 46 deletions

diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap
new file mode 100644
index 000000000000..0d99ee6ae02e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-memmap
@@ -0,0 +1,71 @@
+What:           /sys/firmware/memmap/
+Date:           June 2008
+Contact:        Bernhard Walle <bwalle@suse.de>
+Description:
+                On all platforms, the firmware provides a memory map which the
+                kernel reads. The resources from that memory map are registered
+                in the kernel resource tree and exposed to userspace via
+                /proc/iomem (together with other resources).
+
+                However, on most architectures that firmware-provided memory
+                map is modified afterwards by the kernel itself, either because
+                the kernel merges that memory map with other information or
+                just because the user overwrites that memory map via command
+                line.
+
+                kexec needs the raw firmware-provided memory map to setup the
+                parameter segment of the kernel that should be booted with
+                kexec. Also, the raw memory map is useful for debugging. For
+                that reason, /sys/firmware/memmap is an interface that provides
+                the raw memory map to userspace.
+
+                The structure is as follows: Under /sys/firmware/memmap there
+                are subdirectories with the number of the entry as their name:
+
+                        /sys/firmware/memmap/0
+                        /sys/firmware/memmap/1
+                        /sys/firmware/memmap/2
+                        /sys/firmware/memmap/3
+                        ...
+
+                The maximum depends on the number of memory map entries provided
+                by the firmware. The order is just the order that the firmware
+                provides.
+
+                Each directory contains three files:
+
+                start   : The start address (as hexadecimal number with the
+                          '0x' prefix).
+                end     : The end address, inclusive (regardless whether the
+                          firmware provides inclusive or exclusive ranges).
+                type    : Type of the entry as string. See below for a list of
+                          valid types.
+
+                So, for example:
+
+                        /sys/firmware/memmap/0/start
+                        /sys/firmware/memmap/0/end
+                        /sys/firmware/memmap/0/type
+                        /sys/firmware/memmap/1/start
+                        ...
+
+                Currently following types exist:
+
+                  - System RAM
+                  - ACPI Tables
+                  - ACPI Non-volatile Storage
+                  - reserved
+
+                Following shell snippet can be used to display that memory
+                map in a human-readable format:
+
+                -------------------- 8< ----------------------------------------
+                  #!/bin/bash
+                  cd /sys/firmware/memmap
+                  for dir in * ; do
+                      start=$(cat $dir/start)
+                      end=$(cat $dir/end)
+                      type=$(cat $dir/type)
+                      printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
+                  done
+                -------------------- >8 ----------------------------------------
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index b8e52c0355d3..9691c7f5166c 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -109,7 +109,7 @@ There are two possible methods of using Kdump.
 2) Or use the system kernel binary itself as dump-capture kernel and there is
    no need to build a separate dump-capture kernel. This is possible
    only with the architecutres which support a relocatable kernel. As
-   of today i386 and ia64 architectures support relocatable kernel.
+   of today, i386, x86_64 and ia64 architectures support relocatable kernel.
 
 Building a relocatable kernel is advantageous from the point of view that
 one does not have to build a second kernel for capturing the dump. But
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b52f47d588b4..795c487af8e4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -271,6 +271,17 @@ and is between 256 and 4096 characters. It is defined in the file
         aic79xx=        [HW,SCSI]
                         See Documentation/scsi/aic79xx.txt.
 
+        amd_iommu=      [HW,X86-84]
+                        Pass parameters to the AMD IOMMU driver in the system.
+                        Possible values are:
+                        isolate - enable device isolation (each device, as far
+                                  as possible, will get its own protection
+                                  domain)
+        amd_iommu_size= [HW,X86-64]
+                        Define the size of the aperture for the AMD IOMMU
+                        driver. Possible values are:
+                        '32M', '64M' (default), '128M', '256M', '512M', '1G'
+
         amijoy.map=     [HW,JOY] Amiga joystick support
                         Map of devices attached to JOY0DAT and JOY1DAT
                         Format: <a>,<b>
@@ -599,6 +610,29 @@ and is between 256 and 4096 characters. It is defined in the file
                         See drivers/char/README.epca and
                         Documentation/digiepca.txt.
 
+        disable_mtrr_cleanup [X86]
+        enable_mtrr_cleanup [X86]
+                        The kernel tries to adjust MTRR layout from continuous
+                        to discrete, to make X server driver able to add WB
+                        entry later. This parameter enables/disables that.
+
+        mtrr_chunk_size=nn[KMG] [X86]
+                        used for mtrr cleanup. It is largest continous chunk
+                        that could hold holes aka. UC entries.
+
+        mtrr_gran_size=nn[KMG] [X86]
+                        Used for mtrr cleanup. It is granularity of mtrr block.
+                        Default is 1.
+                        Large value could prevent small alignment from
+                        using up MTRRs.
+
+        mtrr_spare_reg_nr=n [X86]
+                        Format: <integer>
+                        Range: 0,7 : spare reg number
+                        Default : 1
+                        Used for mtrr cleanup. It is spare mtrr entries number.
+                        Set to 2 or more if your graphical card needs more.
+
         disable_mtrr_trim [X86, Intel and AMD only]
                         By default the kernel will trim any uncacheable
                         memory out of your available memory pool based on
@@ -2116,6 +2150,9 @@ and is between 256 and 4096 characters. It is defined in the file
         usbhid.mousepoll=
                         [USBHID] The interval which mice are to be polled at.
 
+        add_efi_memmap  [EFI; x86-32,X86-64] Include EFI memory map in
+                        kernel's map of available physical RAM.
+
         vdso=           [X86-32,SH,x86-64]
                         vdso=2: enable compat VDSO (default with COMPAT_VDSO)
                         vdso=1: enable VDSO (default)
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt
index 757c729ee42e..90aa4531cb67 100644
--- a/Documentation/nmi_watchdog.txt
+++ b/Documentation/nmi_watchdog.txt
@@ -10,7 +10,7 @@ us to generate 'watchdog NMI interrupts'.  (NMI: Non Maskable Interrupt
 which get executed even if the system is otherwise locked up hard).
 This can be used to debug hard kernel lockups.  By executing periodic
 NMI interrupts, the kernel can monitor whether any CPU has locked up,
-and print out debugging messages if so.  
+and print out debugging messages if so.
 
 In order to use the NMI watchdog, you need to have APIC support in your
 kernel. For SMP kernels, APIC support gets compiled in automatically. For
@@ -22,8 +22,7 @@ CONFIG_X86_UP_IOAPIC is for uniprocessor with an IO-APIC. [Note: certain
 kernel debugging options, such as Kernel Stack Meter or Kernel Tracer,
 may implicitly disable the NMI watchdog.]
 
-For x86-64, the needed APIC is always compiled in, and the NMI watchdog is
-always enabled with I/O-APIC mode (nmi_watchdog=1).
+For x86-64, the needed APIC is always compiled in.
 
 Using local APIC (nmi_watchdog=2) needs the first performance register, so
 you can't use it for other purposes (such as high precision performance
@@ -63,16 +62,15 @@ when the system is idle), but if your system locks up on anything but the
 "hlt", then you are out of luck -- the event will not happen at all and the
 watchdog won't trigger. This is a shortcoming of the local APIC watchdog
 -- unfortunately there is no "clock ticks" event that would work all the
-time. The I/O APIC watchdog is driven externally and has no such shortcoming.  
+time. The I/O APIC watchdog is driven externally and has no such shortcoming.
 But its NMI frequency is much higher, resulting in a more significant hit
 to the overall system performance.
 
-NOTE: starting with 2.4.2-ac18 the NMI-oopser is disabled by default,
-you have to enable it with a boot time parameter.  Prior to 2.4.2-ac18
-the NMI-oopser is enabled unconditionally on x86 SMP boxes.
+On x86 nmi_watchdog is disabled by default so you have to enable it with
+a boot time parameter.
 
-On x86-64 the NMI oopser is on by default. On 64bit Intel CPUs
-it uses IO-APIC by default and on AMD it uses local APIC.
+NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally
+on x86 SMP boxes.
 
 [ feel free to send bug reports, suggestions and patches to
   Ingo Molnar <mingo@redhat.com> or the Linux SMP mailing
diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/x86/i386/IO-APIC.txt
index 30b4c714fbe1..30b4c714fbe1 100644
--- a/Documentation/i386/IO-APIC.txt
+++ b/Documentation/x86/i386/IO-APIC.txt
diff --git a/Documentation/i386/boot.txt b/Documentation/x86/i386/boot.txt
index 95ad15c3b01f..147bfe511cdd 100644
--- a/Documentation/i386/boot.txt
+++ b/Documentation/x86/i386/boot.txt
@@ -1,17 +1,14 @@
-                     THE LINUX/I386 BOOT PROTOCOL
-                     ----------------------------
+                     THE LINUX/x86 BOOT PROTOCOL
+                     ---------------------------
 
-                    H. Peter Anvin <hpa@zytor.com>
-                        Last update 2007-05-23
-
-On the i386 platform, the Linux kernel uses a rather complicated boot
+On the x86 platform, the Linux kernel uses a rather complicated boot
 convention.  This has evolved partially due to historical aspects, as
 well as the desire in the early days to have the kernel itself be a
 bootable image, the complicated PC memory model and due to changed
 expectations in the PC industry caused by the effective demise of
 real-mode DOS as a mainstream operating system.
 
-Currently, the following versions of the Linux/i386 boot protocol exist.
+Currently, the following versions of the Linux/x86 boot protocol exist.
 
 Old kernels:    zImage/Image support only.  Some very early kernels
                 may not even support a command line.
@@ -372,10 +369,17 @@ Protocol:	2.00+
         - If 0, the protected-mode code is loaded at 0x10000.
         - If 1, the protected-mode code is loaded at 0x100000.
 
+  Bit 5 (write): QUIET_FLAG
+        - If 0, print early messages.
+        - If 1, suppress early messages.
+                This requests to the kernel (decompressor and early
+                kernel) to not write early messages that require
+                accessing the display hardware directly.
+
   Bit 6 (write): KEEP_SEGMENTS
         Protocol: 2.07+
-        - if 0, reload the segment registers in the 32bit entry point.
-        - if 1, do not reload the segment registers in the 32bit entry point.
+        - If 0, reload the segment registers in the 32bit entry point.
+        - If 1, do not reload the segment registers in the 32bit entry point.
                 Assume that %cs %ds %ss %es are all set to flat segments with
                 a base of 0 (or the equivalent for their environment).
 
@@ -504,7 +508,7 @@ Protocol:	2.06+
   maximum size was 255.
 
 Field name:     hardware_subarch
-Type:           write
+Type:           write (optional, defaults to x86/PC)
 Offset/size:    0x23c/4
 Protocol:       2.07+
 
@@ -520,11 +524,13 @@ Protocol:	2.07+
   0x00000002    Xen
 
 Field name:     hardware_subarch_data
-Type:           write
+Type:           write (subarch-dependent)
 Offset/size:    0x240/8
 Protocol:       2.07+
 
   A pointer to data that is specific to hardware subarch
+  This field is currently unused for the default x86/PC environment,
+  do not modify.
 
 Field name:     payload_offset
 Type:           read
@@ -545,6 +551,34 @@ Protocol:	2.08+
 
   The length of the payload.
 
+Field name:     setup_data
+Type:           write (special)
+Offset/size:    0x250/8
+Protocol:       2.09+
+
+  The 64-bit physical pointer to NULL terminated single linked list of
+  struct setup_data. This is used to define a more extensible boot
+  parameters passing mechanism. The definition of struct setup_data is
+  as follow:
+
+  struct setup_data {
+          u64 next;
+          u32 type;
+          u32 len;
+          u8  data[0];
+  };
+
+  Where, the next is a 64-bit physical pointer to the next node of
+  linked list, the next field of the last node is 0; the type is used
+  to identify the contents of data; the len is the length of data
+  field; the data holds the real payload.
+
+  This list may be modified at a number of points during the bootup
+  process.  Therefore, when modifying this list one should always make
+  sure to consider the case where the linked list already contains
+  entries.
+
+
 **** THE IMAGE CHECKSUM
 
 From boot protocol version 2.08 onwards the CRC-32 is calculated over
@@ -553,6 +587,7 @@ initial remainder of 0xffffffff.  The checksum is appended to the
 file; therefore the CRC of the file up to the limit specified in the
 syssize field of the header is always 0.
 
+
 **** THE KERNEL COMMAND LINE
 
 The kernel command line has become an important way for the boot
@@ -584,28 +619,6 @@ command line is entered using the following protocol:
         covered by setup_move_size, so you may need to adjust this
         field.
 
-Field name:     setup_data
-Type:           write (obligatory)
-Offset/size:    0x250/8
-Protocol:       2.09+
-
-  The 64-bit physical pointer to NULL terminated single linked list of
-  struct setup_data. This is used to define a more extensible boot
-  parameters passing mechanism. The definition of struct setup_data is
-  as follow:
-
-  struct setup_data {
-          u64 next;
-          u32 type;
-          u32 len;
-          u8  data[0];
-  };
-
-  Where, the next is a 64-bit physical pointer to the next node of
-  linked list, the next field of the last node is 0; the type is used
-  to identify the contents of data; the len is the length of data
-  field; the data holds the real payload.
-
 
 **** MEMORY LAYOUT OF THE REAL-MODE CODE
 
diff --git a/Documentation/i386/usb-legacy-support.txt b/Documentation/x86/i386/usb-legacy-support.txt
index 1894cdfc69d9..1894cdfc69d9 100644
--- a/Documentation/i386/usb-legacy-support.txt
+++ b/Documentation/x86/i386/usb-legacy-support.txt
diff --git a/Documentation/i386/zero-page.txt b/Documentation/x86/i386/zero-page.txt
index 169ad423a3d1..169ad423a3d1 100644
--- a/Documentation/i386/zero-page.txt
+++ b/Documentation/x86/i386/zero-page.txt
diff --git a/Documentation/x86_64/00-INDEX b/Documentation/x86/x86_64/00-INDEX
index 92fc20ab5f0e..92fc20ab5f0e 100644
--- a/Documentation/x86_64/00-INDEX
+++ b/Documentation/x86/x86_64/00-INDEX
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index b0c7b6c4abda..b0c7b6c4abda 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
diff --git a/Documentation/x86_64/cpu-hotplug-spec b/Documentation/x86/x86_64/cpu-hotplug-spec
index 3c23e0587db3..3c23e0587db3 100644
--- a/Documentation/x86_64/cpu-hotplug-spec
+++ b/Documentation/x86/x86_64/cpu-hotplug-spec
diff --git a/Documentation/x86_64/fake-numa-for-cpusets b/Documentation/x86/x86_64/fake-numa-for-cpusets
index d1a985c5b00a..d1a985c5b00a 100644
--- a/Documentation/x86_64/fake-numa-for-cpusets
+++ b/Documentation/x86/x86_64/fake-numa-for-cpusets
diff --git a/Documentation/x86_64/kernel-stacks b/Documentation/x86/x86_64/kernel-stacks
index 5ad65d51fb95..5ad65d51fb95 100644
--- a/Documentation/x86_64/kernel-stacks
+++ b/Documentation/x86/x86_64/kernel-stacks
diff --git a/Documentation/x86_64/machinecheck b/Documentation/x86/x86_64/machinecheck
index a05e58e7b159..a05e58e7b159 100644
--- a/Documentation/x86_64/machinecheck
+++ b/Documentation/x86/x86_64/machinecheck
diff --git a/Documentation/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index b89b6d2bebfa..efce75097369 100644
--- a/Documentation/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -11,9 +11,8 @@ ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole
 ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space
 ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB)
 ... unused hole ...
-ffffffff80000000 - ffffffff82800000 (=40 MB)   kernel text mapping, from phys 0
-... unused hole ...
-ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space
+ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
 
 The direct mapping covers all memory in the system up to the highest
 memory address (this means in some cases it can also include PCI memory
diff --git a/Documentation/x86_64/uefi.txt b/Documentation/x86/x86_64/uefi.txt
index 7d77120a5184..a5e2b4fdb170 100644
--- a/Documentation/x86_64/uefi.txt
+++ b/Documentation/x86/x86_64/uefi.txt
@@ -36,3 +36,7 @@ Mechanics:
   services.
         noefi           turn off all EFI runtime services
         reboot_type=k   turn off EFI reboot runtime service
+- If the EFI memory map has additional entries not in the E820 map,
+  you can include those entries in the kernels memory map of available
+  physical RAM by using the following kernel command line parameter.
+        add_efi_memmap  include EFI memory map of available physical RAM