1. 16 12月, 2009 18 次提交
  2. 15 12月, 2009 6 次提交
  3. 14 12月, 2009 5 次提交
  4. 13 12月, 2009 1 次提交
  5. 12 12月, 2009 3 次提交
    • M
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis 提交于
      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: NMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
    • M
      x86: Remove enabling x2apic message for every CPU · 450b1e8d
      Mike Travis 提交于
      Print only once that the system is supporting x2apic mode.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <4B226E92.5080904@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      450b1e8d
    • B
      x86, msr: Add support for non-contiguous cpumasks · 50542251
      Borislav Petkov 提交于
      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: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20091211171440.GD31998@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      50542251
  6. 11 12月, 2009 7 次提交
    • J
      kgdb,x86: do not set kgdb_single_step on x86 · 8097551d
      Jason Wessel 提交于
      On an SMP system the kgdb_single_step flag has the possibility to
      indefinitely hang the system in the case.  Consider the case where,
      CPU 1 has the schedule lock and CPU 0 is set to single step, there is
      no way for CPU 0 to run another task.
      
      The easy way to observe the problem is to make 2 cpus busy, and run
      the kgdb test suite.  You will see that it hangs the system very
      quickly.
      
      while [ 1 ] ; do find /proc > /dev/null 2>&1 ; done &
      while [ 1 ] ; do find /proc > /dev/null 2>&1 ; done &
      echo V1 > /sys/module/kgdbts/parameters/kgdbts
      
      The side effect of this patch is that there is the possibility
      to miss a breakpoint in the case that a single step operation
      was executed to step over a breakpoint in common code.
      
      The trade off of the missed breakpoint is preferred to
      hanging the kernel.  This can be fixed in the future by
      using kprobes or another strategy to step over planted
      breakpoints with out of line execution.
      
      CC: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      8097551d
    • J
      kgdb,i386: Fix corner case access to ss with NMI watch dog exception · cf6f196d
      Jason Wessel 提交于
      It is possible for the user_mode_vm(regs) check to return true on the
      i368 arch for a non master kgdb cpu or when the master kgdb cpu
      handles the NMI watch dog exception.
      
      The solution is simply to select the correct gdb_ss location
      based on the check to user_mode_vm(regs).
      
      CC: Ingo Molnar <mingo@elte.hu>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      cf6f196d
    • R
      kgdb,x86: remove redundant test · a5d09d68
      Roel Kluin 提交于
      The for loop starts with a breakno of 0, and ends when it's 4. so
      this test is always true.
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      a5d09d68
    • A
      Unify sys_mmap* · f8b72560
      Al Viro 提交于
      New helper - sys_mmap_pgoff(); switch syscalls to using it.
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f8b72560
    • Y
      x86: Use find_e820() instead of hard coded trampoline address · 893f38d1
      Yinghai Lu 提交于
      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: NJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Tested-by: NJens Axboe <jens.axboe@oracle.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <4B21630A.6000308@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      893f38d1
    • P
      x86, AMD: Fix stale cpuid4_info shared_map data in shared_cpu_map cpumasks · ebb682f5
      Prarit Bhargava 提交于
      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: NPrarit Bhargava <prarit@redhat.com>
      LKML-Reference: <20091209183336.17855.98708.sendpatchset@prarit.bos.redhat.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ebb682f5
    • C
      x86, perf events: Check if we have APIC enabled · 12558038
      Cyrill Gorcunov 提交于
      Ralf Hildebrandt reported this boot warning:
      
      | Running a vanilla 2.6.32 as Xen DomU, I'm getting:
      |
      | [    0.000999] CPU: Physical Processor ID: 0
      | [    0.000999] CPU: Processor Core ID: 1
      | [    0.000999] Performance Events: AMD PMU driver.
      | [    0.000999] ------------[ cut here ]------------
      | [    0.000999] WARNING: at arch/x86/kernel/apic/apic.c:249 native_apic_write_dummy
      
      So we need to check if APIC functionality is available, and
      not just in the P6 driver but elsewhere as well.
      Reported-by: NRalf Hildebrandt <Ralf.Hildebrandt@charite.de>
      Signed-off-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20091210165634.GF5086@lenovo>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      12558038