1. 09 Jun, 2009 1 commit
  2. 05 Jun, 2009 1 commit
  3. 26 May, 2009 2 commits
    • Andreas Herrmann's avatar
      [CPUFREQ] powernow-k8: determine exact CPU frequency for HW Pstates · ca446d06
      Andreas Herrmann authored
      
      
      Slightly modified by trenn@suse.de -> only do this on fam 10h and fam 11h.
      
      Currently powernow-k8 determines CPU frequency from ACPI PSS objects, but
      according to AMD family 11h BKDG this frequency is just a rounded value:
      
        "CoreFreq (MHz) = The CPU COF specified by MSRC001_00[6B:64][CpuFid]
        rounded to the nearest 100 Mhz."
      
      As a consequnce powernow-k8 reports wrong CPU frequency on some systems,
      e.g. on Turion X2 Ultra:
      
        powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82
                     processors (2 cpu cores) (version 2.20.00)
        powernow-k8:    0 : pstate 0 (2200 MHz)
        powernow-k8:    1 : pstate 1 (1100 MHz)
        powernow-k8:    2 : pstate 2 (600 MHz)
      
      But this is wrong as frequency for Pstate2 is 550 MHz. x86info reports it
      correctly:
      
        #x86info -a |grep Pstate
        ...
        Pstate-0: fid=e, did=0, vid=24 (2200MHz)
        Pstate-1: fid=e, did=1, vid=30 (1100MHz)
        Pstate-2: fid=e, did=2, vid=3c (550MHz) (current)
      
      Solution is to determine the frequency directly from Pstate MSRs instead
      of using rounded values from ACPI table.
      Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      ca446d06
    • Thomas Renninger's avatar
      [CPUFREQ] powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data · df182977
      Thomas Renninger authored
      
      
      - Make the message shorter and easier to grep for
      - Use printk_once instead of WARN_ONCE (functionality of these was mixed)
      Signed-off-by: default avatarThomas Renninger <trenn@suse.de>
      Cc: Langsdorf, Mark <mark.langsdorf@amd.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      df182977
  4. 13 Mar, 2009 1 commit
  5. 25 Feb, 2009 4 commits
  6. 16 Feb, 2009 1 commit
  7. 05 Feb, 2009 1 commit
  8. 06 Jan, 2009 1 commit
  9. 03 Jan, 2009 1 commit
  10. 25 Nov, 2008 1 commit
    • Andreas Herrmann's avatar
      [CPUFREQ] powernow-k8: ignore out-of-range PstateStatus value · a266d9f1
      Andreas Herrmann authored
      
      
      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: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      a266d9f1
  11. 20 Oct, 2008 1 commit
  12. 22 Sep, 2008 1 commit
  13. 19 Aug, 2008 1 commit
  14. 08 Aug, 2008 2 commits
  15. 26 Jul, 2008 1 commit
  16. 18 Jul, 2008 1 commit
    • Mike Travis's avatar
      cpumask: Replace cpumask_of_cpu with cpumask_of_cpu_ptr · 65c01184
      Mike Travis authored
      
      
        * This patch replaces the dangerous lvalue version of cpumask_of_cpu
          with new cpumask_of_cpu_ptr macros.  These are patterned after the
          node_to_cpumask_ptr macros.
      
          In general terms, if there is a cpumask_of_cpu_map[] then a pointer to
          the cpumask_of_cpu_map[cpu] entry is used.  The cpumask_of_cpu_map
          is provided when there is a large NR_CPUS count, reducing
          greatly the amount of code generated and stack space used for
          cpumask_of_cpu().  The pointer to the cpumask_t value is needed for
          calling set_cpus_allowed_ptr() to reduce the amount of stack space
          needed to pass the cpumask_t value.
      
          If there isn't a cpumask_of_cpu_map[], then a temporary variable is
          declared and filled in with value from cpumask_of_cpu(cpu) as well as
          a pointer variable pointing to this temporary variable.  Afterwards,
          the pointer is used to reference the cpumask value.  The compiler
          will optimize out the extra dereference through the pointer as well
          as the stack space used for the pointer, resulting in identical code.
      
          A good example of the orthogonal usages is in net/sunrpc/svc.c:
      
      	case SVC_POOL_PERCPU:
      	{
      		unsigned int cpu = m->pool_to[pidx];
      		cpumask_of_cpu_ptr(cpumask, cpu);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, cpumask);
      		return 1;
      	}
      	case SVC_POOL_PERNODE:
      	{
      		unsigned int node = m->pool_to[pidx];
      		node_to_cpumask_ptr(nodecpumask, node);
      
      		*oldmask = current->cpus_allowed;
      		set_cpus_allowed_ptr(current, nodecpumask);
      		return 1;
      	}
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      65c01184
  17. 23 May, 2008 1 commit
  18. 19 May, 2008 1 commit
  19. 19 Apr, 2008 1 commit
    • Mike Travis's avatar
      x86: use new set_cpus_allowed_ptr function · fc0e4748
      Mike Travis authored
      
      
        * Use new set_cpus_allowed_ptr() function added by previous patch,
          which instead of passing the "newly allowed cpus" cpumask_t arg
          by value,  pass it by pointer:
      
          -int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
          +int set_cpus_allowed_ptr(struct task_struct *p, const cpumask_t *new_mask)
      
        * Cleanup uses of CPU_MASK_ALL.
      
        * Collapse other NR_CPUS changes to arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
          Use pointers to cpumask_t arguments whenever possible.
      
      Depends on:
      	[sched-devel]: sched: add new set_cpus_allowed_ptr function
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      fc0e4748
  20. 07 Feb, 2008 2 commits
    • Dave Jones's avatar
      [CPUFREQ] Fix sparse warning in powernow-k8 · 89c04849
      Dave Jones authored
      
      
      arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1238:9: warning: symbol '__ptr' shadows an earlier one
      arch/x86/kernel/cpu/cpufreq/powernow-k8.c:1238:9: originally declared here
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      89c04849
    • Yinghai Lu's avatar
      [CPUFREQ] powernow-k8 print pstate instead of fid/did for family 10h · 4ae5c49f
      Yinghai Lu authored
      
      
      powernow-k8: Found 1 Quad-Core AMD Opteron(tm) Processor 8354 processors (4 cpu cores) (version 2.20.00)
      powernow-k8:    0 : fid 0x0 did 0x0 (2200 MHz)
      powernow-k8:    1 : fid 0x0 did 0x0 (2000 MHz)
      powernow-k8:    2 : fid 0x0 did 0x0 (1700 MHz)
      powernow-k8:    3 : fid 0x0 did 0x0 (1400 MHz)
      powernow-k8:    4 : fid 0x0 did 0x0 (1100 MHz)
      
      actually index for CPU_HW_PSTATE is pstate instead of fid/vid
      So print it out as pstate.
      
      powernow-k8: Found 1 Quad-Core AMD Opteron(tm) Processor 8354 processors (4 cpu cores) (version 2.20.00)
      powernow-k8:    0 : pstate 0 (2200 MHz)
      powernow-k8:    1 : pstate 1 (2000 MHz)
      powernow-k8:    2 : pstate 2 (1700 MHz)
      powernow-k8:    3 : pstate 3 (1400 MHz)
      powernow-k8:    4 : pstate 4 (1100 MHz)
      Signed-off-by: default avatarYinghai Lu <yinghai.lu@sun.com>
      Cc: "Langsdorf, Mark" <mark.langsdorf@amd.com>
      Cc: "Herrmann3, Andreas" <Andreas.Herrmann3@amd.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      4ae5c49f
  21. 06 Feb, 2008 1 commit
  22. 30 Jan, 2008 1 commit
  23. 22 Oct, 2007 1 commit
  24. 19 Oct, 2007 1 commit
  25. 16 Oct, 2007 1 commit
    • Mike Travis's avatar
      x86: Convert cpu_core_map to be a per cpu variable · 08357611
      Mike Travis authored
      
      
      This is from an earlier message from 'Christoph Lameter':
      
          cpu_core_map is currently an array defined using NR_CPUS. This means that
          we overallocate since we will rarely really use maximum configured cpu.
      
          If we put the cpu_core_map into the per cpu area then it will be allocated
          for each processor as it comes online.
      
          This means that the core map cannot be accessed until the per cpu area
          has been allocated. Xen does a weird thing here looping over all processors
          and zeroing the masks that are not yet allocated and that will be zeroed
          when they are allocated. I commented the code out.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      08357611
  26. 11 Oct, 2007 1 commit
  27. 04 Oct, 2007 3 commits
  28. 13 Jul, 2007 3 commits
  29. 18 May, 2007 1 commit
  30. 14 May, 2007 1 commit