1. 21 4月, 2009 1 次提交
    • J
      x86/uv: fix for no memory at paddr 0 · fc61e663
      Jack Steiner 提交于
      Fix endcase where the memory at physical address 0 does not really
      exist AND one of the sockets on blade 0 has no active cpus.
      
      The memory that _appears_ to be at physical address 0 is actually
      memory that located at a different address but has been remapped by
      the chipset so that it appears to be at physical address 0.
      
      When determining the UV pnode, the algorithm for determining the pnode
      incorrectly used the relocated physical address instead of the actual
      (global) address.
      
      [ Impact: boot failure on partitioned systems ]
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090420132530.GA23156@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fc61e663
  2. 18 4月, 2009 1 次提交
    • J
      x86/uv: fix init of cpu-less nodes · 27229ca6
      Jack Steiner 提交于
      Fix an endcase in the UV initialization code for the "UV large system mode"
      of apicids.  If node zero contains no cpus, cpus on another node will be the
      boot cpu.  The percpu data that contains the extra apicid bits was not
      being initialized early enough.
      
      [ Impact: fix potential boot crash on cpu-less UV nodes ]
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090417142447.GA23759@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27229ca6
  3. 17 4月, 2009 2 次提交
    • D
      x86: fix microcode driver newly spewing warnings · 0917798d
      Dmitry Adamushko 提交于
      Jeff Garzik reported this WARN_ON() noise:
      
      > Kernel: 2.6.30-rc1-00306-g8371f87c
      > Hardware: ICH10 x86-64
      >
      > This is a regression from 2.6.29.  Microcode spews the following WARNING
      > multiple times during boot:
      >
      > ------------[ cut here ]------------
      > WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xeb/0xf0()
      > Hardware name:         sysfs group ffffffffa0209700 not found for
      >  kobject 'cpu0'
      
      Keep sysfs files around for cpus even when we failed to locate
      microcode for them at the moment of module loading. The appropriate
      microcode firmware can become available later on.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0917798d
    • C
      x86: UV BAU distribution and payload MMRs · 4ea3c51d
      Cliff Wickman 提交于
      This patch correctly sets BAU memory mapped registers to point
      to the sending activation descriptor table and target payload table.
      
      The "Broadcast Assist Unit" is used for TLB shootdown in UV.
      
      The memory mapped registers that point to sending and receiving
      memory structures contain node numbers.
      
      In one case the __pa() function did not provide the node id of
      memory on blade zero in configurations where that id is nonzero.
      In another case, it was assumed that memory was allocated on
      the local node.  That assumption is not true in a configuration
      in which the node has no memory.
      
      Tested on the UV hardware simulator.
      
      [ Impact: fix possible runtime crash due to incorrect TLB logic ]
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      LKML-Reference: <E1LuR5Z-0007An-B8@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4ea3c51d
  4. 15 4月, 2009 3 次提交
    • L
      acpi-cpufreq: fix 'smp_call_function_many()' confusion · ea34f43a
      Linus Torvalds 提交于
      It turns out that 'smp_call_function_many()' doesn't work at all like
      'smp_call_function_single()', and my change to Andrew's patch to use it
      rather than a loop over all CPU's acpi-cpufreq doesn't work.
      
      My bad.
      
      'smp_call_function_many()' has two "features" (aka "documented bugs"):
      
       (a) it needs to be called with preemption disabled, because it uses
           smp_processor_id() without guarding the CPU lookup with 'get_cpu()'
           and 'put_cpu()' like the 'single' variant does.
      
       (b) even if the current CPU is part of the CPU mask, it won't do the
           call on that CPU.
      
      Still, we're better off trying to use 'smp_call_function_many()' than
      looping over CPU's, since it at least in theory allows us to use a
      broadcast IPI and do it all in parallel.  So let's just work around the
      silly semantic bugs in that function.
      Reported-and-tested-by: NAli Gholami Rudi <ali@rudi.ir>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>,
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea34f43a
    • H
      x86 microcode: revert some work_on_cpu · 6f66cbc6
      Hugh Dickins 提交于
      Revert part of af5c820a ("x86: cpumask:
      use work_on_cpu in arch/x86/kernel/microcode_core.c")
      
      That change is causing only one Intel CPU's microcode to be updated e.g.
      microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22
      where before it announced that also for CPU0 and CPU1 and CPU2.
      
      We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code,
      because Intel's request_microcode_user() involves a copy_from_user() from
      /sbin/microcode_ctl, which therefore needs to be on that CPU at the time.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f66cbc6
    • C
      x86: UV: BAU partition-relative distribution map · 94ca8e48
      Cliff Wickman 提交于
      This patch enables each partition's BAU distribution bit map
      to be partition-relative.
      
      The distribution bitmap had been constructed assuming 0 as the base
      node number.  That construct would not have allowed a total system of
      greater than 256 nodes.
      It also corrects an error that occurred when the first blade's nasid
      was not zero.  That nasid was stored as the base node.
      The base node number gets added by hardware to the node numbers implied
      in the distribution bitmap, resulting in invalid target nasids.
      
      Tested on the UV hardware simulator.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      LKML-Reference: <E1Ltl0C-0004Ob-37@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      94ca8e48
  5. 14 4月, 2009 3 次提交
  6. 12 4月, 2009 2 次提交
  7. 10 4月, 2009 1 次提交
    • W
      x86, intr-remap: fix eoi for interrupt remapping without x2apic · 746cddd3
      Weidong Han 提交于
      To simplify level irq migration in the presence of interrupt-remapping,
      Suresh used a virtual vector (io-apic pin number) to eliminate io-apic
      RTE modification. Level triggered interrupt will appear as an edge to
      the local apic cpu but still as level to the IO-APIC. So in addition to
      do the local apic EOI, it still needs to do IO-APIC directed EOI to clear
      the remote IRR bit in the IO-APIC RTE. Pls refer to Suresh's patch for
      more details (commit 0280f7c4).
      
      Now interrupt remapping is decoupled from x2apic, it also needs to do the
      directed EOI for apic. Otherwise, apic interrupts won't work correctly.
      Signed-off-by: NWeidong Han <weidong.han@intel.com>
      Cc: iommu@lists.linux-foundation.org
      Cc: Weidong Han <weidong.han@intel.com>
      Cc: suresh.b.siddha@intel.com
      Cc: dwmw2@infradead.org
      Cc: allen.m.kay@intel.com
      LKML-Reference: <1239355037-22856-1-git-send-email-weidong.han@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      746cddd3
  8. 09 4月, 2009 3 次提交
    • J
      x86: cpu_debug remove execute permission · f20ab9c3
      Jaswinder Singh Rajput 提交于
      It seems by mistake these files got execute permissions so removing it.
      Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      LKML-Reference: <1239211186.9037.2.camel@ht.satnam>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f20ab9c3
    • F
      tracing/syscalls: use a dedicated file header · 47788c58
      Frederic Weisbecker 提交于
      Impact: fix build warnings and possibe compat misbehavior on IA64
      
      Building a kernel on ia64 might trigger these ugly build warnings:
      
      CC      arch/ia64/ia32/sys_ia32.o
      In file included from arch/ia64/ia32/sys_ia32.c:55:
      arch/ia64/ia32/ia32priv.h:290:1: warning: "elf_check_arch" redefined
      In file included from include/linux/elf.h:7,
                       from include/linux/module.h:14,
                       from include/linux/ftrace.h:8,
                       from include/linux/syscalls.h:68,
                       from arch/ia64/ia32/sys_ia32.c:18:
      arch/ia64/include/asm/elf.h:19:1: warning: this is the location of the previous definition
      [...]
      
      sys_ia32.c includes linux/syscalls.h which in turn includes linux/ftrace.h
      to import the syscalls tracing prototypes.
      
      But including ftrace.h can pull too much things for a low level file,
      especially on ia64 where the ia32 private headers conflict with higher
      level headers.
      
      Now we isolate the syscall tracing headers in their own lightweight file.
      Reported-by: NTony Luck <tony.luck@intel.com>
      Tested-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: "Frank Ch. Eigler" <fche@redhat.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Jiaying Zhang <jiayingz@google.com>
      Cc: Michael Rubin <mrubin@google.com>
      Cc: Martin Bligh <mbligh@google.com>
      Cc: Michael Davidson <md@google.com>
      LKML-Reference: <20090408184058.GB6017@nowhere>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47788c58
    • H
      x86: smarten /proc/interrupts output for new counters · 59d13812
      Hidetoshi Seto 提交于
      Now /proc/interrupts of tip tree has new counters:
      
        PLT: Platform interrupts
      
      Format change of output, as like that by commit:
      
        commit 7a81d9a7
        x86: smarten /proc/interrupts output
      
      should be applied to these new counters too.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Jan Beulich <jbeulich@novell.com>
      LKML-Reference: <49C98DEA.8060208@jp.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      59d13812
  9. 08 4月, 2009 6 次提交
  10. 07 4月, 2009 5 次提交
  11. 04 4月, 2009 9 次提交
  12. 03 4月, 2009 4 次提交
    • G
      preadv/pwritev: Add preadv and pwritev system calls. · f3554f4b
      Gerd Hoffmann 提交于
      This patch adds preadv and pwritev system calls.  These syscalls are a
      pretty straightforward combination of pread and readv (same for write).
      They are quite useful for doing vectored I/O in threaded applications.
      Using lseek+readv instead opens race windows you'll have to plug with
      locking.
      
      Other systems have such system calls too, for example NetBSD, check
      here: http://www.daemon-systems.org/man/preadv.2.html
      
      The application-visible interface provided by glibc should look like
      this to be compatible to the existing implementations in the *BSD family:
      
        ssize_t preadv(int d, const struct iovec *iov, int iovcnt, off_t offset);
        ssize_t pwritev(int d, const struct iovec *iov, int iovcnt, off_t offset);
      
      This prototype has one problem though: On 32bit archs is the (64bit)
      offset argument unaligned, which the syscall ABI of several archs doesn't
      allow to do.  At least s390 needs a wrapper in glibc to handle this.  As
      we'll need a wrappers in glibc anyway I've decided to push problem to
      glibc entriely and use a syscall prototype which works without
      arch-specific wrappers inside the kernel: The offset argument is
      explicitly splitted into two 32bit values.
      
      The patch sports the actual system call implementation and the windup in
      the x86 system call tables.  Other archs follow as separate patches.
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <linux-api@vger.kernel.org>
      Cc: <linux-arch@vger.kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f3554f4b
    • J
      sgi-gru: add macros for using the UV hub to send interrupts · 66666e50
      Jack Steiner 提交于
      Add macros for using the UV hub to send interrupts.  Change the IPI code
      to use these macros.  These macros will also be used in additional patches
      that will follow.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      66666e50
    • O
      signals: remove 'handler' parameter to tracehook functions · 43918f2b
      Oleg Nesterov 提交于
      Container-init must behave like global-init to processes within the
      container and hence it must be immune to unhandled fatal signals from
      within the container (i.e SIG_DFL signals that terminate the process).
      
      But the same container-init must behave like a normal process to processes
      in ancestor namespaces and so if it receives the same fatal signal from a
      process in ancestor namespace, the signal must be processed.
      
      Implementing these semantics requires that send_signal() determine pid
      namespace of the sender but since signals can originate from workqueues/
      interrupt-handlers, determining pid namespace of sender may not always be
      possible or safe.
      
      This patchset implements the design/simplified semantics suggested by
      Oleg Nesterov.  The simplified semantics for container-init are:
      
      	- container-init must never be terminated by a signal from a
      	  descendant process.
      
      	- container-init must never be immune to SIGKILL from an ancestor
      	  namespace (so a process in parent namespace must always be able
      	  to terminate a descendant container).
      
      	- container-init may be immune to unhandled fatal signals (like
      	  SIGUSR1) even if they are from ancestor namespace. SIGKILL/SIGSTOP
      	  are the only reliable signals to a container-init from ancestor
      	  namespace.
      
      This patch:
      
      Based on an earlier patch submitted by Oleg Nesterov and comments from
      Roland McGrath (http://lkml.org/lkml/2008/11/19/258).
      
      The handler parameter is currently unused in the tracehook functions.
      Besides, the tracehook functions are called with siglock held, so the
      functions can check the handler if they later need to.
      
      Removing the parameter simiplifies changes to sig_ignored() in a follow-on
      patch.
      Signed-off-by: NSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Acked-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Daniel Lezcano <daniel.lezcano@free.fr>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      43918f2b
    • A
      Simplify copy_thread() · 6f2c55b8
      Alexey Dobriyan 提交于
      First argument unused since 2.3.11.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f2c55b8