1. 20 7月, 2010 1 次提交
  2. 08 7月, 2010 2 次提交
  3. 17 6月, 2010 1 次提交
    • V
      x86: Look for IA32_ENERGY_PERF_BIAS support · 23016bf0
      Venkatesh Pallipadi 提交于
      The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
      hardware a hint whether OS policy favors more power saving,
      or more performance.  This allows the OS to have some influence
      on internal hardware power/performance tradeoffs where the OS
      has previously had no influence.
      
      The support for this feature is indicated by CPUID.06H.ECX.bit3,
      as documented in the Intel Architectures Software Developer's Manual.
      
      This patch discovers support of this feature and displays it
      as "epb" in /proc/cpuinfo.
      Signed-off-by: NVenkatesh Pallipadi <venki@google.com>
      LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      23016bf0
  4. 10 6月, 2010 3 次提交
  5. 03 6月, 2010 1 次提交
    • I
      xen: ensure timer tick is resumed even on CPU driving the resume · cd52e17e
      Ian Campbell 提交于
      The core suspend/resume code is run from stop_machine on CPU0 but
      parts of the suspend/resume machinery (including xen_arch_resume) are
      run on whichever CPU happened to schedule the xenwatch kernel thread.
      
      As part of the non-core resume code xen_arch_resume is called in order
      to restart the timer tick on non-boot processors. The boot processor
      itself is taken care of by core timekeeping code.
      
      xen_arch_resume uses smp_call_function which does not call the given
      function on the current processor. This means that we can end up with
      one CPU not receiving timer ticks if the xenwatch thread happened to
      be scheduled on CPU > 0.
      
      Use on_each_cpu instead of smp_call_function to ensure the timer tick
      is resumed everywhere.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Stable Kernel <stable@kernel.org> # .32.x
      cd52e17e
  6. 02 6月, 2010 1 次提交
    • B
      x86, smpboot: Fix cores per node printing on boot · 4adc8b71
      Borislav Petkov 提交于
      Percpu initialization happens now after booting the cores on the
      machine and this causes them all to be displayed as belonging to
      node 0:
      
      Jun  8 05:57:21 kepek kernel: [    0.106999] Booting Node   0,
      Processors  #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 Ok.
      
      Use early_cpu_to_node() to get the correct node of each core
      instead.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Mike Travis <travis@sgi.com>
      LKML-Reference: <20100601190455.GA14237@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4adc8b71
  7. 01 6月, 2010 2 次提交
  8. 31 5月, 2010 3 次提交
    • A
      x86/mm: Remove unused DBG() macro · e565813a
      Akinobu Mita 提交于
      DBG() macro for CONFIG_DEBUG_PER_CPU_MAPS is unused.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      LKML-Reference: <1274706291-13554-1-git-send-email-akinobu.mita@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e565813a
    • S
      perf_events: Fix event scheduling issues introduced by transactional API · 90151c35
      Stephane Eranian 提交于
      The transactional API patch between the generic and model-specific
      code introduced several important bugs with event scheduling, at
      least on X86. If you had pinned events, e.g., watchdog,  and were
      over-committing the PMU, you would get bogus counts. The bug was
      showing up on Intel CPU because events would move around more
      often that on AMD. But the problem also existed on AMD, though
      harder to expose.
      
      The issues were:
      
       - group_sched_in() was missing a cancel_txn() in the error path
      
       - cpuc->n_added was not properly maintained, leading to missing
         actions in hw_perf_enable(), i.e., n_running being 0. You cannot
         update n_added until you know the transaction has succeeded. In
         case of failed transaction n_added was not adjusted back.
      
       - in case of failed transactions, event_sched_out() was called
         and eventually invoked x86_disable_event() to touch the HW reg.
         But with transactions, on X86, event_sched_in() does not touch
         HW registers, it simply collects events into a list. Thus, you
         could end up calling x86_disable_event() on a counter which
         did not correspond to the current event when idx != -1.
      
      The patch modifies the generic and X86 code to avoid all those problems.
      
      First, we keep track of the number of events added last. In case the
      transaction fails, we substract them from n_added. This approach is
      necessary (as opposed to delaying updates to n_added) because not all
      event updates use the transaction API, e.g., single events.
      
      Second, we encapsulate the event_sched_in() and event_sched_out() in
      group_sched_in() inside the transaction. That makes the operations
      symmetrical and you can also detect that you are inside a transaction
      and skip the HW reg access by checking cpuc->group_flag.
      
      With this patch, you can now overcommit the PMU even with pinned
      system-wide events present and still get valid counts.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1274796225.5882.1389.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      90151c35
    • L
      Revert "cpusets: randomize node rotor used in cpuset_mem_spread_node()" · 35926ff5
      Linus Torvalds 提交于
      This reverts commit 0ac0c0d0, which
      caused cross-architecture build problems for all the wrong reasons.
      IA64 already added its own version of __node_random(), but the fact is,
      there is nothing architectural about the function, and the original
      commit was just badly done. Revert it, since no fix is forthcoming.
      Requested-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      35926ff5
  9. 28 5月, 2010 11 次提交
  10. 27 5月, 2010 2 次提交
  11. 26 5月, 2010 3 次提交
    • L
      Revert "endian: #define __BYTE_ORDER" · 13da9e20
      Linus Torvalds 提交于
      This reverts commit b3b77c8c, which was
      also totally broken (see commit 0d2daf5c that reverted the crc32
      version of it).  As reported by Stephen Rothwell, it causes problems on
      big-endian machines:
      
      > In file included from fs/jfs/jfs_types.h:33,
      >                  from fs/jfs/jfs_incore.h:26,
      >                  from fs/jfs/file.c:22:
      > fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined
      
      The kernel has never had that crazy "__BYTE_ORDER == __LITTLE_ENDIAN"
      model.  It's not how we do things, and it isn't how we _should_ do
      things.  So don't go there.
      Requested-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13da9e20
    • B
      x86, k8: Fix section mismatch for powernowk8_exit() · fe501f1e
      Borislav Petkov 提交于
      Fix the following warning:
      
      "WARNING: arch/x86/kernel/built-in.o(.exit.text+0x72):
      Section mismatch in reference from the function powernowk8_exit() to the variable .cpuinit.data:cpb_nb
      
      The function __exit powernowk8_exit() references a variable
      __cpuinitdata cpb_nb. This is often seen when error handling in the exit
      function uses functionality in the init path. The fix is often to remove
      the __cpuinitdata annotation of cpb_nb so it may be used outside an init
      section."
      
      Cc: <stable@kernel.org>
      Reported-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20100525152858.GA24836@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fe501f1e
    • K
      driver core: add devname module aliases to allow module on-demand auto-loading · 578454ff
      Kay Sievers 提交于
      This adds:
        alias: devname:<name>
      to some common kernel modules, which will allow the on-demand loading
      of the kernel module when the device node is accessed.
      
      Ideally all these modules would be compiled-in, but distros seems too
      much in love with their modularization that we need to cover the common
      cases with this new facility. It will allow us to remove a bunch of pretty
      useless init scripts and modprobes from init scripts.
      
      The static device node aliases will be carried in the module itself. The
      program depmod will extract this information to a file in the module directory:
        $ cat /lib/modules/2.6.34-00650-g537b60d1-dirty/modules.devname
        # Device nodes to trigger on-demand module loading.
        microcode cpu/microcode c10:184
        fuse fuse c10:229
        ppp_generic ppp c108:0
        tun net/tun c10:200
        dm_mod mapper/control c10:235
      
      Udev will pick up the depmod created file on startup and create all the
      static device nodes which the kernel modules specify, so that these modules
      get automatically loaded when the device node is accessed:
        $ /sbin/udevd --debug
        ...
        static_dev_create_from_modules: mknod '/dev/cpu/microcode' c10:184
        static_dev_create_from_modules: mknod '/dev/fuse' c10:229
        static_dev_create_from_modules: mknod '/dev/ppp' c108:0
        static_dev_create_from_modules: mknod '/dev/net/tun' c10:200
        static_dev_create_from_modules: mknod '/dev/mapper/control' c10:235
        udev_rules_apply_static_dev_perms: chmod '/dev/net/tun' 0666
        udev_rules_apply_static_dev_perms: chmod '/dev/fuse' 0666
      
      A few device nodes are switched to statically allocated numbers, to allow
      the static nodes to work. This might also useful for systems which still run
      a plain static /dev, which is completely unsafe to use with any dynamic minor
      numbers.
      
      Note:
      The devname aliases must be limited to the *common* and *single*instance*
      device nodes, like the misc devices, and never be used for conceptually limited
      systems like the loop devices, which should rather get fixed properly and get a
      control node for losetup to talk to, instead of creating a random number of
      device nodes in advance, regardless if they are ever used.
      
      This facility is to hide the mess distros are creating with too modualized
      kernels, and just to hide that these modules are not compiled-in, and not to
      paper-over broken concepts. Thanks! :)
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Ian Kent <raven@themaw.net>
      Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      578454ff
  12. 25 5月, 2010 8 次提交
    • C
      drivers/hwmon/coretemp.c: get TjMax value from MSR · a321cedb
      Carsten Emde 提交于
      The MSR IA32_TEMPERATURE_TARGET contains the TjMax value in the newer
      Intel processors.
      Signed-off-by: NHuaxu Wan <huaxu.wan@linux.intel.com>
      Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: Yong Wang <yong.y.wang@linux.intel.com>
      Cc: Rudolf Marek <r.marek@assembler.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a321cedb
    • J
      endian: #define __BYTE_ORDER · b3b77c8c
      Joakim Tjernlund 提交于
      Linux does not define __BYTE_ORDER in its endian header files which makes
      some header files bend backwards to get at the current endian.  Lets
      #define __BYTE_ORDER in big_endian.h/litte_endian.h to make it easier for
      header files that are used in user space too.
      
      In userspace the convention is that
      
        1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined,
        2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN.
      Signed-off-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b3b77c8c
    • P
      perf, trace: Fix !x86 build bug · 87f44bbc
      Peter Zijlstra 提交于
      Patch b7e2ecef (perf, trace: Optimize tracepoints by removing
      IRQ-disable from perf/tracepoint interaction) made the
      unfortunate mistake of assuming the world is x86 only, correct
      this.
      
      The problem was that perf_fetch_caller_regs() did
      local_save_flags() into regs->flags, and I re-used that to
      remove another local_save_flags(), forgetting !x86 doesn't have
      regs->flags.
      
      Do the reverse, remove the local_save_flags() from
      perf_fetch_caller_regs() and let the ftrace site do the
      local_save_flags() instead.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Cc: acme@redhat.com
      Cc: efault@gmx.de
      Cc: fweisbec@gmail.com
      Cc: rostedt@goodmis.org
      LKML-Reference: <1274778175.5882.623.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      87f44bbc
    • P
      x86: remove last traces of quicklist usage · 48691ff8
      Peter Zijlstra 提交于
      We still have a stray quicklist header included even though we axed
      quicklist usage quite a while back.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <201005241913.o4OJDJe9010881@imap1.linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      48691ff8
    • G
      x86, setup: Phoenix BIOS fixup is needed on Dell Inspiron Mini 1012 · 3d6e77a3
      Gabor Gombas 提交于
      The low-memory corruption checker triggers during suspend/resume, so we
      need to reserve the low 64k.  Don't be fooled that the BIOS identifies
      itself as "Dell Inc.", it's still Phoenix BIOS.
      
      [ hpa: I think we blacklist almost every BIOS in existence.  We should
      either change this to a whitelist or just make it unconditional. ]
      Signed-off-by: NGabor Gombas <gombasg@digikabel.hu>
      LKML-Reference: <201005241913.o4OJDIMM010877@imap1.linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@kernel.org>
      3d6e77a3
    • J
      x86: "nosmp" command line option should force the system into UP mode · 5f2eb550
      Jan Beulich 提交于
      Bits set in cpu_possible_mask prior to the execution of
      prefill_possible_map() (i.e.  when parsing ACPI or MPS tables) would
      prevent the SMP alternatives logic from switching to UP mode, plus
      unnecessary setup of per-CPU data for CPUs that can never come online.
      
      Additionally, without CONFIG_HOTPLUG_CPU disabled CPUs can never come
      online, and hence setting cpu_possible_mask bits for them is again a
      simple waste of resources.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      LKML-Reference: <201005241913.o4OJDH3Z010874@imap1.linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5f2eb550
    • J
      arch/x86/pci: use kasprintf · b46fc5f2
      Julia Lawall 提交于
      kasprintf combines kmalloc and sprintf, and takes care of the size
      calculation itself.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression a,flag;
      expression list args;
      statement S;
      @@
      
        a =
      -  \(kmalloc\|kzalloc\)(...,flag)
      +  kasprintf(flag,args)
        <... when != a
        if (a == NULL || ...) S
        ...>
      - sprintf(a,args);
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      LKML-Reference: <201005241913.o4OJDG3R010871@imap1.linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      b46fc5f2
    • K
      x86, apic: ack all pending irqs when crashed/on kexec · 8c3ba8d0
      Kerstin Jonsson 提交于
      When the SMP kernel decides to crash_kexec() the local APICs may have
      pending interrupts in their vector tables.
      
      The setup routine for the local APIC has a deficient mechanism for
      clearing these interrupts, it only handles interrupts that has already
      been dispatched to the local core for servicing (the ISR register) safely,
      it doesn't consider lower prioritized queued interrupts stored in the IRR
      register.
      
      If you have more than one pending interrupt within the same 32 bit word in
      the LAPIC vector table registers you may find yourself entering the IO
      APIC setup with pending interrupts left in the LAPIC.  This is a situation
      for wich the IO APIC setup is not prepared.  Depending of what/which
      interrupt vector/vectors are stuck in the APIC tables your system may show
      various degrees of malfunctioning.  That was the reason why the
      check_timer() failed in our system, the timer interrupts was blocked by
      pending interrupts from the old kernel when routed trough the IO APIC.
      
      Additional comment from Jiri Bohac:
      ==============
      If this should go into stable release,
      I'd add some kind of limit on the number of iterations, just to be safe from
      hard to debug lock-ups:
      
      +if (loops++  > MAX_LOOPS) {
      +        printk("LAPIC pending clean-up")
      +        break;
      +}
       while (queued);
      
      with MAX_LOOPS something like 1E9 this would leave plenty of time for the
      pending IRQs to be cleared and would and still cause at most a second of delay
      if the loop were to lock-up for whatever reason.
      
      [trenn@suse.de:
      
      V2: Use tsc if avail to bail out after 1 sec due to possible virtual
          apic_read calls which may take rather long (suggested by: Avi Kivity
          <avi@redhat.com>) If no tsc is available bail out quickly after
          cpu_khz, if we broke out too early and still have irqs pending (which
          should never happen?) we still get a WARN_ON...
      
      V3: - Fixed indentation -> checkpatch clean
          - max_loops must be signed
      
      V4: - Fix typo, mixed up tsc and ntsc in first rdtscll() call
      
      V5: Adjust WARN_ON() condition to also catch error in cpu_has_tsc case]
      
      Cc: <jbohac@novell.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Tested-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      LKML-Reference: <201005241913.o4OJDGWM010865@imap1.linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      8c3ba8d0
  13. 23 5月, 2010 1 次提交
  14. 22 5月, 2010 1 次提交