- 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>
-
- 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>
-
- 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>
-
- 09 8月, 2008 1 次提交
-
-
由 Mark Langsdorf 提交于
This patch provides support for the _PSD ACPI object in the Powernow-k8 driver. Although it looks like an invasive patch, most of it is simply the consequence of turning the static acpi_performance_data structure into a pointer. AMD has tested it on several machines over the past few days without issue. [trivial checkpatch warnings fixed up by davej] [X86_POWERNOW_K8_ACPI=n buildfix from Randy Dunlap] Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Tested-by: NFrank Arnold <frank.arnold@amd.com> Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 07 2月, 2008 1 次提交
-
-
由 Mark Langsdorf 提交于
The latest series of Turion X2 processors have a new XFAM model. Add support for them to powernow-k8.h. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 23 10月, 2007 1 次提交
-
-
由 Mark Langsdorf 提交于
This patch should apply cleanly to the 2.6.23-git7 kernel. It changes the powernow-k8 driver code that deals with 3rd generation Opteron, Phenom, and later processors to match the architectural pstate driver described in the AMD64 Architecture Programmer's Manual Volume 2 Chapter 18. The initial implementation of the hardware pstate driver for PowerNow! used some processor-version specific features, and would not be maintainable in the long term as the processor features changed. This architectural driver should work on all future AMD processors. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 20 10月, 2007 1 次提交
-
-
由 Simon Arlott 提交于
Spelling fixes in arch/i386/. Signed-off-by: NSimon Arlott <simon@fire.lp0.eu> Signed-off-by: NAdrian Bunk <bunk@kernel.org>
-
- 11 10月, 2007 1 次提交
-
-
由 Thomas Gleixner 提交于
Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 15 5月, 2007 1 次提交
-
-
由 Dave Jones 提交于
Mark Langsdorf points out that the correct define for this revision bump is 0x80000. Also to save us having to keep renaming the #define, give it a more meaningful name. Signed-off-by: NDave Jones <davej@redhat.com>
-
- 13 5月, 2007 1 次提交
-
-
由 Dave Jones 提交于
Reported-by: NCalvin Dodge <caldodge@gmail.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 01 5月, 2007 1 次提交
-
-
由 David Rientjes 提交于
fill_powernow_table_pstate() and fill_powernow_table_fidvid() are only defined and used for X86_POWERNOW_K8_ACPI. Signed-off-by: NDavid Rientjes <rientjes@google.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 20 6月, 2006 1 次提交
-
-
由 Langsdorf, Mark 提交于
The fid/vid masks for parts using the extended parts are slightly incorrect and can result in incorrect fid/vid codes being applied. No instances of this problem have been reported in the field but it could be a problem with future parts. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 05 6月, 2006 1 次提交
-
-
由 Dave Jones 提交于
Forthcoming AMD products will use a different algorithm for transitioning pstates than the current generation Opteron products do. The attached patch allows the powernow-k8 driver to work with those products. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 28 3月, 2006 1 次提交
-
-
由 Andrew Morton 提交于
It is unneeded and wrong. Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 28 2月, 2006 1 次提交
-
-
由 Dave Jones 提交于
Signed-off-by: NDave Jones <davej@redhat.com>
-
- 30 11月, 2005 1 次提交
-
-
由 Langsdorf, Mark 提交于
Future versions of the Opteron processor may support frequency transitions of 100 MHz, instead of the=20 current 200 MHz. This patch enables the powernow-k8 driver to transition to an odd FID code, indicating a multiple of 100 MHz frequency. Signed-off-by: NJacob Shin <jacob.shin@amd.com> Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 30 7月, 2005 1 次提交
-
-
由 Dave Jones 提交于
From: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 29 7月, 2005 1 次提交
-
-
由 Dave Jones 提交于
can be encoded in the current driver's 4 bit frequency field. This patch updates the driver to support Rev F including 6 bit FIDs and processor ID updates. This should apply cleanly whether or not the dual-core bugfix I sent out last week is applied. I'd prefer that both get applied, of course. Signed-off-by: NDavid Keck <david.keck@amd.com> Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 01 6月, 2005 1 次提交
-
-
由 Dave Jones 提交于
With the release of the dual-core AMD Opterons last week, it's high time that cpufreq supported them. The attached patch applies cleanly to 2.6.12-rc3 and updates powernow-k8 to support the latest Athlon 64 and Opteron processors. Update the driver to version 1.40.0 and provide support for dual-core processors. Signed-off-by: NMark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: NDave Jones <davej@redhat.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-