Skip to content
  1. Mar 13, 2009
  2. Mar 12, 2009
    • H. Peter Anvin's avatar
      x86: remove zImage support · 5e47c478
      H. Peter Anvin authored
      
      
      Impact: obsolete feature removal
      
      The zImage kernel format has been functionally unused for a very long
      time.  It is just barely possible to build a modern kernel that still
      fits within the zImage size limit, but it is highly unlikely that
      anyone ever uses it.  Furthermore, although it is still supported by
      most bootloaders, it has been at best poorly tested (or not tested at
      all); some bootloaders are even known to not support zImage at all and
      not having even noticed.
      
      Also remove some really obsolete constants that no longer have any
      meaning.
      
      LKML-Reference: <49B703D4.1000008@zytor.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      5e47c478
  3. Mar 11, 2009
  4. Mar 10, 2009
    • Dave Jones's avatar
      Revert "[CPUFREQ] Disable sysfs ui for p4-clockmod." · 129f8ae9
      Dave Jones authored
      This reverts commit e088e4c9
      
      .
      
      Removing the sysfs interface for p4-clockmod was flagged as a
      regression in bug 12826.
      
      Course of action:
       - Find out the remaining causes of overheating, and fix them
         if possible. ACPI should be doing the right thing automatically.
         If it isn't, we need to fix that.
       - mark p4-clockmod ui as deprecated
       - try again with the removal in six months.
      
      It's not really feasible to printk about the deprecation, because
      it needs to happen at all the sysfs entry points, which means adding
      a lot of strcmp("p4-clockmod".. calls to the core, which.. bleuch.
      
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      129f8ae9
  5. Mar 09, 2009
    • Rusty Russell's avatar
      lguest: fix for CONFIG_SPARSE_IRQ=y · 6db6a5f3
      Rusty Russell authored
      
      
      Impact: remove lots of lguest boot WARN_ON() when CONFIG_SPARSE_IRQ=y
      
      We now need to call irq_to_desc_alloc_cpu() before
      set_irq_chip_and_handler_name(), but we can't do that from init_IRQ (no
      kmalloc available).
      
      So do it as we use interrupts instead.  Also means we only alloc for
      irqs we use, which was the intent of CONFIG_SPARSE_IRQ anyway.
      
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@redhat.com>
      6db6a5f3
    • Rusty Russell's avatar
      lguest: fix crash 'unhandled trap 13 at <native_read_msr_safe>' · cbd88c8e
      Rusty Russell authored
      
      
      Impact: fix lguest boot crash on modern Intel machines
      
      The code in early_init_intel does:
      
      	if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
      		u64 misc_enable;
      
      		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
      
      And that rdmsr faults (not allowed from non-0 PL).  We can get around
      this by mugging the family ID part of the cpuid.  5 seems like a good
      number.
      
      Of course, this is a hack (how very lguest!).  We could just indicate
      that we don't support MSRs, or implement lguest_rdmst.
      
      Reported-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Tested-by: default avatarPatrick McHardy <kaber@trash.net>
      cbd88c8e
    • Jeremy Fitzhardinge's avatar
      x86-32: make sure virt_addr_valid() returns false for fixmap addresses · 0feca851
      Jeremy Fitzhardinge authored
      
      
      I found that virt_addr_valid() was returning true for fixmap addresses.
      
      I'm not sure whether pfn_valid() is supposed to include this test,
      but there's no harm in being explicit.
      
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B166D6.2080505@goop.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      0feca851
    • Stuart Bennett's avatar
      x86 mmiotrace: fix remove_kmmio_fault_pages() · d0fc63f7
      Stuart Bennett authored
      Impact: fix race+crash in mmiotrace
      
      The list manipulation in remove_kmmio_fault_pages() was broken. If more
      than one consecutive kmmio_fault_page was re-added during the grace
      period between unregister_kmmio_probe() and remove_kmmio_fault_pages(),
      the list manipulation failed to remove pages from the release list.
      
      After a second grace period the pages get into rcu_free_kmmio_fault_pages()
      and raise a BUG_ON() kernel crash.
      
      The list manipulation is fixed to properly remove pages from the release
      list.
      
      This bug has been present from the very beginning of mmiotrace in the
      mainline kernel. It was introduced in 0fd0e3da
      
       ("x86: mmiotrace full
      patch, preview 1");
      
      An urgent fix for Linus. Tested by Stuart (on 32-bit) and Pekka
      (on amd and intel 64-bit systems, nouveau and nvidia proprietary).
      
      Signed-off-by: default avatarStuart Bennett <stuart@freedesktop.org>
      Signed-off-by: default avatarPekka Paalanen <pq@iki.fi>
      LKML-Reference: <20090308202135.34933feb@daedalus.pq.iki.fi>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d0fc63f7
    • Yinghai Lu's avatar
      x86: fix warning about nodeid · e954ef20
      Yinghai Lu authored
      
      
      Impact: cleanup
      
      Ingo found there warning about nodeid with some configs.
      
      try to use for_each_online_node for non numa too. in that case
      nodeid will be 0.
      
      also move out boundary checking from setup_node_bootmem(), so
      non-numa config will not check it.
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <49B03069.80001@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e954ef20
    • Wang Chen's avatar
      x86: don't define __this_fixmap_does_not_exist() · 8827247f
      Wang Chen authored
      Impact: improve out-of-range fixmap index debugging
      
      Commit "1b42f516
      
      "
      defined the __this_fixmap_does_not_exist() function
      with a WARN_ON(1) in it.
      
      This causes the linker to not report an error when
      __this_fixmap_does_not_exist() is called with a
      non-constant parameter.
      
      Ingo defined __this_fixmap_does_not_exist() because he
      wanted to get virt addresses of fix memory of nest level
      by non-constant index.
      
      But we can fix this and still keep the link-time check:
      
      We can get the four slot virt addresses on link time and
      store them to array slot_virt[].
      
      Then we can then refer the slot_virt with non-constant index,
      in the ioremap-leak detection code.
      
      Signed-off-by: default avatarWang Chen <wangchen@cn.fujitsu.com>
      LKML-Reference: <49B2075B.4070509@cn.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8827247f
  6. Mar 08, 2009
    • Yinghai Lu's avatar
      x86: remove smp_apply_quirks()/smp_checks() · 1f442d70
      Yinghai Lu authored
      
      
      Impact: cleanup and code size reduction on 64-bit
      
      This code is only applied to Intel Pentium and AMD K7 32-bit cpus.
      
      Move those checks to intel_init()/amd_init() for 32-bit
      so 64-bit will not build this code.
      
      Also change to use cpu_index check to see if we need to emit warning.
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B377D2.8030108@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1f442d70
    • Cliff Wickman's avatar
      x86: UV: remove uv_flush_tlb_others() WARN_ON · 3a450de1
      Cliff Wickman authored
      
      
      In uv_flush_tlb_others() (arch/x86/kernel/tlb_uv.c),
      the "WARN_ON(!in_atomic())" fails if CONFIG_PREEMPT is not enabled.
      
      And CONFIG_PREEMPT is not enabled by default in the distribution that
      most UV owners will use.
      
      We could #ifdef CONFIG_PREEMPT the warning, but that is not good form.
      And there seems to be no suitable fix to in_atomic() when CONFIG_PREMPT
      is not on.
      
      As Ingo commented:
      
        > and we have no proper primitive to test for atomicity. (mainly
        > because we dont know about atomicity on a non-preempt kernel)
      
      So we drop the WARN_ON.
      
      Signed-off-by: default avatarCliff Wickman <cpw@sgi.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3a450de1
  7. Mar 07, 2009
    • Cyrill Gorcunov's avatar
      x86: linkage.h - guard assembler specifics by __ASSEMBLY__ · 7ab15247
      Cyrill Gorcunov authored
      Stephen Rothwell reported:
      
      |Today's linux-next build (x86_64 allmodconfig) produced this warning:
      |
      |In file included from drivers/char/epca.c:49:
      |drivers/char/digiFep1.h:7:1: warning: "GLOBAL" redefined
      |In file included from include/linux/linkage.h:5,
      |                 from include/linux/kernel.h:11,
      |                 from arch/x86/include/asm/system.h:10,
      |                 from arch/x86/include/asm/processor.h:17,
      |                 from include/linux/prefetch.h:14,
      |                 from include/linux/list.h:6,
      |                 from include/linux/module.h:9,
      |                 from drivers/char/epca.c:29:
      |arch/x86/include/asm/linkage.h:55:1: warning: this is the location of the previous definition
      |
      |Probably introduced by commit 95695547
      
      
      |("x86: asm linkage - introduce GLOBAL macro") from the x86 tree.
      
      Any assembler specific snippets being placed in headers
      are to be protected by __ASSEMBLY__. Fixed.
      
      Also move __ALIGN definition under the same protection as well.
      
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <20090306160833.GB7420@localhost>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7ab15247
  8. Mar 06, 2009
    • Markus Metzger's avatar
      x86, pebs: correct qualifier passed to ds_write_config() from ds_request_pebs() · 73bf1b62
      Markus Metzger authored
      
      
      ds_write_config() can write the BTS as well as the PEBS part of
      the DS config. ds_request_pebs() passes the wrong qualifier, which
      results in the wrong configuration to be written.
      
      Reported-by: default avatarStephane Eranian <eranian@googlemail.com>
      Signed-off-by: default avatarMarkus Metzger <markus.t.metzger@intel.com>
      LKML-Reference: <20090305085721.A22550@sedona.ch.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      73bf1b62
    • Markus Metzger's avatar
      x86, bts: remove bad warning · 9ca0791d
      Markus Metzger authored
      
      
      In case a ptraced task is reaped (while the tracer is still attached),
      ds_exit_thread() is called before ptrace_exit(). The latter will
      release the bts_tracer and remove the thread's ds_ctx.
      The former will WARN() if the context is not NULL.
      
      Oleg Nesterov submitted patches that move ptrace_exit() before
      exit_thread() and thus reverse the order of the above calls.
      
      Remove the bad warning. I will add it again when Oleg's changes are in.
      
      Signed-off-by: default avatarMarkus Metzger <markus.t.metzger@intel.com>
      LKML-Reference: <20090305084954.A22000@sedona.ch.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9ca0791d
    • Pekka Enberg's avatar
      x86: rename do_not_nx to disable_nx in mm/init_64.c · 5dd61dfa
      Pekka Enberg authored
      
      
      As a preparational step for unifying noexec handling on 32-bit and 64-bit,
      rename the do_not_nx variable to disable_nx on 64-bit.
      
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      LKML-Reference: <1236265497.31324.11.camel@penberg-laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5dd61dfa
    • Pekka Enberg's avatar
      x86: fix uninitialized variable in init_memory_mapping() · c77a3b59
      Pekka Enberg authored
      
      
      Signed-off-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      LKML-Reference: <1236265466.31324.9.camel@penberg-laptop>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c77a3b59
    • Yinghai Lu's avatar
      x86: make "memtest" like "memtest=17" · d1a8e779
      Yinghai Lu authored
      
      
      Impact: make boot command line "memtest" do one loop by default
      
      So don't need to guess many patterns in one loop.
      
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B10532.3020105@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d1a8e779
    • Tejun Heo's avatar
      x86, percpu: setup reserved percpu area for x86_64 · 6b19b0c2
      Tejun Heo authored
      
      
      Impact: fix relocation overflow during module load
      
      x86_64 uses 32bit relocations for symbol access and static percpu
      symbols whether in core or modules must be inside 2GB of the percpu
      segement base which the dynamic percpu allocator doesn't guarantee.
      This patch makes x86_64 reserve PERCPU_MODULE_RESERVE bytes in the
      first chunk so that module percpu areas are always allocated from the
      first chunk which is always inside the relocatable range.
      
      This problem exists for any percpu allocator but is easily triggered
      when using the embedding allocator because the second chunk is located
      beyond 2GB on it.
      
      This patch also changes the meaning of PERCPU_DYNAMIC_RESERVE such
      that it only indicates the size of the area to reserve for dynamic
      allocation as static and dynamic areas can be separate.  New
      PERCPU_DYNAMIC_RESERVED is increased by 4k for both 32 and 64bits as
      the reserved area separation eats away some allocatable space and
      having slightly more headroom (currently between 4 and 8k after
      minimal boot sans module area) makes sense for common case
      performance.
      
      x86_32 can address anywhere from anywhere and doesn't need reserving.
      
      Mike Galbraith first reported the problem first and bisected it to the
      embedding percpu allocator commit.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarMike Galbraith <efault@gmx.de>
      Reported-by: default avatarJaswinder Singh Rajput <jaswinder@kernel.org>
      6b19b0c2
    • Tejun Heo's avatar
      percpu, module: implement reserved allocation and use it for module percpu variables · edcb4639
      Tejun Heo authored
      
      
      Impact: add reserved allocation functionality and use it for module
      	percpu variables
      
      This patch implements reserved allocation from the first chunk.  When
      setting up the first chunk, arch can ask to set aside certain number
      of bytes right after the core static area which is available only
      through a separate reserved allocator.  This will be used primarily
      for module static percpu variables on architectures with limited
      relocation range to ensure that the module perpcu symbols are inside
      the relocatable range.
      
      If reserved area is requested, the first chunk becomes reserved and
      isn't available for regular allocation.  If the first chunk also
      includes piggy-back dynamic allocation area, a separate chunk mapping
      the same region is created to serve dynamic allocation.  The first one
      is called static first chunk and the second dynamic first chunk.
      Although they share the page map, their different area map
      initializations guarantee they serve disjoint areas according to their
      purposes.
      
      If arch doesn't setup reserved area, reserved allocation is handled
      like any other allocation.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      edcb4639
    • Tejun Heo's avatar
      x86: make embedding percpu allocator return excessive free space · 9a4f8a87
      Tejun Heo authored
      
      
      Impact: reduce unnecessary memory usage on certain configurations
      
      Embedding percpu allocator allocates unit_size *
      smp_num_possible_cpus() bytes consecutively and use it for the first
      chunk.  However, if the static area is small, this can result in
      excessive prellocated free space in the first chunk due to
      PCPU_MIN_UNIT_SIZE restriction.
      
      This patch makes embedding percpu allocator preallocate only what's
      necessary as described by PERPCU_DYNAMIC_RESERVE and return the
      leftover to the bootmem allocator.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      9a4f8a87
    • Tejun Heo's avatar
      percpu: use negative for auto for pcpu_setup_first_chunk() arguments · cafe8816
      Tejun Heo authored
      
      
      Impact: argument semantic cleanup
      
      In pcpu_setup_first_chunk(), zero @unit_size and @dyn_size meant
      auto-sizing.  It's okay for @unit_size as 0 doesn't make sense but 0
      dynamic reserve size is valid.  Alos, if arch @dyn_size is calculated
      from other parameters, it might end up passing in 0 @dyn_size and
      malfunction when the size is automatically adjusted.
      
      This patch makes both @unit_size and @dyn_size ssize_t and use -1 for
      auto sizing.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      cafe8816
  9. Mar 05, 2009