1. 26 12月, 2008 1 次提交
  2. 20 12月, 2008 2 次提交
  3. 18 12月, 2008 1 次提交
  4. 17 12月, 2008 5 次提交
  5. 15 12月, 2008 1 次提交
  6. 08 12月, 2008 10 次提交
  7. 04 12月, 2008 1 次提交
  8. 03 12月, 2008 3 次提交
  9. 01 12月, 2008 2 次提交
  10. 26 11月, 2008 4 次提交
    • 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
    • M
      x86, bts: fix wrmsr and spinlock over kmalloc · de90add3
      Markus Metzger 提交于
      Impact: fix sleeping-with-spinlock-held bugs/crashes
      
      - Turn a wrmsr to write the DS_AREA MSR into a wrmsrl.
      - Use irqsave variants of spinlocks.
      - Do not allocate memory while holding spinlocks.
      Reported-by: NStephane Eranian <eranian@googlemail.com>
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      de90add3
    • M
      x86, pebs: fix PEBS record size configuration · c4858ffc
      Markus Metzger 提交于
      Impact: fix DS hw enablement on 64-bit x86
      
      Fix the PEBS record size in the DS configuration.
      Reported-by: NStephane Eranian <eranian@googlemail.com>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c4858ffc
    • M
      x86, bts: exclude ds.c from build when disabled · 292c669c
      Markus Metzger 提交于
      Impact: cleanup
      
      Move the CONFIG guard from the .c file into the makefile.
      Reported-by: NAndi Kleen <andi-suse@firstfloor.org>
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      292c669c
  11. 25 11月, 2008 1 次提交
  12. 23 11月, 2008 1 次提交
  13. 21 11月, 2008 1 次提交
    • M
      x86: Fix interrupt leak due to migration · 0ca4b6b0
      Matthew Wilcox 提交于
      When we migrate an interrupt from one CPU to another, we set the
      move_in_progress flag and clean up the vectors later once they're not
      being used.  If you're unlucky and call destroy_irq() before the vectors
      become un-used, the move_in_progress flag is never cleared, which causes
      the interrupt to become unusable.
      
      This was discovered by Jesse Brandeburg for whom it manifested as an
      MSI-X device refusing to use MSI-X mode when the driver was unloaded
      and reloaded repeatedly.
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ca4b6b0
  14. 20 11月, 2008 2 次提交
  15. 19 11月, 2008 1 次提交
  16. 18 11月, 2008 4 次提交