1. 24 11月, 2009 1 次提交
  2. 14 11月, 2009 3 次提交
    • I
      x86: Fix cpu_devs[] initialization in early_cpu_init() · 31c997ca
      Ingo Molnar 提交于
      Yinghai Lu noticed that this commit:
      
        0388423d: x86: Minimise printk spew from per-vendor init code
      
      mistakenly left out the initialization of cpu_devs[] in the
      !PROCESSOR_SELECT case. Fix it.
      Reported-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Dave Jones <davej@redhat.com>
      LKML-Reference: <20091113203000.GA19160@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      31c997ca
    • R
      x86: Remove CPU cache size output for non-Intel too · b01c845f
      Roland Dreier 提交于
      As Dave Jones said about the output in intel_cacheinfo.c: "They
      aren't useful, and pollute the dmesg output a lot (especially on
      machines with many cores).  Also the same information can be
      trivially found out from userspace."
      
      Give the generic display_cacheinfo() function the same treatment.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Acked-by: NDave Jones <davej@redhat.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <adaocn6dp99.fsf_-_@roland-alpha.cisco.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b01c845f
    • D
      x86: Minimise printk spew from per-vendor init code · 0388423d
      Dave Jones 提交于
      In the default case where the kernel supports all CPU vendors,
      we currently print out a bunch of not useful messages on every
      system.
      
      32-bit:
      KERNEL supported cpus:
        Intel GenuineIntel
        AMD AuthenticAMD
        NSC Geode by NSC
        Cyrix CyrixInstead
        Centaur CentaurHauls
        Transmeta GenuineTMx86
        Transmeta TransmetaCPU
        UMC UMC UMC UMC
      
      64-bit:
      KERNEL supported cpus:
        Intel GenuineIntel
        AMD AuthenticAMD
        Centaur CentaurHauls
      
      Given that "what CPUs does the kernel support" isn't useful for
      the "support everything" case, we can suppress these printk's.
      Signed-off-by: NDave Jones <davej@redhat.com>
      LKML-Reference: <20091113203000.GA19160@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0388423d
  3. 13 11月, 2009 1 次提交
    • D
      x86: Remove the CPU cache size printk's · 15cd8812
      Dave Jones 提交于
      They aren't really useful, and they pollute the dmesg output a lot
      (especially on machines with many cores).
      
      Also the same information can be trivially found out from
      userspace.
      Reported-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Roland Dreier <rdreier@cisco.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Jack Steiner <steiner@sgi.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20091112231542.GA7129@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      15cd8812
  4. 16 10月, 2009 1 次提交
    • R
      x86: Don't print number of MCE banks for every CPU · 93ae5012
      Roland Dreier 提交于
      The MCE initialization code explicitly says it doesn't handle
      asymmetric configurations where different CPUs support different
      numbers of MCE banks, and it prints a big warning in that case.
      
      Therefore, printing the "mce: CPU supports <x> MCE banks"
      message into the kernel log for every CPU is pure redundancy
      that clutters the log significantly for systems with lots of
      CPUs.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      LKML-Reference: <adaeip473qt.fsf@cisco.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      93ae5012
  5. 12 10月, 2009 1 次提交
  6. 03 10月, 2009 1 次提交
    • A
      x86: Simplify bound checks in the MTRR code · 11879ba5
      Arjan van de Ven 提交于
      The current bound checks for copy_from_user in the MTRR driver are
      not as obvious as they could be, and gcc agrees with that.
      
      This patch simplifies the boundary checks to the point that gcc can
      now prove to itself that the copy_from_user() is never going past
      its bounds.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090926205150.30797709@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11879ba5
  7. 02 10月, 2009 1 次提交
    • I
      x86: EDAC: MCE: Fix MCE decoding callback logic · f436f8bb
      Ingo Molnar 提交于
      Make decoding of MCEs happen only on AMD hardware by registering a
      non-default callback only on CPU families which support it.
      
      While looking at the interaction of decode_mce() with the other MCE
      code i also noticed a few other things and made the following
      cleanups/fixes:
      
       - Fixed the mce_decode() weak alias - a weak alias is really not
         good here, it should be a proper callback. A weak alias will be
         overriden if a piece of code is built into the kernel - not
         good, obviously.
      
       - The patch initializes the callback on AMD family 10h and 11h.
      
       - Added the more correct fallback printk of:
      
      	No support for human readable MCE decoding on this CPU type.
      	Transcribe the message and run it through 'mcelog --ascii' to decode.
      
         On CPUs that dont have a decoder.
      
       - Made the surrounding code more readable.
      
      Note that the callback allows us to have a default fallback -
      without having to check the CPU versions during the printout
      itself. When an EDAC module registers itself, it can install the
      decode-print function.
      
      (there's no unregister needed as this is core code.)
      
      version -v2 by Borislav Petkov:
      
       - add K8 to the set of supported CPUs
      
       - always build in edac_mce_amd since we use an early_initcall now
      
       - fix checkpatch warnings
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      LKML-Reference: <20091001141432.GA11410@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f436f8bb
  8. 30 9月, 2009 1 次提交
  9. 24 9月, 2009 1 次提交
    • I
      x86: mce: Use safer ways to access MCE registers · 11868a2d
      Ingo Molnar 提交于
      Use rdmsrl_safe() when accessing MCE registers. While in
      theory we always 'know' which ones are safe to access from
      the capability bits, there's a lot of hardware variations
      and reality might differ from theory, as it did in this case:
      
         http://bugzilla.kernel.org/show_bug.cgi?id=14204
      
      [    0.010016] mce: CPU supports 5 MCE banks
      [    0.011029] general protection fault: 0000 [#1]
      [    0.011998] last sysfs file:
      [    0.011998] Modules linked in:
      [    0.011998]
      [    0.011998] Pid: 0, comm: swapper Not tainted (2.6.31_router #1) HP Vectra
      [    0.011998] EIP: 0060:[<c100d9b9>] EFLAGS: 00010246 CPU: 0
      [    0.011998] EIP is at mce_rdmsrl+0x19/0x60
      [    0.011998] EAX: 00000000 EBX: 00000001 ECX: 00000407 EDX: 08000000
      [    0.011998] ESI: 00000000 EDI: 8c000000 EBP: 00000405 ESP: c17d5eac
      
      So WARN_ONCE() instead of crashing the box.
      
      ( also fix a number of stylistic inconsistencies in the code. )
      
      Note, we might still crash in wrmsrl() if we get that far, but
      we shouldnt if the registers are truly inaccessible.
      Reported-by: NGNUtoo <GNUtoo@no-log.org>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <bug-14204-5438@http.bugzilla.kernel.org/>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11868a2d
  10. 23 9月, 2009 2 次提交
    • P
      perf_event, x86: Fix 'perf sched record' crashing the machine · 7d428966
      Peter Zijlstra 提交于
      Chris Malley reported that 'perf sched record' sometimes
      crashes his box with:
      
      [  389.272175] BUG: unable to handle kernel paging request at ffffb300
      [  389.272294] IP: [<c011b0bd>] default_send_IPI_self+0x1d/0x50
      [  389.272366] *pde = 0073f067 *pte = 00000000
      [  389.274708] Call Trace:
      [  389.274752]  [<c010e3b4>] ?  set_perf_event_pending+0x14/0x20
      [  389.274801]  [<c01b9751>] ?  perf_output_unlock+0x121/0x1a0
      [  389.274848]  [<c01b981a>] ? perf_output_end+0x4a/0x70
      [  389.274893]  [<c01ba690>] ?  __perf_event_overflow+0x240/0x2f0
      [  389.274942]  [<c030963e>] ? atomic64_cmpxchg+0x1e/0x30
      [  389.274988]  [<c01ba8f4>] ?  perf_swevent_ctx_event+0x1b4/0x1c0
      [  389.275035]  [<c01ba773>] ?  perf_swevent_ctx_event+0x33/0x1c0
      [  389.275081]  [<c01ba9a7>] ? do_perf_sw_event+0xa7/0x160
      [  389.275127]  [<c01baae2>] ? perf_tp_event+0x82/0xa0
      [  389.275174]  [<c012e9c6>] ?  ftrace_profile_sched_stat_runtime+0xe6/0x120
      [  389.275224]  [<c012e8e0>] ?  ftrace_profile_sched_stat_runtime+0x0/0x120
      [  389.275273]  [<c013c85a>] ? update_curr+0x18a/0x230
      [  389.275318]  [<c013cdc5>] ?  put_prev_task_fair+0x155/0x160
      [  389.275366]  [<c01618b5>] ? sched_clock_cpu+0xd5/0x110
      [  389.275413]  [<c04e7525>] ? _spin_lock_irq+0x45/0x50
      [  389.275458]  [<c04e424e>] ? schedule+0x20e/0xb10
      
      The problem is that the box has no lapic enabled:
      
        [    0.042445] Local APIC not detected. Using dummy APIC emulation.
      
      The below seems like the best fix. We disabled all lapic bits, except
      the self-IPI-resend logic.
      Reported-by: NChris Malley <mail@chrismalley.co.uk>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <7863dc4c0909221409v7893bfd3o4b590d5951a233ba@mail.gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d428966
    • H
      x86: mce, inject: Use real inject-msg in raise_local · 14c0abf1
      Huang Ying 提交于
      Current raise_local() uses a struct mce that comes from mce_write()
      as a parameter instead of the real inject-msg, so when we set
      mce.finished = 0 to clear injected MCE, the real inject stays
      valid.
      
      This will cause the remaining inject-msg affect the next injection,
      which is not desired.
      
      To fix this, real inject-msg is used in raise_local instead of the
      one on the stack.
      
      This patch is based on the diagnosis and the fixes by Dean Nelson.
      Reported-by: NDean Nelson <dnelson@redhat.com>
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <1253601357.15717.757.camel@yhuang-dev.sh.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      14c0abf1
  11. 22 9月, 2009 2 次提交
    • I
      x86: mce: Fix thermal throttling message storm · b417c9fd
      Ingo Molnar 提交于
      If a system switches back and forth between hot and cold mode,
      the MCE code will print a stream of critical kernel messages.
      
      Extend the throttling code to properly notice this, by
      only printing the first hot + cold transition and omitting
      the rest up to CHECK_INTERVAL (5 minutes).
      
      This way we'll only get a single incident of:
      
       [  102.356584] CPU0: Temperature above threshold, cpu clock throttled (total events = 1)
       [  102.357000] Disabling lock debugging due to kernel taint
       [  102.369223] CPU0: Temperature/speed normal
      
      Every 5 minutes. The 'total events' count tells the number of cold/hot
      transitions detected, should overheating occur after 5 minutes again:
      
      [  402.357580] CPU0: Temperature above threshold, cpu clock throttled (total events = 24891)
      [  402.358001] CPU0: Temperature/speed normal
      [  450.704142] Machine check events logged
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b417c9fd
    • I
      x86: mce: Clean up thermal throttling state tracking code · 39676840
      Ingo Molnar 提交于
      Instead of a mess of three separate percpu variables, consolidate
      the state into a single structure.
      
      Also clean up therm_throt_process(), use cleaner and more
      understandable variable names and a clearer logic.
      
      This, without changing the logic, makes the code more
      streamlined, more readable and smaller as well:
      
         text	   data	    bss	    dec	    hex	filename
         1487	    169	      4	   1660	    67c	therm_throt.o.before
         1432	    176	      4	   1612	    64c	therm_throt.o.after
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39676840
  12. 21 9月, 2009 8 次提交
    • M
      trivial: fix missing printk space in amd_k7_smp_check · 7da8b6dd
      Michael Tokarev 提交于
      This trivial patch fixes one missing space in printk.
      
      I already fixed it about half a year ago or more, but the change (in
      arch/x86/kernel/cpu/smpboot.c at that time) didn't made into
      mainline yet.
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      
      index 28e5f59..6c139ed 100644
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7da8b6dd
    • I
      perf: Tidy up after the big rename · 57c0c15b
      Ingo Molnar 提交于
       - provide compatibility Kconfig entry for existing PERF_COUNTERS .config's
      
       - provide courtesy copy of old perf_counter.h, for user-space projects
      
       - small indentation fixups
      
       - fix up MAINTAINERS
      
       - fix small x86 printout fallout
      
       - fix up small PowerPC comment fallout (use 'counter' as in register)
      Reviewed-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      57c0c15b
    • I
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar 提交于
      Bye-bye Performance Counters, welcome Performance Events!
      
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      
      User-space tooling and ABI compatibility is not affected - this patch
      should be function-invariant. (Also, defconfigs were not touched to
      keep the size down.)
      
      This patch has been generated via the following script:
      
        FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
      
        sed -i \
          -e 's/PERF_EVENT_/PERF_RECORD_/g' \
          -e 's/PERF_COUNTER/PERF_EVENT/g' \
          -e 's/perf_counter/perf_event/g' \
          -e 's/nb_counters/nb_events/g' \
          -e 's/swcounter/swevent/g' \
          -e 's/tpcounter_event/tp_event/g' \
          $FILES
      
        for N in $(find . -name perf_counter.[ch]); do
          M=$(echo $N | sed 's/perf_counter/perf_event/g')
          mv $N $M
        done
      
        FILES=$(find . -name perf_event.*)
      
        sed -i \
          -e 's/COUNTER_MASK/REG_MASK/g' \
          -e 's/COUNTER/EVENT/g' \
          -e 's/\<event\>/event_id/g' \
          -e 's/counter/event/g' \
          -e 's/Counter/Event/g' \
          $FILES
      
      ... to keep it as correct as possible. This script can also be
      used by anyone who has pending perfcounters patches - it converts
      a Linux kernel tree over to the new naming. We tried to time this
      change to the point in time where the amount of pending patches
      is the smallest: the end of the merge window.
      
      Namespace clashes were fixed up in a preparatory patch - and some
      stylistic fallout will be fixed up in a subsequent patch.
      
      ( NOTE: 'counters' are still the proper terminology when we deal
        with hardware registers - and these sed scripts are a bit
        over-eager in renaming them. I've undone some of that, but
        in case there's something left where 'counter' would be
        better than 'event' we can undo that on an individual basis
        instead of touching an otherwise nicely automated patch. )
      Suggested-by: NStephane Eranian <eranian@google.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cdd6c482
    • I
      perf_counter: Rename 'event' to event_id/hw_event · dfc65094
      Ingo Molnar 提交于
      In preparation to the renames, to avoid a namespace clash.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dfc65094
    • A
      x86: Print the hypervisor returned tsc_khz during boot · 6399c087
      Alok Kataria 提交于
      On an AMD-64 system the processor frequency that is printed during
      system boot, may be different than the tsc frequency that was
      returned by the hypervisor, due to the value returned from
      calibrate_cpu.
      
      For debugging timekeeping or other related issues it might be
      better to get the tsc_khz value returned by the hypervisor.
      
      The patch below now prints the tsc frequency that the VMware
      hypervisor returned.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1252095219.12518.13.camel@ank32.eng.vmware.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6399c087
    • H
      x86/i386: Remove duplicated #include · efc8f741
      Huang Weiyi 提交于
      Remove duplicated #include in:
      
        arch/x86/kernel/cpu/common.c
      Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      efc8f741
    • J
      x86, mtrr: Convert loop to a while based construct, avoid naked semicolon · 9ff6d8e0
      Joe Perches 提交于
      Perhaps this is a more readable/standard form.
      Signed-off-by: NJoe Perches <joe@perches.com>
      LKML-Reference: <1252945687.3937.14.camel@Joe-Laptop.home>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9ff6d8e0
    • P
      perf_counter: x86: Fix PMU resource leak · a1792cda
      Peter Zijlstra 提交于
      Dave noticed that we leak the PMU resource reservations when we
      fail the hardware counter init.
      Reported-by: NDavid Miller <davem@davemloft.net>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NDavid Miller <davem@davemloft.net>
      LKML-Reference: <1252483487.7746.164.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a1792cda
  13. 20 9月, 2009 2 次提交
  14. 19 9月, 2009 2 次提交
  15. 16 9月, 2009 3 次提交
  16. 15 9月, 2009 6 次提交
  17. 04 9月, 2009 4 次提交