1. 06 Jun, 2012 4 commits
    • Yasuaki Ishimatsu's avatar
      x86/numa: Set numa_nodes_parsed at acpi_numa_memory_affinity_init() · 4af463d2
      Yasuaki Ishimatsu authored
      When hot-adding a CPU, the system outputs following messages
      since node_to_cpumask_map[2] was not allocated memory.
      
      Booting Node 2 Processor 32 APIC 0xc0
      node_to_cpumask_map[2] NULL
      Pid: 0, comm: swapper/32 Tainted: G       A     3.3.5-acd #21
      Call Trace:
       [<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
       [<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
       [<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
       [<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
       [<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
       [<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
       [<ffffffff81505263>] smp_callin+0x139/0x1be
       [<ffffffff815052fb>] start_secondary+0x13/0xeb
      
      The reason is that the bit of node 2 was not set at
      numa_nodes_parsed. numa_nodes_parsed is set by only
      acpi_numa_processor_affinity_init /
      acpi_numa_x2apic_affinity_init. Thus even if hot-added memory
      which is same PXM as hot-added CPU is written in ACPI SRAT
      Table, if the hot-added CPU is not written in ACPI SRAT table,
      numa_nodes_parsed is not set.
      
      But according to ACPI Spec Rev 5.0, it says about ACPI SRAT
      table as follows: This optional table provides information that
      allows OSPM to associate processors and memory ranges, including
      ranges of memory provided by hot-added memory devices, with
      system localities / proximity domains and clock domains.
      
      It means that ACPI SRAT table only provides information for CPUs
      present at boot time and for memory including hot-added memory.
      So hot-added memory is written in ACPI SRAT table, but hot-added
      CPU is not written in it. Thus numa_nodes_parsed should be set
      by not only acpi_numa_processor_affinity_init /
      acpi_numa_x2apic_affinity_init but also
      acpi_numa_memory_affinity_init for the case.
      
      Additionally, if system has cpuless memory node,
      acpi_numa_processor_affinity_init /
      acpi_numa_x2apic_affinity_init cannot set numa_nodes_parseds
      since these functions cannot find cpu description for the node.
      In this case, numa_nodes_parsed needs to be set by
      acpi_numa_memory_affinity_init.
      Signed-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: liuj97@gmail.com
      Cc: kosaki.motohiro@gmail.com
      Link: http://lkml.kernel.org/r/4FCC2098.4030007@jp.fujitsu.com
      [ merged it ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4af463d2
    • Xiaotian Feng's avatar
      x86/gart: Fix kmemleak warning · aff5a62d
      Xiaotian Feng authored
      aperture_64.c now is using memblock, the previous
      kmemleak_ignore() for alloc_bootmem() should be removed then.
      
      Otherwise, with kmemleak enabled, kernel will throw warnings
      like:
      
      [    0.000000] kmemleak: Trying to color unknown object at 0xffff8800c4000000 as Black
      [    0.000000] Pid: 0, comm: swapper/0 Not tainted 3.5.0-rc1-next-20120605+ #130
      [    0.000000] Call Trace:
      [    0.000000]  [<ffffffff811b27e6>] paint_ptr+0x66/0xc0
      [    0.000000]  [<ffffffff816b90fb>] kmemleak_ignore+0x2b/0x60
      [    0.000000]  [<ffffffff81ef7bc0>] kmemleak_init+0x217/0x2c1
      [    0.000000]  [<ffffffff81ed2b97>] start_kernel+0x32d/0x3eb
      [    0.000000]  [<ffffffff81ed25e4>] ? repair_env_string+0x5a/0x5a
      [    0.000000]  [<ffffffff81ed2356>] x86_64_start_reservations+0x131/0x135
      [    0.000000]  [<ffffffff81ed2120>] ? early_idt_handlers+0x120/0x120
      [    0.000000]  [<ffffffff81ed245c>] x86_64_start_kernel+0x102/0x111
      [    0.000000] kmemleak: Early log backtrace:
      [    0.000000]    [<ffffffff816b911b>] kmemleak_ignore+0x4b/0x60
      [    0.000000]    [<ffffffff81ee6a38>] gart_iommu_hole_init+0x3e7/0x547
      [    0.000000]    [<ffffffff81edb20b>] pci_iommu_alloc+0x44/0x6f
      [    0.000000]    [<ffffffff81ee81ad>] mem_init+0x19/0xec
      [    0.000000]    [<ffffffff81ed2a54>] start_kernel+0x1ea/0x3eb
      [    0.000000]    [<ffffffff81ed2356>] x86_64_start_reservations+0x131/0x135
      [    0.000000]    [<ffffffff81ed245c>] x86_64_start_kernel+0x102/0x111
      [    0.000000]    [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: default avatarXiaotian Feng <dannyfeng@tencent.com>
      Cc: Xiaotian Feng <xtfeng@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/1338922831-2847-1-git-send-email-xtfeng@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      aff5a62d
    • Thomas Gleixner's avatar
      x86: mce: Add the dropped timer interval init back · 1a87fc1e
      Thomas Gleixner authored
      commit 82f7af09 ("x86/mce: Cleanup timer mess) dropped the
      initialization of the per cpu timer interval. Duh :(
      
      Restore the previous behaviour.
      Reported-by: default avatarChen Gong <gong.chen@linux.intel.com>
      Cc: bp@amd64.org
      Cc: tony.luck@intel.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      1a87fc1e
    • Chen Gong's avatar
      x86/mce: Fix the MCE poll timer logic · 958fb3c5
      Chen Gong authored
      In commit 82f7af09 ("x86/mce: Cleanup timer mess), Thomas just
      forgot the "/ 2" there while cleaning up.
      Signed-off-by: default avatarChen Gong <gong.chen@linux.intel.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@amd64.org
      Cc: tony.luck@intel.com
      Link: http://lkml.kernel.org/r/1338863702-9245-1-git-send-email-gong.chen@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      958fb3c5
  2. 05 Jun, 2012 2 commits
  3. 04 Jun, 2012 12 commits
  4. 03 Jun, 2012 3 commits
    • Linus Torvalds's avatar
      vfs: move inode stat information closer together · 2f9d3df8
      Linus Torvalds authored
      The comment above it says "Stat data, not accessed from path walking",
      but in fact some of inode fields we use for the common stat data was way
      down at the end of the inode, causing unnecessary cache misses for the
      common stat operations.
      
      The inode structure is pretty big, and this can change padding depending
      on field width, but at least on the common 64-bit configurations this
      doesn't change the size.  Some of our inode layout has historically been
      to tro to avoid unnecessary padding fields, but cache locality is at
      least as important for layout, if not more.
      
      Noticed by looking at kernel profiles, and noticing that the "i_blkbits"
      access stood out like a sore thumb.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f9d3df8
    • Linus Torvalds's avatar
      Linux 3.5-rc1 · f8f5701b
      Linus Torvalds authored
      f8f5701b
    • Linus Torvalds's avatar
      Merge tag 'dm-3.5-changes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm · 912afc36
      Linus Torvalds authored
      Pull device-mapper updates from Alasdair G Kergon:
       "Improve multipath's retrying mechanism in some defined circumstances
        and provide a simple reserve/release mechanism for userspace tools to
        access thin provisioning metadata while the pool is in use."
      
      * tag 'dm-3.5-changes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
        dm thin: provide userspace access to pool metadata
        dm thin: use slab mempools
        dm mpath: allow ioctls to trigger pg init
        dm mpath: delay retry of bypassed pg
        dm mpath: reduce size of struct multipath
      912afc36
  5. 02 Jun, 2012 18 commits
  6. 01 Jun, 2012 1 commit
    • Linus Torvalds's avatar
      Merge tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6 · 804ce986
      Linus Torvalds authored
      Pull fbdev updates from Florian Tobias Schandinat:
       - driver for AUO-K1900 and AUO-K1901 epaper controller
       - large updates for OMAP (e.g. decouple HDMI audio and video)
       - some updates for Exynos and SH Mobile
       - various other small fixes and cleanups
      
      * tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits)
        video: bfin_adv7393fb: Fix cleanup code
        video: exynos_dp: reduce delay time when configuring video setting
        video: exynos_dp: move sw reset prioir to enabling sw defined function
        video: exynos_dp: use devm_ functions
        fb: handle NULL pointers in framebuffer release
        OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
        OMAPDSS: Apply VENC timings even if panel is disabled
        OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
        OMAPDSS: DISPC: Support rotation through TILER
        OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
        OMAPFB: remove compiler warnings when CONFIG_BUG=n
        OMAPDSS: remove compiler warnings when CONFIG_BUG=n
        OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
        OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
        OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
        OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
        drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
        video: exynos mipi dsi: support reverse panel type
        video: exynos mipi dsi: Properly interpret the interrupt source flags
        video: exynos mipi dsi: Avoid races in probe()
        ...
      804ce986