1. 15 Dec, 2009 3 commits
    • Ingo Molnar's avatar
      Merge branch 'x86/mce' into x86/urgent · bf08b3b1
      Ingo Molnar authored
      Merge reason: Leftover mini-topic from the merge window - merge it.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      bf08b3b1
    • Ingo Molnar's avatar
      Merge branch 'x86/asm' into x86/urgent · ab1eebe7
      Ingo Molnar authored
      Merge reason: it's stable so lets push it upstream.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ab1eebe7
    • FUJITA Tomonori's avatar
      x86: Split swiotlb initialization into two stages · 186a2502
      FUJITA Tomonori authored
      The commit f4780ca0 moves
      swiotlb initialization before dma32_free_bootmem(). It's
      supposed to fix a bug that the commit
      75f1cdf1 introduced, we
      initialize SWIOTLB right after dma32_free_bootmem so we wrongly
      steal memory area allocated for GART with broken BIOS earlier.
      
      However, the above commit introduced another problem, which
      likely breaks machines with huge amount of memory. Such a box
      use the majority of DMA32_ZONE so there is no memory for
      swiotlb.
      
      With this patch, the x86 IOMMU initialization sequence are:
      
      1. We set swiotlb to 1 in the case of (max_pfn > MAX_DMA32_PFN
         && !no_iommu). If swiotlb usage is forced by the boot option,
         we go to the step 3 and finish (we don't try to detect IOMMUs).
      
      2. We call the detection functions of all the IOMMUs. The
         detection function sets x86_init.iommu.iommu_init to the IOMMU
         initialization function (so we can avoid calling the
         initialization functions of all the IOMMUs needlessly).
      
      3. We initialize swiotlb (and set dma_ops to swiotlb_dma_ops) if
         swiotlb is set to 1.
      
      4. If the IOMMU initialization function doesn't need swiotlb
         (e.g. the initialization is sucessful) then sets swiotlb to zero.
      
      5. If we find that swiotlb is set to zero, we free swiotlb
         resource.
      Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
      Reported-by: default avatarRoland Dreier <rdreier@cisco.com>
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      LKML-Reference: <20091215204729A.fujita.tomonori@lab.ntt.co.jp>
      Tested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      186a2502
  2. 14 Dec, 2009 8 commits
  3. 13 Dec, 2009 1 commit
  4. 11 Dec, 2009 13 commits
    • H. Peter Anvin's avatar
      nvram: Fix write beyond end condition; prove to gcc copy is safe · a01c7800
      H. Peter Anvin authored
      In nvram_write, first of all, correctly handle the case where the file
      pointer is already beyond the end; we should return EOF in that case.
      
      Second, make the logic a bit more explicit so that gcc can statically
      prove that the copy_from_user() is safe.  Once the condition of the
      beyond-end filepointer is eliminated, the copy is safe but gcc can't
      prove it, causing build failures for i386 allyesconfig.
      
      Third, eliminate the entirely superfluous variable "len", and just use
      the passed-in variable "count" instead.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <tip-*@git.kernel.org>
      a01c7800
    • H. Peter Anvin's avatar
      mm: Adjust do_pages_stat() so gcc can see copy_from_user() is safe · b9255850
      H. Peter Anvin authored
      Slightly adjust the logic for determining the size of the
      copy_form_user() in do_pages_stat(); with this change, gcc can see
      that the copying is safe.
      
      Without this, we get a build error for i386 allyesconfig:
      
      /home/hpa/kernel/linux-2.6-tip.urgent/arch/x86/include/asm/uaccess_32.h:213:
      error: call to ‘copy_from_user_overflow’ declared with attribute
      error: copy_from_user() buffer size is not provably correct
      
      Unlike an earlier patch from Arjan, this doesn't introduce new
      variables; merely reshuffles the compare so that gcc can see that an
      overflow cannot happen.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Brice Goglin <Brice.Goglin@inria.fr>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      LKML-Reference: <20090926205406.30d55b08@infradead.org>
      b9255850
    • Mike Travis's avatar
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis authored
      When there are a large number of processors in a system, there
      is an excessive amount of messages sent to the system console.
      It's estimated that with 4096 processors in a system, and the
      console baudrate set to 56K, the startup messages will take
      about 84 minutes to clear the serial port.
      
      This set of patches limits the number of repetitious messages
      which contain no additional information.  Much of this information
      is obtainable from the /proc and /sysfs.   Some of the messages
      are also sent to the kernel log buffer as KERN_DEBUG messages so
      dmesg can be used to examine more closely any details specific to
      a problem.
      
      The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
      
      Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
      Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
      ...
      Booting Node   3, Processors  #56 #57 #58 #59 #60 #61 #62 #63 Ok.
      Brought up 64 CPUs
      
      After the system is running, a single line boot message is displayed
      when CPU's are hotplugged on:
      
          Booting Node %d Processor %d APIC 0x%x
      
      Status of the following lines:
      
          CPU: Physical Processor ID:		printed once (for boot cpu)
          CPU: Processor Core ID:		printed once (for boot cpu)
          CPU: Hyper-Threading is disabled	printed once (for boot cpu)
          CPU: Thermal monitoring enabled	printed once (for boot cpu)
          CPU %d/0x%x -> Node %d:		removed
          CPU %d is now offline:		only if system_state == RUNNING
          Initializing CPU#%d:		KERN_DEBUG
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
    • Mike Travis's avatar
      x86: Remove enabling x2apic message for every CPU · 450b1e8d
      Mike Travis authored
      Print only once that the system is supporting x2apic mode.
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Acked-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <4B226E92.5080904@sgi.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      450b1e8d
    • H. Peter Anvin's avatar
      doc: Add documentation for bootloader_{type,version} · d75757ab
      H. Peter Anvin authored
      Add documentation for kernel/bootloader_type and
      kernel/bootloader_version to sysctl/kernel.txt.  This should really
      have been done a long time ago.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Shen Feng <shen@cn.fujitsu.com>
      d75757ab
    • Borislav Petkov's avatar
      x86, msr: Add support for non-contiguous cpumasks · 50542251
      Borislav Petkov authored
      The current rd/wrmsr_on_cpus helpers assume that the supplied
      cpumasks are contiguous. However, there are machines out there
      like some K8 multinode Opterons which have a non-contiguous core
      enumeration on each node (e.g. cores 0,2 on node 0 instead of 0,1), see
      http://www.gossamer-threads.com/lists/linux/kernel/1160268.
      
      This patch fixes out-of-bounds writes (see URL above) by adding per-CPU
      msr structs which are used on the respective cores.
      
      Additionally, two helpers, msrs_{alloc,free}, are provided for use by
      the callers of the MSR accessors.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Aristeu Rozanski <aris@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20091211171440.GD31998@aftab>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      50542251
    • H. Peter Anvin's avatar
      5c6baba8
    • Yinghai Lu's avatar
      x86: Use find_e820() instead of hard coded trampoline address · 893f38d1
      Yinghai Lu authored
      Jens found the following crash/regression:
      
      [    0.000000] found SMP MP-table at [ffff8800000fdd80] fdd80
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 0-fff BIOS data page
      
      and
      
      [    0.000000] Kernel panic - not syncing: Overlapping early reservations 12-f011 MP-table mpc to 6000-7fff TRAMPOLINE
      
      and bisected it to b24c2a92 ("x86: Move find_smp_config()
      earlier and avoid bootmem usage").
      
      It turns out the BIOS is using the first 64k for mptable,
      without reserving it.
      
      So try to find good range for the real-mode trampoline instead of
      hard coding it, in case some bios tries to use that range for sth.
      Reported-by: default avatarJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Tested-by: default avatarJens Axboe <jens.axboe@oracle.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <4B21630A.6000308@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      893f38d1
    • Linus Torvalds's avatar
      Merge branch 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 · 3ef884b4
      Linus Torvalds authored
      * 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (189 commits)
        drm/radeon/kms: fix warning about cur_placement being uninitialised.
        drm/ttm: Print debug information on memory manager when eviction fails
        drm: Add memory manager debug function
        drm/radeon/kms: restore surface registers on resume.
        drm/radeon/kms/r600/r700: fallback gracefully on ucode failure
        drm/ttm: Initialize eviction placement in case the driver callback doesn't
        drm/radeon/kms: cleanup structure and module if initialization fails
        drm/radeon/kms: actualy set the eviction placements we choose
        drm/radeon/kms: Fix NULL ptr dereference
        drm/radeon/kms/avivo: add support for new pll selection algo
        drm/radeon/kms/avivo: fix some bugs in the display bandwidth setup
        drm/radeon/kms: fix return value from fence function.
        drm/radeon: Remove tests for -ERESTART from the TTM code.
        drm/ttm: Have the TTM code return -ERESTARTSYS instead of -ERESTART.
        drm/radeon/kms: Convert radeon to new TTM validation API (V2)
        drm/ttm: Rework validation & memory space allocation (V3)
        drm: Add search/get functions to get a block in a specific range
        drm/radeon/kms: fix avivo tiling regression since radeon object rework
        drm/i915: Remove a debugging printk from hangcheck
        drm/radeon/kms: make sure i2c id matches
        ...
      3ef884b4
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp · 4e5df806
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp: (21 commits)
        amd64_edac: bump driver version
        amd64_edac: fix use-uninitialised bug
        amd64_edac: correct sys address to chip select mapping
        amd64_edac: add a leaner syndrome decoding algorithm
        amd64_edac: remove early hw support check
        amd64_edac: detect DDR3 memory type
        edac: add memory types strings for debugging
        edac, mce: update AMD F10h revD check
        amd64_edac: remove unneeded extract_error_address wrapper
        amd64_edac: rename StinkyIdentifier
        amd64_edac: remove superfluous dbg printk
        amd64_edac: enhance address to DRAM bank mapping
        amd64_edac: cleanup f10_early_channel_count
        amd64_edac: dump DIMM sizes on K8 too
        amd64_edac: cleanup rest of amd64_dump_misc_regs
        amd64_edac: cleanup DRAM cfg low debug output
        amd64_edac: wrap-up pci config read error handling
        amd64_edac: unify MCGCTL ECC switching
        cpumask: use modern cpumask style in drivers/edac/amd64_edac.c
        amd64_edac: make DRAM regions output more human-readable
        ...
      4e5df806
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://gitorious.org/linux-omap-dss2/linux · aa2cf420
      Linus Torvalds authored
      * 'for-linus' of git://gitorious.org/linux-omap-dss2/linux:
        MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer
        OMAP: SDP: Enable DSS2 for OMAP3 SDP board
        OMAP: DSS2: Taal DSI command mode panel driver
        OMAP: DSS2: Add generic and Sharp panel drivers
        OMAP: DSS2: omapfb driver
        OMAP: DSS2: DSI driver
        OMAP: DSS2: SDI driver
        OMAP: DSS2: RFBI driver
        OMAP: DSS2: Video encoder driver
        OMAP: DSS2: DPI driver
        OMAP: DSS2: DISPC
        OMAP: DSS2: Add more core files
        OMAP: DSS2: Display Subsystem Driver core
        OMAP: DSS2: Documentation for DSS2
        OMAP: Add support for VRFB rotation engine
        OMAP: Add VRAM manager
        OMAP: OMAPFB: add omapdss device
        OMAP: OMAPFB: split omapfb.h
        OMAP2: Add funcs for writing SMS_ROT_* registers
      aa2cf420
    • Prarit Bhargava's avatar
      x86, AMD: Fix stale cpuid4_info shared_map data in shared_cpu_map cpumasks · ebb682f5
      Prarit Bhargava authored
      The per_cpu cpuid4_info shared_map can contain stale data when CPUs are added
      and removed.
      
      The stale data can lead to a NULL pointer derefernce panic on a remove of a
      CPU that has had siblings previously removed.
      
      This patch resolves the panic by verifying a cpu is actually online before
      adding it to the shared_cpu_map, only examining cpus that are part of
      the same lower level cache, and by updating other siblings lowest level cache
      maps when a cpu is added.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      LKML-Reference: <20091209183336.17855.98708.sendpatchset@prarit.bos.redhat.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      ebb682f5
    • Brian Gerst's avatar
      x86: Merge kernel_thread() · df59e7bf
      Brian Gerst authored
      Signed-off-by: default avatarBrian Gerst <brgerst@gmail.com>
      LKML-Reference: <1260380084-3707-6-git-send-email-brgerst@gmail.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      df59e7bf
  5. 10 Dec, 2009 15 commits