1. 11 9月, 2009 1 次提交
  2. 09 9月, 2009 1 次提交
    • T
      dmi: extend dmi_get_year() to dmi_get_date() · 3e5cd1f2
      Tejun Heo 提交于
      There are cases where full date information is required instead of
      just the year.  Add month and day parsing to dmi_get_year() and rename
      it to dmi_get_date().
      
      As the original function only required '/' followed by any number of
      parseable characters at the end of the string, keep that behavior to
      avoid upsetting existing users.
      
      The new function takes dates of format [mm[/dd]]/yy[yy].  Year, month
      and date are checked to be in the ranges of [1-9999], [1-12] and
      [1-31] respectively and any invalid or out-of-range component is
      returned as zero.
      
      The dummy implementation is updated accordingly but the return value
      is updated to indicate field not found which is consistent with how
      other dummy functions behave.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      3e5cd1f2
  3. 08 9月, 2009 1 次提交
  4. 06 9月, 2009 2 次提交
  5. 05 9月, 2009 1 次提交
    • H
      x86, msr: change msr-reg.o to obj-y, and export its symbols · b19ae399
      H. Peter Anvin 提交于
      Change msr-reg.o to obj-y (it will be included in virtually every
      kernel since it is used by the initialization code for AMD processors)
      and add a separate C file to export its symbols to modules, so that
      msr.ko can use them; on uniprocessors we bypass the helper functions
      in msr.o and use the accessor functions directly via inlines.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <20090904140834.GA15789@elte.hu>
      Cc: Borislav Petkov <petkovbb@googlemail.com>
      b19ae399
  6. 04 9月, 2009 14 次提交
    • P
      kmemleak: Don't scan uninitialized memory when kmemcheck is enabled · 8e019366
      Pekka Enberg 提交于
      Ingo Molnar reported the following kmemcheck warning when running both
      kmemleak and kmemcheck enabled:
      
        PM: Adding info for No Bus:vcsa7
        WARNING: kmemcheck: Caught 32-bit read from uninitialized memory
        (f6f6e1a4)
        d873f9f600000000c42ae4c1005c87f70000000070665f666978656400000000
         i i i i u u u u i i i i i i i i i i i i i i i i i i i i i u u u
                 ^
      
        Pid: 3091, comm: kmemleak Not tainted (2.6.31-rc7-tip #1303) P4DC6
        EIP: 0060:[<c110301f>] EFLAGS: 00010006 CPU: 0
        EIP is at scan_block+0x3f/0xe0
        EAX: f40bd700 EBX: f40bd780 ECX: f16b46c0 EDX: 00000001
        ESI: f6f6e1a4 EDI: 00000000 EBP: f10f3f4c ESP: c2605fcc
         DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
        CR0: 8005003b CR2: e89a4844 CR3: 30ff1000 CR4: 000006f0
        DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
        DR6: ffff4ff0 DR7: 00000400
         [<c110313c>] scan_object+0x7c/0xf0
         [<c1103389>] kmemleak_scan+0x1d9/0x400
         [<c1103a3c>] kmemleak_scan_thread+0x4c/0xb0
         [<c10819d4>] kthread+0x74/0x80
         [<c10257db>] kernel_thread_helper+0x7/0x3c
         [<ffffffff>] 0xffffffff
        kmemleak: 515 new suspected memory leaks (see
        /sys/kernel/debug/kmemleak)
        kmemleak: 42 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
      
      The problem here is that kmemleak will scan partially initialized
      objects that makes kmemcheck complain. Fix that up by skipping
      uninitialized memory regions when kmemcheck is enabled.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      8e019366
    • I
      sched: Turn on SD_BALANCE_NEWIDLE · 840a0653
      Ingo Molnar 提交于
      Start the re-tuning of the balancer by turning on newidle.
      
      It improves hackbench performance and parallelism on a 4x4 box.
      The "perf stat --repeat 10" measurements give us:
      
        domain0             domain1
        .......................................
       -SD_BALANCE_NEWIDLE -SD_BALANCE_NEWIDLE:
         2041.273208  task-clock-msecs         #      9.354 CPUs    ( +-   0.363% )
      
       +SD_BALANCE_NEWIDLE -SD_BALANCE_NEWIDLE:
         2086.326925  task-clock-msecs         #     11.934 CPUs    ( +-   0.301% )
      
       +SD_BALANCE_NEWIDLE +SD_BALANCE_NEWIDLE:
         2115.289791  task-clock-msecs         #     12.158 CPUs    ( +-   0.263% )
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      840a0653
    • I
      sched: Clean up topology.h · 47734f89
      Ingo Molnar 提交于
      Re-organize the flag settings so that it's visible at a glance
      which sched-domains flags are set and which not.
      
      With the new balancer code we'll need to re-tune these details
      anyway, so make it cleaner to make fewer mistakes down the
      road ;-)
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47734f89
    • Y
      x86: Use hard_smp_processor_id() to get apic id for AMD K8 cpus · 0d96b9ff
      Yinghai Lu 提交于
      Otherwise, system with apci id lifting will have wrong apicid in
      /proc/cpuinfo.
      
      and use that in srat_detect_node().
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      LKML-Reference: <4A998CCA.1040407@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0d96b9ff
    • M
      x86, perf_counter, bts: Do not allow kernel BTS tracing for now · 1653192f
      markus.t.metzger@intel.com 提交于
      Kernel BTS tracing generates too much data too fast for us to
      handle, causing the kernel to hang.
      
      Fail for BTS requests for kernel code.
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Acked-by: NPeter Zijlstra <a.p.zjilstra@chello.nl>
      LKML-Reference: <20090902140616.901253000@intel.com>
      [ This is really a workaround - but we want BTS tracing in .32
        so make sure we dont regress. The lockup should be fixed
        ASAP. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1653192f
    • M
      x86, perf_counter, bts: Correct pointer-to-u64 casts · 596da17f
      markus.t.metzger@intel.com 提交于
      On 32bit, pointers in the DS AREA configuration are cast to
      u64. The current (long) cast to avoid compiler warnings results
      in a signed 64bit address.
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20090902140615.305889000@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      596da17f
    • M
      x86, perf_counter, bts: Fail if BTS is not available · 747b50aa
      markus.t.metzger@intel.com 提交于
      Reserve PERF_COUNT_HW_BRANCH_INSTRUCTIONS with sample_period ==
      1 for BTS tracing and fail, if BTS is not available.
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20090902140612.943801000@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      747b50aa
    • J
      x86/i386: Put aligned stack-canary in percpu shared_aligned section · 53f82452
      Jeremy Fitzhardinge 提交于
      Pack aligned things together into a special section to minimize
      padding holes.
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Tejun Heo <tj@kernel.org>
      LKML-Reference: <4AA035C0.9070202@goop.org>
      [ queued up in tip:x86/asm because it depends on this commit:
        x86/i386: Make sure stack-protector segment base is cache aligned ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      53f82452
    • A
      x86, sched: Workaround broken sched domain creation for AMD Magny-Cours · 5a925b42
      Andreas Herrmann 提交于
      Current sched domain creation code can't handle multi-node processors.
      When switching to power_savings scheduling errors show up and
      system might hang later on (due to broken sched domain hierarchy):
      
        # echo 0  >> /sys/devices/system/cpu/sched_mc_power_savings
        CPU0 attaching sched-domain:
         domain 0: span 0-5 level MC
          groups: 0 1 2 3 4 5
          domain 1: span 0-23 level NODE
           groups: 0-5 6-11 18-23 12-17
        ...
        # echo 1  >> /sys/devices/system/cpu/sched_mc_power_savings
        CPU0 attaching sched-domain:
         domain 0: span 0-11 level MC
          groups: 0 1 2 3 4 5 6 7 8 9 10 11
        ERROR: parent span is not a superset of domain->span
          domain 1: span 0-5 level CPU
        ERROR: domain->groups does not contain CPU0
           groups: 6-11 (__cpu_power = 12288)
        ERROR: groups don't span domain->span
           domain 2: span 0-23 level NODE
            groups:
        ERROR: domain->cpu_power not set
      
        ERROR: groups don't span domain->span
        ...
      
      Fixing all aspects of power-savings scheduling for Magny-Cours needs
      some larger changes in the sched domain creation code.
      
      As a short-term and temporary workaround avoid the problems by
      extending "the worst possible hack" ;-(
      and always use llc_shared_map on AMD Magny-Cours when MC domain span
      is calculated.
      
      With this I get:
      
        # echo 1  >> /sys/devices/system/cpu/sched_mc_power_savings
        CPU0 attaching sched-domain:
         domain 0: span 0-5 level MC
          groups: 0 1 2 3 4 5
          domain 1: span 0-5 level CPU
           groups: 0-5 (__cpu_power = 6144)
           domain 2: span 0-23 level NODE
            groups: 0-5 (__cpu_power = 6144) 6-11 (__cpu_power = 6144) 18-23 (__cpu_power = 6144) 12-17 (__cpu_power = 6144)
        ...
      
      I.e. no errors during sched domain creation, no system hangs, and also
      mc_power_savings scheduling works to a certain extend.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      5a925b42
    • A
      x86, mcheck: Use correct cpumask for shared bank4 · cb9805ab
      Andreas Herrmann 提交于
      This fixes threshold_bank4 support on multi-node processors.
      
      The correct mask to use is llc_shared_map, representing an internal
      node on Magny-Cours.
      
      We need to create 2 sets of symlinks for sibling shared banks -- one
      set for each internal node, symlinks of each set should target the
      first core on same internal node.
      
      Currently only one set is created where all symlinks are targeting
      the first core of the entire socket.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      cb9805ab
    • A
      x86, cacheinfo: Fixup L3 cache information for AMD multi-node processors · a326e948
      Andreas Herrmann 提交于
      L3 cache size, associativity and shared_cpu information need to be
      adapted to show information for an internal node instead of the
      entire physical package.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      a326e948
    • A
      x86: Fix CPU llc_shared_map information for AMD Magny-Cours · 4a376ec3
      Andreas Herrmann 提交于
      Construct entire NodeID and use it as cpu_llc_id. Thus internal node
      siblings are stored in llc_shared_map.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      4a376ec3
    • J
      x86/i386: Make sure stack-protector segment base is cache aligned · 1ea0d14e
      Jeremy Fitzhardinge 提交于
      The Intel Optimization Reference Guide says:
      
      	In Intel Atom microarchitecture, the address generation unit
      	assumes that the segment base will be 0 by default. Non-zero
      	segment base will cause load and store operations to experience
      	a delay.
      		- If the segment base isn't aligned to a cache line
      		  boundary, the max throughput of memory operations is
      		  reduced to one [e]very 9 cycles.
      	[...]
      	Assembly/Compiler Coding Rule 15. (H impact, ML generality)
      	For Intel Atom processors, use segments with base set to 0
      	whenever possible; avoid non-zero segment base address that is
      	not aligned to cache line boundary at all cost.
      
      We can't avoid having a non-zero base for the stack-protector
      segment, but we can make it cache-aligned.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <4AA01893.6000507@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ea0d14e
    • I
      x86, msr: Fix msr-reg.S compilation with gas 2.16.1, on 32-bit too · 8adf65cf
      Ingo Molnar 提交于
      The macro was defined in the 32-bit path as well - breaking the
      build on 32-bit platforms:
      
        arch/x86/lib/msr-reg.S: Assembler messages:
        arch/x86/lib/msr-reg.S:53: Error: Bad macro parameter list
        arch/x86/lib/msr-reg.S:100: Error: invalid character '_' in mnemonic
        arch/x86/lib/msr-reg.S:101: Error: invalid character '_' in mnemonic
      
      Cc: Borislav Petkov <petkovbb@googlemail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <tip-f6909f39@git.kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8adf65cf
  7. 03 9月, 2009 20 次提交