1. 05 1月, 2011 4 次提交
    • H
      x86, NMI: Add touch_nmi_watchdog to io_check_error delay · 74d91e3c
      Huang Ying 提交于
      Prevent the long delay in io_check_error making NMI watchdog
      timeout.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      LKML-Reference: <1294198689-15447-3-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      74d91e3c
    • D
      x86: Avoid calling arch_trigger_all_cpu_backtrace() at the same time · 554ec063
      Dongdong Deng 提交于
      The spin_lock_debug/rcu_cpu_stall detector uses
      trigger_all_cpu_backtrace() to dump cpu backtrace.
      Therefore it is possible that trigger_all_cpu_backtrace()
      could be called at the same time on different CPUs, which
      triggers and 'unknown reason NMI' warning. The following case
      illustrates the problem:
      
            CPU1                    CPU2                     ...   CPU N
                             trigger_all_cpu_backtrace()
                             set "backtrace_mask" to cpu mask
                                     |
      generate NMI interrupts  generate NMI interrupts       ...
          \                          |                               /
           \                         |                              /
      
      The "backtrace_mask" will be cleaned by the first NMI interrupt
      at nmi_watchdog_tick(), then the following NMI interrupts
      generated by other cpus's arch_trigger_all_cpu_backtrace() will
      be taken as unknown reason NMI interrupts.
      
      This patch uses a test_and_set to avoid the problem, and stop
      the arch_trigger_all_cpu_backtrace() from calling to avoid
      dumping a double cpu backtrace info when there is already a
      trigger_all_cpu_backtrace() in progress.
      Signed-off-by: NDongdong Deng <dongdong.deng@windriver.com>
      Reviewed-by: NBruce Ashfield <bruce.ashfield@windriver.com>
      Cc: fweisbec@gmail.com
      LKML-Reference: <1294198689-15447-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      554ec063
    • D
      x86: Only call smp_processor_id in non-preempt cases · 9ab181fa
      Don Zickus 提交于
      There are some paths that walk the die_chain with preemption on.
      Make sure we are in an NMI call before we start doing anything.
      
      This was triggered by do_general_protection calling notify_die
      with DIE_GPF.
      Reported-by: NJan Kiszka <jan.kiszka@web.de>
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      LKML-Reference: <1294198689-15447-1-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9ab181fa
    • Y
      x86: Fix APIC ID sizing bug on larger systems, clean up MAX_APICS confusion · cb2ded37
      Yinghai Lu 提交于
      Found one x2apic pre-enabled system, x2apic_mode suddenly get
      corrupted after register some cpus, when compiled
      CONFIG_NR_CPUS=255 instead of 512.
      
      It turns out that generic_processor_info() ==> phyid_set(apicid,
      phys_cpu_present_map) causes the problem.
      
      phys_cpu_present_map is sized by MAX_APICS bits, and pre-enabled
      system some cpus have an apic id > 255.
      
      The variable after phys_cpu_present_map may get corrupted
      silently:
      
       ffffffff828e8420 B phys_cpu_present_map
       ffffffff828e8440 B apic_verbosity
       ffffffff828e8444 B local_apic_timer_c2_ok
       ffffffff828e8448 B disable_apic
       ffffffff828e844c B x2apic_mode
       ffffffff828e8450 B x2apic_disabled
       ffffffff828e8454 B num_processors
       ...
      
      Actually phys_cpu_present_map is referenced via apic id, instead
      index. We should use MAX_LOCAL_APIC instead MAX_APICS.
      
      For 64-bit it will be 32768 in all cases. BSS will increase by 4k bytes
      on 64-bit:
      
      	text		data		bss		dec		filename
      	21696943	4193748		12787712	38678403	vmlinux.before
      	21696943	4193748		12791808	38682499	vmlinux.after
      
      No change on 32bit.
      
      Finally we can remove MAX_APCIS that was rather confusing.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      LKML-Reference: <4D23BD9C.3070102@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cb2ded37
  2. 04 1月, 2011 5 次提交
  3. 03 1月, 2011 1 次提交
    • R
      arch/x86/oprofile/op_model_amd.c: Perform initialisation on a single CPU · c7c25802
      Robert Richter 提交于
      Disable preemption in init_ibs(). The function only checks the
      ibs capabilities and sets up pci devices (if necessary). It runs
      only on one cpu but operates with the local APIC and some MSRs,
      thus it is better to disable preemption.
      
      [    7.034377] BUG: using smp_processor_id() in preemptible [00000000] code: modprobe/483
      [    7.034385] caller is setup_APIC_eilvt+0x155/0x180
      [    7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-20101110+ #1
      [    7.034392] Call Trace:
      [    7.034400]  [<ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0
      [    7.034404]  [<ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180
      [ ... ]
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812
      
      Reported-by: <atswartz@gmail.com>
      Signed-off-by: NRobert Richter <robert.richter@amd.com>
      Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Dan Carpenter <error27@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <stable@kernel.org>         [2.6.37.x]
      LKML-Reference: <20110103111514.GM4739@erda.amd.com>
      [ small cleanups ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c7c25802
  4. 02 1月, 2011 1 次提交
  5. 30 12月, 2010 3 次提交
  6. 29 12月, 2010 1 次提交
  7. 28 12月, 2010 1 次提交
    • C
      x86, paravirt: Use native_halt on a halt, not native_safe_halt · c8217b83
      Cliff Wickman 提交于
      halt() should use native_halt()
      safe_halt() uses native_safe_halt()
      
      If CONFIG_PARAVIRT=y, halt() is defined in arch/x86/include/asm/paravirt.h as
      
      static inline void halt(void)
      {
              PVOP_VCALL0(pv_irq_ops.safe_halt);
      }
      
      Otherwise (no CONFIG_PARAVIRT) halt() in arch/x86/include/asm/irqflags.h is
      
      static inline void halt(void)
      {
              native_halt();
      }
      
      So it looks to me like the CONFIG_PARAVIRT case of using native_safe_halt()
      for a halt() is an oversight.
      Am I missing something?
      
      It probably hasn't shown up as a problem because the local apic is disabled
      on a shutdown or restart.  But if we disable interrupts and call halt()
      we shouldn't expect that the halt() will re-enable interrupts.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      LKML-Reference: <E1PSBcz-0001g1-FM@eag09.americas.sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c8217b83
  8. 27 12月, 2010 1 次提交
    • J
      x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree() · 5cdd2de0
      Jesper Juhl 提交于
      In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
      we have  this:
      
      	while (leftover) {
      		...
      		if (get_ucode_data(mc, ucode_ptr, mc_size) ||
      		    microcode_sanity_check(mc) < 0) {
      			vfree(mc);
      			break;
      		}
      		...
      	}
      
      	if (mc)
      		vfree(mc);
      
      This will cause a double free of 'mc'. This patch fixes that by
      just  removing the vfree() call in the loop since 'mc' will be
      freed nicely just  after we break out of the loop.
      
      There's also a second change in the patch. I noticed a lot of
      checks for  pointers being NULL before passing them to vfree().
      That's completely  redundant since vfree() deals gracefully with
      being passed a NULL pointer.  Removing the redundant checks
      yields a nice size decrease for the object  file.
      
      Size before the patch:
         text    data     bss     dec     hex filename
         4578     240    1032    5850    16da arch/x86/kernel/microcode_intel.o
      Size after the patch:
         text    data     bss     dec     hex filename
         4489     240     984    5713    1651 arch/x86/kernel/microcode_intel.o
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Acked-by: NTigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Shaohua Li <shaohua.li@intel.com>
      LKML-Reference: <alpine.LNX.2.00.1012251946100.10759@swampdragon.chaosbits.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cdd2de0
  9. 24 12月, 2010 2 次提交
    • Y
      x86, acpi: Parse all SRAT cpu entries even above the cpu number limitation · d3bd0588
      Yinghai Lu 提交于
      Recent Intel new system have different order in MADT, aka will list all thread0
      at first, then all thread1.
      But SRAT table still old order, it will list cpus in one socket all together.
      
      If the user have compiled limited NR_CPUS or boot with nr_cpus=, could have missed
      to put some cpus apic id to node mapping into apicid_to_node[].
      
      for example for 4 sockets system with 64 cpus with nr_cpus=32 will get crash...
      
      [    9.106288] Total of 32 processors activated (136190.88 BogoMIPS).
      [    9.235021] divide error: 0000 [#1] SMP
      [    9.235315] last sysfs file:
      [    9.235481] CPU 1
      [    9.235592] Modules linked in:
      [    9.245398]
      [    9.245478] Pid: 2, comm: kthreadd Not tainted 2.6.37-rc1-tip-yh-01782-ge92ef79-dirty #274      /Sun Fire x4800
      [    9.265415] RIP: 0010:[<ffffffff81075a8f>]  [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
      ...
      [    9.645938] RIP  [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
      [    9.665356]  RSP <ffff88103f8d1c40>
      [    9.665568] ---[ end trace 2296156d35fdfc87 ]---
      
      So let just parse all cpu entries in SRAT.
      
      Also add apicid checking with MAX_LOCAL_APIC, in case We could out of boundaries of
      apicid_to_node[].
      
      it fixes following bug too.
      https://bugzilla.kernel.org/show_bug.cgi?id=22662
      
      -v2: expand to 32bit according to hpa
         need to add MAX_LOCAL_APIC for 32bit
      Reported-and-Tested-by: NWu Fengguang <fengguang.wu@intel.com>
      Reported-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Tested-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D0AD486.9020704@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      d3bd0588
    • Y
      x86, acpi: Add MAX_LOCAL_APIC for 32bit · 56d91f13
      Yinghai Lu 提交于
      We should use MAX_LOCAL_APIC for max apic ids and MAX_APICS as number
      of local apics.
      
      Also apic_version[] array should use MAX_LOCAL_APICs.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <4D0AD464.2020408@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      56d91f13
  10. 23 12月, 2010 1 次提交
    • D
      x86, nmi_watchdog: Remove ARCH_HAS_NMI_WATCHDOG and rely on CONFIG_HARDLOCKUP_DETECTOR · 4a7863cc
      Don Zickus 提交于
      The x86 arch has shifted its use of the nmi_watchdog from a
      local implementation to the global one provide by
      kernel/watchdog.c.  This shift has caused a whole bunch of
      compile problems under different config options.  I attempt to
      simplify things with the patch below.
      
      In order to simplify things, I had to come to terms with the
      meaning of two terms ARCH_HAS_NMI_WATCHDOG and
      CONFIG_HARDLOCKUP_DETECTOR.  Basically they mean the same thing,
      the former on a local level and the latter on a global level.
      
      With the old x86 nmi watchdog gone, there is no need to rely on
      defining the ARCH_HAS_NMI_WATCHDOG variable because it doesn't
      make sense any more.  x86 will now use the global
      implementation.
      
      The changes below do a few things.  First it changes the few
      places that relied on ARCH_HAS_NMI_WATCHDOG to use
      CONFIG_X86_LOCAL_APIC (the former was an alias for the latter
      anyway, so nothing unusual here).  Those pieces of code were
      relying more on local apic functionality the nmi watchdog
      functionality, so the change should make sense.
      
      Second, I removed the x86 implementation of
      touch_nmi_watchdog().  It isn't need now, instead x86 will rely
      on kernel/watchdog.c's implementation.
      
      Third, I removed the #define ARCH_HAS_NMI_WATCHDOG itself from
      x86.  And tweaked the include/linux/nmi.h file to tell users to
      look for an externally defined touch_nmi_watchdog in the case of
      ARCH_HAS_NMI_WATCHDOG _or_ CONFIG_HARDLOCKUP_DETECTOR. This
      changes removes some of the ugliness in that file.
      
      Finally, I added a Kconfig dependency for
      CONFIG_HARDLOCKUP_DETECTOR that said you can't have
      ARCH_HAS_NMI_WATCHDOG _and_ CONFIG_HARDLOCKUP_DETECTOR.  You can
      only have one nmi_watchdog.
      
      Tested with
      ARCH=i386: allnoconfig, defconfig, allyesconfig, (various broken
      configs) ARCH=x86_64: allnoconfig, defconfig, allyesconfig,
      (various broken configs)
      
      Hopefully, after this patch I won't get any more compile broken
      emails. :-)
      
      v3:
        changed a couple of 'linux/nmi.h' -> 'asm/nmi.h' to pick-up correct function
        prototypes when CONFIG_HARDLOCKUP_DETECTOR is not set.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: fweisbec@gmail.com
      LKML-Reference: <1293044403-14117-1-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4a7863cc
  11. 22 12月, 2010 2 次提交
  12. 19 12月, 2010 2 次提交
  13. 18 12月, 2010 8 次提交
  14. 17 12月, 2010 5 次提交
  15. 16 12月, 2010 3 次提交