1. 17 1月, 2009 1 次提交
  2. 15 1月, 2009 1 次提交
    • I
      fix: crash: IP: __bitmap_intersects+0x48/0x73 · 5cd73762
      Ingo Molnar 提交于
      -tip testing found this crash:
      
      > [   35.258515] calling  acpi_cpufreq_init+0x0/0x127 @ 1
      > [   35.264127] BUG: unable to handle kernel NULL pointer dereference at (null)
      > [   35.267554] IP: [<ffffffff80478092>] __bitmap_intersects+0x48/0x73
      > [   35.267554] PGD 0
      > [   35.267554] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c is still broken: there's no
      allocation of the variable mask, so we pass in an uninitialized cmd.mask
      field to drv_read(), which then passes it to the scheduler which then
      crashes ...
      
      Switch it over to the much simpler constant-cpumask-pointers approach.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5cd73762
  3. 13 1月, 2009 1 次提交
    • I
      Revert "cpumask: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write" · 50c668d6
      Ingo Molnar 提交于
      This reverts commit 7503bfba.
      
      Dieter Ries reported bootup soft-hangs and bisected it back to
      this commit, and reverting this commit gave him a working system.
      
      The commit introduces work_on_cpu() use into the cpufreq code,
      but that is subtly problematic from a lock hierarchy POV: the
      hotplug-cpu lock is an highlevel lock that is taken before
      lowlevel locks, and in this codepath we are called with the
      policy lock taken.
      
      Dieter did not have lockdep enabled so we dont have a nice stack
      trace proof for this, but using work_on_cpu() in such a lowlevel
      place certainly looks wrong, so we revert the patch.
      
      work_on_cpu() needs to be reworked to be more generally usable.
      Reported-by: NDieter Ries <clip2@gmx.de>
      Tested-by: NDieter Ries <clip2@gmx.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      50c668d6
  4. 12 1月, 2009 2 次提交
  5. 09 1月, 2009 1 次提交
  6. 07 1月, 2009 1 次提交
    • L
      x86: fix section mismatch warnings in mcheck/mce_amd_64.c · 51d7a139
      Leonardo Potenza 提交于
      Mark the function local_allocate_threshold_blocks() with __cpuinit,
      in order to remove the following section mismatch messages:
      
      WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x1363): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      WARNING: arch/x86/kernel/cpu/built-in.o(.text+0x1def): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0xef2b): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      All the callsites of this function are __cpuinit already, and all the
      functions it calls are __cpuinit as well.
      Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      51d7a139
  7. 06 1月, 2009 5 次提交
  8. 05 1月, 2009 1 次提交
  9. 04 1月, 2009 4 次提交
  10. 31 12月, 2008 2 次提交
  11. 29 12月, 2008 1 次提交
  12. 26 12月, 2008 1 次提交
  13. 25 12月, 2008 1 次提交
    • F
      tracing/ftrace: don't trace on early stage of a secondary cpu boot, v3 · 0ca59dd9
      Frederic Weisbecker 提交于
      Impact: fix a crash/hard-reboot on certain configs while enabling cpu runtime
      
      On some archs, the boot of a secondary cpu can have an early fragile state.
      On x86-64, the pda is not initialized on the first stage of a cpu boot but
      it is needed to get the cpu number and the current task pointer. This data
      is needed during tracing. As they were dereferenced at this stage, we got a
      crash while tracing a cpu being enabled at runtime.
      
      Some other archs like ia64 can have such kind of issue too.
      
      Changes on v2:
      
      We dropped the previous solution of a per-arch called function to guess the
      current state of a cpu. That could slow down the tracing.
      
      This patch removes the -pg flag on arch/x86/kernel/cpu/common.c where
      the low level cpu boot functions exist, on start_secondary() and a helper
      function used at this stage.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0ca59dd9
  14. 20 12月, 2008 1 次提交
  15. 19 12月, 2008 1 次提交
  16. 17 12月, 2008 5 次提交
  17. 13 12月, 2008 1 次提交
    • R
      cpumask: change cpumask_scnprintf, cpumask_parse_user, cpulist_parse, and... · 29c0177e
      Rusty Russell 提交于
      cpumask: change cpumask_scnprintf, cpumask_parse_user, cpulist_parse, and cpulist_scnprintf to take pointers.
      
      Impact: change calling convention of existing cpumask APIs
      
      Most cpumask functions started with cpus_: these have been replaced by
      cpumask_ ones which take struct cpumask pointers as expected.
      
      These four functions don't have good replacement names; fortunately
      they're rarely used, so we just change them over.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: paulus@samba.org
      Cc: mingo@redhat.com
      Cc: tony.luck@intel.com
      Cc: ralf@linux-mips.org
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: cl@linux-foundation.org
      Cc: srostedt@redhat.com
      29c0177e
  18. 12 12月, 2008 1 次提交
  19. 06 12月, 2008 5 次提交
  20. 30 11月, 2008 1 次提交
  21. 26 11月, 2008 2 次提交
    • A
      tracing: add "power-tracer": C/P state tracer to help power optimization · f3f47a67
      Arjan van de Ven 提交于
      Impact: new "power-tracer" ftrace plugin
      
      This patch adds a C/P-state ftrace plugin that will generate
      detailed statistics about the C/P-states that are being used,
      so that we can look at detailed decisions that the C/P-state
      code is making, rather than the too high level "average"
      that we have today.
      
      An example way of using this is:
      
       mount -t debugfs none /sys/kernel/debug
       echo cstate > /sys/kernel/debug/tracing/current_tracer
       echo 1 > /sys/kernel/debug/tracing/tracing_enabled
       sleep 1
       echo 0 > /sys/kernel/debug/tracing/tracing_enabled
       cat /sys/kernel/debug/tracing/trace | perl scripts/trace/cstate.pl > out.svg
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f3f47a67
    • A
      [CPUFREQ] powernow-k8: ignore out-of-range PstateStatus value · a266d9f1
      Andreas Herrmann 提交于
      A workaround for AMD CPU family 11h erratum 311 might cause that the
      P-state Status Register shows a "current P-state" which is larger than
      the "current P-state limit" in P-state Current Limit Register. For the
      wrong P-state value there is no ACPI _PSS object defined and
      powernow-k8/cpufreq can't determine the proper CPU frequency for that
      state.
      
      As a consequence this can cause a panic during boot (potentially with
      all recent kernel versions -- at least I have reproduced it with
      various 2.6.27 kernels and with the current .28 series), as an
      example:
      
      powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \
      )
      powernow-k8:    0 : pstate 0 (2200 MHz)
      powernow-k8:    1 : pstate 1 (1100 MHz)
      powernow-k8:    2 : pstate 2 (600 MHz)
      BUG: unable to handle kernel paging request at ffff88086e7528b8
      IP: [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
      PGD 202063 PUD 0
      Oops: 0002 [#1] SMP
      last sysfs file:
      CPU 1
      Modules linked in:
      Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16
      RIP: 0010:[<ffffffff80486361>]  [<ffffffff80486361>] cpufreq_stats_update+0x4a/0\
      f
      Synaptics claims to have extended capabilities, but I'm not able to read them.<6\
      6
      RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0
      RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c
      RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080
      R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10
      R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000
      Unable to initialize Synaptics hardware.
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0)
      Stack:
       ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7
       ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000
       ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10
      Call Trace:
       [<ffffffff804863c7>] ? cpufreq_stat_notifier_trans+0x51/0x83
       [<ffffffff8024b46c>] ? notifier_call_chain+0x29/0x4c
       [<ffffffff8024b561>] ? __srcu_notifier_call_chain+0x46/0x61
       [<ffffffff8048496d>] ? cpufreq_notify_transition+0x93/0xa9
       [<ffffffff8021ab8d>] ? powernowk8_target+0x1e8/0x5f3
       [<ffffffff80486687>] ? cpufreq_governor_performance+0x1b/0x20
       [<ffffffff80484886>] ? __cpufreq_governor+0x71/0xa8
       [<ffffffff80484b21>] ? __cpufreq_set_policy+0x101/0x13e
       [<ffffffff80485bcd>] ? cpufreq_add_dev+0x3f0/0x4cd
       [<ffffffff8048577a>] ? handle_update+0x0/0x8
       [<ffffffff803c2062>] ? sysdev_driver_register+0xb6/0x10d
       [<ffffffff8056592c>] ? powernowk8_init+0x0/0x7e
       [<ffffffff8048604c>] ? cpufreq_register_driver+0x8f/0x140
       [<ffffffff80209056>] ? _stext+0x56/0x14f
       [<ffffffff802c2234>] ? proc_register+0x122/0x17d
       [<ffffffff802c23a0>] ? create_proc_entry+0x73/0x8a
       [<ffffffff8025c259>] ? register_irq_proc+0x92/0xaa
       [<ffffffff8025c2c8>] ? init_irq_proc+0x57/0x69
       [<ffffffff807fc85f>] ? kernel_init+0x116/0x169
       [<ffffffff8020cc79>] ? child_rip+0xa/0x11
       [<ffffffff807fc749>] ? kernel_init+0x0/0x169
       [<ffffffff8020cc6f>] ? child_rip+0x0/0x11
      Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\
      
      RIP  [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
       RSP <ffff88006fb83b20>
      CR2: ffff88086e7528b8
      ---[ end trace 0678bac75e67a2f7 ]---
      Kernel panic - not syncing: Attempted to kill init!
      
      In short, aftereffect of the wrong P-state is that
      cpufreq_stats_update() uses "-1" as index for some array in
      
      cpufreq_stats_update (unsigned int cpu)
      {
      ...
           if (stat->time_in_state)
                      stat->time_in_state[stat->last_index] =
                              cputime64_add(stat->time_in_state[stat->last_index],
                                            cputime_sub(cur_time, stat->last_time));
      ...
      }
      
      Fortunately, the wrong P-state value is returned only if the core is
      in P-state 0. This fix solves the problem by detecting the
      out-of-range P-state, ignoring it, and using "0" instead.
      
      Cc: Mark Langsdorf <mark.langsdorf@amd.com>
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NDave Jones <davej@redhat.com>
      a266d9f1
  22. 23 11月, 2008 1 次提交
    • H
      x86: hypervisor - fix sparse warnings · 4e42ebd5
      Hannes Eder 提交于
      Impact: fix sparse build warning
      
      Fix the following sparse warnings:
      
        arch/x86/kernel/cpu/hypervisor.c:37:15: warning: symbol
        'get_hypervisor_tsc_freq' was not declared. Should it be static?
        arch/x86/kernel/cpu/hypervisor.c:53:16: warning: symbol
        'init_hypervisor' was not declared. Should it be static?
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Cc: "Alok N Kataria" <akataria@vmware.com>
      Cc: "Dan Hecht" <dhecht@vmware.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4e42ebd5