- 19 7月, 2010 1 次提交
-
-
由 Pavel Machek 提交于
pavel@suse.cz no longer works, replace it with working address. Signed-off-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 26 5月, 2010 1 次提交
-
-
由 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>
-
- 03 5月, 2010 1 次提交
-
-
由 Mark Langsdorf 提交于
With F10, model 10, all valid frequencies are in the ACPI _PST table. Cc: <stable@kernel.org> # 33.x 32.x Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> LKML-Reference: <1270065406-1814-6-git-send-email-bp@amd64.org> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Reviewed-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NH. Peter Anvin <hpa@zytor.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 10 4月, 2010 3 次提交
-
-
由 Mark Langsdorf 提交于
With F10, model 10, all valid frequencies are in the ACPI _PST table. Cc: <stable@kernel.org> # 33.x 32.x Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> LKML-Reference: <1270065406-1814-6-git-send-email-bp@amd64.org> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Reviewed-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Mark Langsdorf 提交于
Starting with model 10 of Family 0x10, AMD processors may have support for APERF/MPERF. Add support for identifying it and using it within cpufreq. Move the APERF/MPERF functions out of the acpi-cpufreq code and into their own file so they can easily be shared. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> LKML-Reference: <20100401141956.GA1930@aftab> Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> Reviewed-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Borislav Petkov 提交于
Starting with F10h, revE, AMD processors add support for a dynamic core boosting feature called Core Performance Boost. When a specific condition is present, a subset of the cores on a system are boosted beyond their P0 operating frequency to speed up the performance of single-threaded applications. In the normal case, the system comes out of reset with core boosting enabled. This patch adds a sysfs knob with which core boosting can be switched on or off for benchmarking purposes. While at it, make the CPB code hotplug-aware so that taking cores offline wouldn't interfere with boosting the remaining online cores. Furthermore, add cpu_online_mask hotplug protection as suggested by Andrew. Finally, cleanup the driver init codepath and update copyrights. Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com> LKML-Reference: <1270065406-1814-3-git-send-email-bp@amd64.org> Reviewed-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 28 1月, 2010 1 次提交
-
-
由 Lin Ming 提交于
acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 13 1月, 2010 1 次提交
-
-
由 Thomas Renninger 提交于
Easy fix for a regression introduced in 2.6.31. On managed CPUs the cpufreq.c core will call driver->exit(cpu) on the managed cpus and powernow_k8 will free the core's data. Later driver->get(cpu) function might get called trying to read out the current freq of a managed cpu and the NULL pointer check does not work on the freed object -> better set it to NULL. ->get() is unsigned and must return 0 as invalid frequency. Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14391Signed-off-by: NThomas Renninger <trenn@suse.de> Tested-by: NMichal Schmidt <mschmidt@redhat.com> CC: stable@kernel.org Signed-off-by: NDave Jones <davej@redhat.com>
-
- 17 12月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Noone uses this wrapper yet, and Ingo asked that it be kept consistent with current task_struct usage. (One user crept in via linux-next: fixed) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au. Cc: Ingo Molnar <mingo@elte.hu> Cc: Tejun Heo <tj@kernel.org>
-
- 25 11月, 2009 2 次提交
-
-
由 Thomas Renninger 提交于
This interface is mainly intended (and implemented) for ACPI _PPC BIOS frequency limitations, but other cpufreq drivers can also use it for similar use-cases. Why is this needed: Currently it's not obvious why cpufreq got limited. People see cpufreq/scaling_max_freq reduced, but this could have happened by: - any userspace prog writing to scaling_max_freq - thermal limitations - hardware (_PPC in ACPI case) limitiations Therefore export bios_limit (in kHz) to: - Point the user that it's the BIOS (broken or intended) which limits frequency - Export it as a sysfs interface for userspace progs. While this was a rarely used feature on laptops, there will appear more and more server implemenations providing "Green IT" features like allowing the service processor to limit the frequency. People want to know about HW/BIOS frequency limitations. All ACPI P-state driven cpufreq drivers are covered with this patch: - powernow-k8 - powernow-k7 - acpi-cpufreq Tested with a patched DSDT which limits the first two cores (_PPC returns 1) via _PPC, exposed by bios_limit: # echo 2200000 >cpu2/cpufreq/scaling_max_freq # cat cpu*/cpufreq/scaling_max_freq 2600000 2600000 2200000 2200000 # #scaling_max_freq shows general user/thermal/BIOS limitations # cat cpu*/cpufreq/bios_limit 2600000 2600000 2800000 2800000 # #bios_limit only shows the HW/BIOS limitation CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com> CC: Len Brown <lenb@kernel.org> CC: davej@codemonkey.org.uk CC: linux@dominikbrodowski.net Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Rusty Russell 提交于
It's still mugging the current process's cpumask, but as comment in 1ff6e97f says, it's not a trivial fix. So, at least we can use a cpumask_var_t to do the Wrong Thing the Right Way :) Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> To: cpufreq@vger.kernel.org Cc: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 18 11月, 2009 1 次提交
-
-
由 Roel Kluin 提交于
Not makes it a bool before the comparison. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 16 9月, 2009 1 次提交
-
-
由 Kurt Roeckx 提交于
Fixes bugzilla #13780 From: Kurt Roeckx <kurt@roeckx.be> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 02 9月, 2009 1 次提交
-
-
由 Mark Langsdorf 提交于
Remove an obsolete check that used to prevent there being more than 2 low P-states. Now that low-to-low P-states changes are enabled, it prevents otherwise workable configurations with multiple low P-states. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Tested-by: NKrists Krilovs <pow@pow.za.net> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 09 7月, 2009 1 次提交
-
-
由 Joe Perches 提交于
Commit 5fd29d6c ("printk: clean up handling of log-levels and newlines") changed printk semantics. printk lines with multiple KERN_<level> prefixes are no longer emitted as before the patch. <level> is now included in the output on each additional use. Remove all uses of multiple KERN_<level>s in formats. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 07 7月, 2009 1 次提交
-
-
由 Mark Langsdorf 提交于
Provide support for family 0xf processors with 2 P-states below the elevator voltage. Remove the checks that prevent this configuration from being supported and increase the transition voltage to prevent errors during the transition. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 15 6月, 2009 7 次提交
-
-
由 Rusty Russell 提交于
Remove all old-style cpumask operators, and cpumask_t. Also: get rid of the unused define_siblings function. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Acked-by: NMark Langsdorf <mark.langsdorf@amd.com> Tested-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Rusty Russell 提交于
cpumask: avoid playing with cpus_allowed in powernow-k8.c It's generally a very bad idea to mug some process's cpumask: it could legitimately and reasonably be changed by root, which could break us (if done before our code) or them (if we restore the wrong value). I did not replace powernowk8_target; it needs fixing, but it grabs a mutex (so no smp_call_function_single here) but Mark points out it can be called multiple times per second, so work_on_cpu is too heavy. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> To: cpufreq@vger.kernel.org Acked-by: NMark Langsdorf <mark.langsdorf@amd.com> Tested-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Naga Chumbalkar 提交于
Make powernowk8_get() similar to powernowk8_target() and powernowk8_verify() in the way it obtains "powernow_data" for a given CPU. Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Langsdorf, Mark <mark.langsdorf@amd.com> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com> Reviewed-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Tested-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Acked-by: NLangsdorf, Mark <mark.langsdorf@amd.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Naga Chumbalkar 提交于
By definition, "cpuinfo_cur_freq" should report the value from HW. So, don't depend on the cached value. Instead read P-state directly from HW, while taking into account the erratum 311 workaround for Fam 11h processors. Cc: Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Langsdorf, Mark <mark.langsdorf@amd.com> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com> Reviewed-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Tested-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Acked-by: NLangsdorf, Mark <mark.langsdorf@amd.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Andrew Morton 提交于
This symbol doesn't need file-global scope. Cc: "Zhang, Rui" <rui.zhang@intel.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Ingo Molnar <mingo@elte.hu> Cc: Langsdorf, Mark <mark.langsdorf@amd.com> Cc: Leo Milano <lmilano@gmx.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Luis Henriques 提交于
Mess cleanup in powernow_k8_acpi_pst_values() function. Signed-off-by: NLuis Henriques <henrix@sapo.pt> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Thomas Renninger 提交于
This doesn't fix anything, but it's expected that a transition latency of 0 could cause trouble in the future. Signed-off-by: NThomas Renninger <trenn@suse.de> Cc: Langsdorf, Mark <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 09 6月, 2009 1 次提交
-
-
由 Yinghai Lu 提交于
These are defined as static cpumask_var_t so if MAXSMP is not used, they are cleared already. Avoid surprises when MAXSMP is enabled. Signed-off-by: NYinghai Lu <yinghai.lu@kernel.org> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 06 6月, 2009 1 次提交
-
-
由 Dave Jones 提交于
The powernow-k8 driver checks to see that the Performance Control/Status Registers are declared as FFH (functional fixed hardware) by the BIOS. However, this check got broken in the commit: 0e64a0c9 [CPUFREQ] checkpatch cleanups for powernow-k8 Fix based on an original patch from Naga Chumbalkar. Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com> Cc: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 27 5月, 2009 2 次提交
-
-
由 Andreas Herrmann 提交于
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: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Thomas Renninger 提交于
- Make the message shorter and easier to grep for - Use printk_once instead of WARN_ONCE (functionality of these was mixed) Signed-off-by: NThomas Renninger <trenn@suse.de> Cc: Langsdorf, Mark <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 13 3月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y In most places it's cleaner to use the accessors cpu_sibling_mask() and cpu_core_mask() wrappers which already exist. I couldn't avoid cleaning up the access in oprofile, either. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 25 2月, 2009 4 次提交
-
-
由 Dave Jones 提交于
a0abd520 introduced a slew of extra kfree/return -ENODEV pairs. This replaces them all with gotos. Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Thomas Renninger 提交于
This is the typical message you get if you plug in a CPU which is newer than your BIOS. It's annoying seeing this message for each core. Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Thomas Renninger 提交于
powernow-k8 driver should always try to get cpufreq info from ACPI. Otherwise it will not be able to detect the transition latency correctly which results in ondemand governor taking a wrong sampling rate which will then result in sever performance loss. Let the user not shoot himself in the foot and always compile in ACPI support for powernow-k8. This also fixes a wrong message if ACPI_PROCESSOR is compiled as a module and #ifndef CONFIG_ACPI_PROCESSOR path is chosen. Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
由 Dave Jones 提交于
This driver has so many long function names, and deep nested if's The remaining warnings will need some code restructuring to clean up. Signed-off-by: NDave Jones <davej@redhat.com>
-
- 16 2月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Impact: fix powernow-k8 when acpi=off (or other error). There was a spurious change introduced into powernow-k8 in this patch: so that we try to "restore" the cpus_allowed we never saved. We revert that file. See lkml "[PATCH] x86/powernow: fix cpus_allowed brokage when acpi=off" from Yinghai for the bug report. Cc: Mike Travis <travis@sgi.com> Cc: Yinghai Lu <yinghai@kernel.org> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Acked-by: NIngo Molnar <mingo@elte.hu>
-
- 06 2月, 2009 1 次提交
-
-
由 Mark Langsdorf 提交于
At this time, the PowerNow! driver for K8 uses an experimentally derived formula to calculate transition latency. The value it provides is orders of magnitude too large on modern systems. This patch replaces the formula with ACPI _PSS latency values for more accuracy and better performance. I've tested it on two 2nd generation Opteron systems, a 3rd generation Operton system, and a Turion X2 without seeing any stability problems. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 06 1月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Impact: use new cpumask API to reduce memory usage This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NMike Travis <travis@sgi.com> Acked-by: NDave Jones <davej@redhat.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 1月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Impact: Reduce memory usage, use new API. This is part of an effort to reduce structure sizes for machines configured with large NR_CPUS. cpumask_t gets replaced by cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or struct cpumask * (large NR_CPUS). (Changes to powernow-k* by <travis>.) Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NMike Travis <travis@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 26 11月, 2008 1 次提交
-
-
由 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>
-
- 21 10月, 2008 1 次提交
-
-
由 Dave Jones 提交于
Update assorted email addresses and related info to point to a single current, valid address. additionally - trivial CREDITS entry updates. (Not that this file means much any more) - remove arjans dead redhat.com address from powernow driver Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 9月, 2008 1 次提交
-
-
由 Thomas Renninger 提交于
Make use of FW_BUG interface to give vendors and users the ability to automatically check for powernow-k8 related BIOS bugs by: dmesg |grep "Firmware Bug" Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 8月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 34ae7f35, which has been reported to cause a number of problems. During suspend and resume, it apparently causes a crash in a CPU hotplug notifier to happen, although the exact details are sketchy because of the inability to get good traces during the suspend sequence. See buzilla entries http://bugzilla.kernel.org/show_bug.cgi?id=11296 http://bugzilla.kernel.org/show_bug.cgi?id=11339 for more examples and details. [ Mark: "Revert the patch for now. I'm still looking into getting a reliable reproduction and I do not have a fix at this time." ] Requested-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NMark Langsdorf <mark.langsdorf@amd.com> Acked-by: NDave Jones <davej@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@inux-foundation.org>
-