Linux CPU Freq

• Thread Index

• [Bug 12788] ~40,000 wakeups/sec after suspend/resume with Tickless kernel
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• [Bug 12788] After suspend/resume with Tickless kernel, CPU spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH] acpi-cpufreq.c - Fix typo and indentation
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH V2 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH V2 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH V2 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• [PATCH V2 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH V2 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH V2 3/3] kernel.h: Remove unused printk_once
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH V2 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
• [PATCH 3/3] kernel.h: Remove unused printk_once
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 2/3] arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: Use DO_ONCE & spelling fix
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 0/3] Introduce and use DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 1/3] kernel.h: Add DO_ONCE statement expression macro
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [patch for 2.6.30? 1/2] cpufreq: powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] x86: Fix VIA C3 Longhaul v2 identification
  • From: Krzysztof Helt <krzysztof.h1@xxxxx>
• [PATCH] cpufreq fix timer teardown in conservative governor
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• [PATCH] cpufreq fix timer teardown in ondemand governor
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• [Bug 13186] cpufreq timer teardown problem
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• [PATCH] Cpufreq: Added input event hook to ramp up cpu frequency
  • From: Tero Kristo <tero.kristo@xxxxxxxxx>
• [Experimental] Cpufreq hack for embedded systems
  • From: Tero Kristo <tero.kristo@xxxxxxxxx>
• [Bug 13146] Foxconn A7GM-S 2.0: BIOS does not provide ACPI _PSS objects in a way that Linux understands
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [patch for 2.6.30? 1/2] cpufreq: powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
  • From: akpm@xxxxxxxxxxxxxxxxxxxx
• [patch for 2.6.30? 2/2] cpufreq: powernow-k8: determine exact CPU frequency for HW Pstates
  • From: akpm@xxxxxxxxxxxxxxxxxxxx
• Unknown p4-clockmod-capable CPU
  • From: root <root@xxxxxxxxxxxxxxxxx>
• AMD Athlon64 2000+ embedded CPU volt/freq control?
  • From: Andrew Paprocki <andrew@xxxxxxxxxxx>
• [PATCH] cpufreq: shorten names for cpufreq workqueues
  • From: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
  • From: Ingo Molnar <mingo@xxxxxxx>
• [PATCH 2/2] CPUFREQ: powernow-k8: determine exact CPU frequency for HW Pstates
  • From: Thomas Renninger <trenn@xxxxxxx>
• [RESEND] Powernow-k8 fixes which should still hit 2.6.30
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/2] CPUFREQ: powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: [PATCH] cpufreq fix timer teardown in ondemand governor (2.6.28.x, 2.6.29.1, 2.6.30-rc2)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• Re: [PATCH -stable] cpufreq fix timer teardown in conservative governor (2.6.28.x, 2.6.29.1)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• [Bug 13186] cpufreq timer teardown problem
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [BUG] 2.6.29.1 debugobjects warning
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq fix timer teardown in conservative governor (2.6.30-rc2)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• Re: [PATCH] cpufreq fix timer teardown in conservative governor (2.6.30-rc2)
  • From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
• [Bug 13096] 2.6.30-rc2 hangs in get_measured_perf on tigerton
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 13096] 2.6.30-rc2 hangs in get_measured_perf on tigerton
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 13186] New: cpufreq timer teardown problem
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH] cpufreq fix timer teardown in conservative governor (2.6.30-rc2)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• Re: [BUG] 2.6.29.1 debugobjects warning
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• Re: [BUG] 2.6.29.1 debugobjects warning
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] cpufreq fix timer teardown in conservative governor (2.6.30-rc2)
  • From: Len Brown <lenb@xxxxxxxxxx>
• [PATCH -stable] cpufreq fix timer teardown in conservative governor (2.6.28.x, 2.6.29.1)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• [PATCH] cpufreq fix timer teardown in conservative governor (2.6.30-rc2)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• [PATCH] cpufreq fix timer teardown in ondemand governor (2.6.28.x, 2.6.29.1, 2.6.30-rc2)
  • From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxx>
• Re: ACPI / powernow-k8 problems with M4A78T-E (AM3) and 2.6.30-rc3
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [BUG] 2.6.29.1 debugobjects warning
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: build issue #5 for v2.6.30-rc3 :
  • From: Dave Jones <davej@xxxxxxxxxx>
• build issue #5 for v2.6.30-rc3 :
  • From: Toralf Förster <toralf.foerster@xxxxxx>
• [PATCH 1/3] acpi-cpufreq: Move average performance funtions into separate file and KConfig
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/3] X86: Introduce mperf_aperf X86_FEATURE
  • From: Thomas Renninger <trenn@xxxxxxx>
• Separate average frequency from acpi-cpufreq and make it available via EXPORT_SYMBOL_GPL for others
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/3] acpi-cpufreq: Use X86_FEATURE_APERF_MPERF to check for average freq capability
  • From: Thomas Renninger <trenn@xxxxxxx>
• is the change in meaning of cpu related metrics taken into account in other kernel tools
  • From: Tim Coote <tim+vger.kernel.org@xxxxxxxxx>
• [PATCH 1/5] CPUFREQ: ondemand: Uncouple minimal sampling rate from HZ in NO_HZ case
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 5/5] CPUFREQ: powernow-k8: determine exact CPU frequency for HW Pstates
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/5] CPUFREQ: Only set sampling_rate_max deprecated, sampling_rate_min is useful
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 4/5] CPUFREQ: powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/5] CPUFREQ: powernow-k8: Set tranistion latency to 1 if ACPI tables export 0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Several ondemand and powernow-k8 cleanups and bugfixes for 2.6.30
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [BUG 2.6.30_rc1] powernow-k8: oops during initialization
  • From: Ozan Çağlayan <ozan@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
• Re: [PATCH 5/8] acpi-cpufreq: Move average performance funtions into separate file and KConfig
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: [PATCH 5/8] acpi-cpufreq: Move average performance funtions into separate file and KConfig
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH 4/8] acpi-cpufreq: Do not let get_measured perf depend on internal variable
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 3/8] acpi-cpufreq: First multiply then divide to avoid zero results
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH 2/8] acpi-cpufreq: Cleanup: Use printk_once
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH 1/8] Fix for a regression that was introduced by earlier commit
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH] x86, acpi_cpufreq: Fix the NULL pointer dereference in get_measured_perf
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH 7/8] acpi-cpufreq: Use already defined IDA feature flag instead of checking cpuid
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: [PATCH 5/8] acpi-cpufreq: Move average performance funtions into separate file and KConfig
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: [PATCH 4/8] acpi-cpufreq: Do not let get_measured perf depend on internal variable
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: [PATCH 3/8] acpi-cpufreq: First multiply then divide to avoid zero results
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• [PATCH 5/8] acpi-cpufreq: Move average performance funtions into separate file and KConfig
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/8] Fix for a regression that was introduced by earlier commit
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 6/8] CPUFREQ: Add average frequency to sysfs exported files of cpufreq_stats
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/8] acpi-cpufreq: Cleanup: Use printk_once
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 4/8] acpi-cpufreq: Do not let get_measured perf depend on internal variable
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/8] acpi-cpufreq: First multiply then divide to avoid zero results
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 7/8] acpi-cpufreq: Use already defined IDA feature flag instead of checking cpuid
  • From: Thomas Renninger <trenn@xxxxxxx>
• acpi-cpufreq: Move average performance code and make it available to userspace and several cleanups in this area
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 8/8] CPUFREQ: Add documentation for new average_freq cpufreq_stats sysfs file
  • From: Thomas Renninger <trenn@xxxxxxx>
• p4-clockmod: Unknown p4-clockmod-capable CPU. Please send an e-mail
  • From: Michael Heiming <m.heiming@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: dynamic voltage frequency scaling (DVFS) per core in Opteron
  • From: Victor Jimenez <victor.javier@xxxxxx>
• Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH] x86, acpi_cpufreq: Fix the NULL pointer dereference in get_measured_perf
  • From: "Zhang, Yanmin" <yanmin_zhang@xxxxxxxxxxxxxxx>
• [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• [PATCH] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
  • From: "Darrick J. Wong" <djwong@xxxxxxxxxx>
• [Bug 13096] New: 2.6.30-rc2 hangs in get_measured_perf on tigerton
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH] x86, acpi_cpufreq: Fix the NULL pointer dereference in get_measured_perf
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• [PATCH 1/3] S3C64XX: Add initial support for ARMCLK
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 3/3] S3C: Add DVFS support to the S3C cpufreq driver
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/3] S3C: Initial support for CPU frequency scaling
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] S3C: Initial support for CPU frequency scaling
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/3] S3C: Add DVFS support to the S3C cpufreq driver
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/3] S3C: Initial support for CPU frequency scaling
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 3/3] SMDK6410: Hook regulator control of VDDARM up for WM1190-EV1
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 0/3] Initial cpufreq support for Samsung S3C CPUs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• RE: 2.6.30-rc2 hangs in get_measured_perf on tigerton
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: 2.6.30-rc2 hangs in get_measured_perf on tigerton
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Unknown p4-clockmod-capable CPU
  • From: Lakestake Rocketry <lakestake@xxxxxxxxx>
• cpufreq-set option to set all related cpus?
  • From: Frank Myhr <fmyhr@xxxxxxxxxxx>
• Re: cpufreq-set option to set all related cpus?
  • From: Frank Myhr <fmyhr@xxxxxxxxxxx>
• [Bug 13035] select for cpufreq/ files
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 13035] New: select for cpufreq/ files
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 2/8] ACPI: cpufreq: remove dupilcated #include
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [patch 1/2] acpi x86: Cleanup acpi_cpufreq structures related to aperf/mperf
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: process priority
  • From: Howard Chu <hyc@xxxxxxxxx>
• Re: process priority
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: process priority
  • From: Thomas Renninger <trenn@xxxxxxx>
• process priority
  • From: Howard Chu <hyc@xxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Grigori Goronzy <greg@xxxxxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Corentin Chary <corentin.chary@xxxxxxxxx>
• Re: [RFC] Improving scheduler for asymmetric multi-core processor in Google's summer of code
  • From: Hitoshi Mitake <h.mitake@xxxxxxxxx>
• [Bug 12788] After suspend/resume with Tickless kernel, CPU spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [RFC] Improving scheduler for asymmetric multi-core processor in Google's summer of code
  • From: Hitoshi Mitake <h.mitake@xxxxxxxxx>
• Re: [RFC] Improving scheduler for asymmetric multi-core processor in Google's summer of code
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [RFC] Improving scheduler for asymmetric multi-core processor in Google's summer of code
  • From: Hitoshi Mitake <h.mitake@xxxxxxxxx>
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12993] warning in powernow-k8.c:1254
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH 1/3] [CPUREQ] remove duplicated #include
  • From: Huang Weiyi <weiyi.huang@xxxxxxxxx>
• [Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 6382] powernow_k8 causes hangs on system
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• Re: dynamic voltage frequency scaling (DVFS) per core in Opteron
  • From: Amithash Prasad <amithash@xxxxxxxxx>
• Re: dynamic voltage frequency scaling (DVFS) per core in Opteron
  • From: Thomas Renninger <trenn@xxxxxxx>
• dynamic voltage frequency scaling (DVFS) per core in Opteron
  • From: Victor Jimenez <victor.javier@xxxxxx>
• dynamic voltage frequency scaling (DVFS) per core in Opteron
  • From: Victor Jimenez <victor.javier@xxxxxx>
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugzilla-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] ACPI limits CPU to 800Mhz
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12910] New: Wierd iteractions with CPUFREQ
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12902] CPU frequency alternates between min and max for niced background processes
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12902] CPU frequency alternates between min and max for niced background processes
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12902] New: CPU frequency alternates between min and max for niced background processes
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• p4-clockmod: Unknown p4-clockmod-capable CPU
  • From: linus <linus@xxxxxxxxxx>
• 2.6.29-rcX: wierd iteractions with CPUFREQ
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Fabio Comolli <fabio.comolli@xxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Fabio Comolli <fabio.comolli@xxxxxxxxx>
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: New C6 state in intels nehalem
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: New C6 state in intels nehalem
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: New C6 state in intels nehalem
  • From: michael k lang <mlang@xxxxxxxx>
• No cpufreq on aOpen MP45
  • From: "Daniel Malmgren" <daniel@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: New C6 state in intels nehalem
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: New C6 state in intels nehalem
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• RE: [PATCH 1/4] S3C: CPU detection support
  • From: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
• New C6 state in intels nehalem
  • From: michael k lang <mlang@xxxxxxxx>
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH] cpufreq: add atom family to p4-clockmod
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 1/4] S3C: CPU detection support
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [PATCH 1/4] S3C: CPU detection support
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/4] S3C: CPU detection support
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [PATCH] cpufreq: add atom family to p4-clockmod
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [PATCH] cpufreq: add atom family to p4-clockmod
  • From: Jarod Wilson <jarod@xxxxxxxxxx>
• Re: [PATCH] cpufreq: add atom family to p4-clockmod
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 4/4] S3C64XX: Add DVFS support to the S3C64XX cpufreq driver
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 3/4] S3C64XX: Initial support for CPU frequency scaling
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/4] S3C64XX: Add initial support for ARMCLK
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/4] S3C: CPU detection support
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 0/4] Initial cpufreq support for Samsung S3C6410 CPUs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• Longhaul v2 mode is never selected for VIA C3 chips
  • From: Krzysztof Helt <krzysztof.h1@xxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Maciej Piechotka <uzytkownik2@xxxxxxxxx>
• Re: [Bugme-new] [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH] cpufreq: Remove KERN_ERR output if nForce2 chipset not found
  • From: Jarod Wilson <jarod@xxxxxxxxxx>
• Re: [PATCH] cpufreq: Remove KERN_ERR output if nForce2 chipset not found
  • From: Roland Dreier <rdreier@xxxxxxxxx>
• Re: [PATCH] cpufreq: Remove KERN_ERR output if nForce2 chipset not found
  • From: Jarod Wilson <jarod@xxxxxxxxxx>
• [PATCH] cpufreq: Remove KERN_ERR output if nForce2 chipset not found
  • From: Roland Dreier <rdreier@xxxxxxxxx>
• [PATCH] cpufreq: add atom family to p4-clockmod
  • From: Jarod Wilson <jarod@xxxxxxxxxx>
• Re: Unknown p4-clockmode-capable CPU
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: fehlerinfo cpufreq-info
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12826] New: cpufreq driver do not expose all data and configuration to /sys
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Unknown p4-clockmode-capable CPU
  • From: Geoffrey Leach <geoff@xxxxxxxxxx>
• Unknown p4-clockmod-capable CPU
  • From: Boban Aćimović <boban.acimovic@xxxxxxxxx>
• Re: [PATCH 1/3] S3C: CPU detection support
  • From: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: "Rafael J. Wysocki" <rjw@xxxxxxx>
• Re: [PATCH 2/3] S3C64XX: Add initial support for ARMCLK
  • From: Mark Brown <broonie@xxxxxxxxxxxxx>
• Re: [PATCH 2/3] S3C64XX: Add initial support for ARMCLK
  • From: Magnus Lilja <lilja.magnus@xxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Sitsofe Wheeler <sitsofe@xxxxxxxxx>
• Re: [PATCH 1/3] S3C: CPU detection support
  • From: Tony Lindgren <tony@xxxxxxxxxxx>
• Re: [PATCH 2/3] S3C64XX: Add initial support for ARMCLK
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] S3C: CPU detection support
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Sitsofe Wheeler <sitsofe@xxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
• Re: 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• 2.6.28 - 2.6.29-rc6-git5 regression, p4-clockmod/cpufreq probably
  • From: Denys Fedoryschenko <denys@xxxxxxxxxxx>
• Re: [PATCH 2/3] S3C64XX: Add initial support for ARMCLK
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12788] New: After suspend/resume, processor spends more time in C0 state, C3 hardly used
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• cpuspeed failure report, as advised by kernel messages
  • From: Michal Szymanski <msz@xxxxxxxxxxxxxx>
• [PATCH 3/3] S3C64XX: Initial support for CPU frequency scaling
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 2/3] S3C64XX: Add initial support for ARMCLK
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/3] S3C: CPU detection support
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 0/3] Initial cpufreq support for Samsung S3C6410 CPUs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Intel Atom 330 CPU
  • From: egf@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH] p4-clockmod: Calculate frequency based on TSC value for P4 models 0 and 1
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH] p4-clockmod: Calculate frequency based on TSC value for P4 models 0 and 1
  • From: Frans Pop <elendil@xxxxxxxxx>
• Re: [PATCH] p4-clockmod: Calculate frequency based on TSC value for P4 models 0 and 1
  • From: Dave Jones <davej@xxxxxxxxxx>
• [PATCH] p4-clockmod: Calculate frequency based on TSC value for P4 models 0 and 1
  • From: Frans Pop <elendil@xxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] cpufreq: Make cpufreq-nforce2 less obnoxious
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Scott James Remnant <scott@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Scott James Remnant <scott@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Alan Jenkins <sourcejedi.lkml@xxxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Ingo Molnar <mingo@xxxxxxx>
• [PATCH] cpufreq: Change link order of x86 cpufreq modules
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• [PATCH 04/10] alloc_percpu: change percpu_ptr to per_cpu_ptr
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH] cpufreq: Governor poll frequency tuneables exported in config.
  • From: Mike Chan <mike@xxxxxxxxxxx>
• Re: [PATCH] cpufreq: Governor poll frequency tuneables exported in config.
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH] cpufreq: Governor poll frequency tuneables exported in config.
  • From: Éric Piel <eric.piel@xxxxxxxxxxxxxxxx>
• NAS build with
  • From: Peter de Jong <linux@xxxxxxxxxxx>
• Re: [PATCH 4/4] [CPUFREQ] conservative: remove 10x from def_sampling_rate
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Unknown p4-clockmod-capable CPU
  • From: Geoffrey Leach <geoff@xxxxxxxxxx>
• RE: AMD 7750 / Asus M3N-HD/HDMI: cpufreq doesn't work
  • From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
• [PATCH 3/4] [CPUFREQ] conservative: fixup governor to function more like ondemand logic
  • From: Alexander Clouter <alex@xxxxxxxxxxxxx>
• [PATCH 4/4] [CPUFREQ] conservative: remove 10x from def_sampling_rate
  • From: Alexander Clouter <alex@xxxxxxxxxxxxx>
• [PATCH 1/4] [CPUFREQ] conservative: amend author's email address
  • From: Alexander Clouter <alex@xxxxxxxxxxxxx>
• [PATCH 2/4] [CPUFREQ] conservative: fix dbs_cpufreq_notifier so freq is not locked
  • From: Alexander Clouter <alex@xxxxxxxxxxxxx>
• [PATCH] cpufreq: Governor poll frequency tuneables exported in config.
  • From: Mike Chan <mike@xxxxxxxxxxx>
• Re: AMD 7750 / Asus M3N-HD/HDMI: cpufreq doesn't work
  • From: Amithash Prasad <amithash@xxxxxxxxx>
• AMD 7750 / Asus M3N-HD/HDMI: cpufreq doesn't work
  • From: Leszek Koltunski <leszek@xxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: p4-clockmod / X5472
  • From: Costin Grigoras <costin.grigoras@xxxxxxx>
• Re: p4-clockmod / X5472
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• p4-clockmod / X5472
  • From: Costin Grigoras <costin.grigoras@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 4/7] CPUFREQ: powernow-k8: Get transition latency from ACPI _PSS table
  • From: Robert Hancock <hancockrwd@xxxxxxxxx>
• p4-clockmod: Unknown p4-clockmod-capable CPU. Please send an e-mail to <cpufreq@xxxxxxxxxxxxxxx>
  • From: Patrick Pichon <patrick@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Dmitry Adamushko <dmitry.adamushko@xxxxxxxxx>
• Re: [tip:core/printk] printk: introduce printk_once()
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Ingo Molnar <mingo@xxxxxxx>
• [tip:core/printk] printk: introduce printk_once()
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Ingo Molnar <mingo@xxxxxxx>
• On top fixes for my last patches
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/2] CPUFREQ: Use static or it won't compile if conservative and ondemand are set =y
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/2] CPUFREQ: powernow-k8: Forgot to use printk instead of WARN_ONCE in last patch
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12495] thinkpad problems during resume
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12495] thinkpad problems during resume
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups - against next
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] CPUFREQ: powernow-k8: Only print error message once, not per core.
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 3/7] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 6/7] CPUFREQ: powernow-k8: Only print error message once, not per core.
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 7/7] ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries
  • From: Len Brown <lenb@xxxxxxxxxx>
• Re: [PATCH 6/7] CPUFREQ: powernow-k8: Only print error message once, not per core.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 3/7] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/7] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH 7/7] ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 5/7] CPUFREQ: powernow-k8: Always compile powernow-k8 driver with ACPI support
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 4/7] CPUFREQ: powernow-k8: Get transition latency from ACPI _PSS table
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/7] CPUFREQ: Introduce /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/7] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/7] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 6/7] CPUFREQ: powernow-k8: Only print error message once, not per core.
  • From: Thomas Renninger <trenn@xxxxxxx>
• CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups - against next
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: cpufreq on demand governor sampling rate restricted to HZ even on NO_HZ kernels
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 7/7] ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 2/7] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 4/7] CPUFREQ: powernow-k8: Get transition latency from ACPI _PSS table
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/7] CPUFREQ: Introduce /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 5/7] CPUFREQ: powernow-k8: Always compile powernow-k8 driver with ACPI support
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 6/7] CPUFREQ: powernow-k8: Only print error message once, not per core.
  • From: Thomas Renninger <trenn@xxxxxxx>
• CPUFREQ: Ondemand and powernow-k8 enhancements/fixes/cleanups
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/7] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Thomas Renninger <trenn@xxxxxxx>
• RE: [PATCH] Determine latency from ACPI
  • From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
• Re: [PATCH] Determine latency from ACPI
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Determine latency from ACPI
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Determine latency from ACPI
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• No intermediate powerstates with e_powersaver
  • From: Piet Hein <ex_adres@xxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Freeze-up related to this message???
  • From: Frank Krawczyk <fkrawczyk@xxxxxxxx>
• Re: cpufreq on demand governor sampling rate restricted to HZ even on NO_HZ kernels
  • From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@xxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• cpufreq on demand governor sampling rate restricted to HZ even on NO_HZ kernels
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: circular locking dependency on shutdown
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• [PATCH][retry 1] Determine latency from ACPI
  • From: Mark Langsdorf <mark.langsdorf@xxxxxxx>
• Re: circular locking dependency on shutdown
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: circular locking dependency on shutdown
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• circular locking dependency on shutdown
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH] Determine latency from ACPI
  • From: Thomas Renninger <trenn@xxxxxxx>
• conservative on multi-core
  • From: Rafi Rubin <rafi@xxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Mike Travis <travis@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Mike Travis <travis@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• [PATCH] Determine latency from ACPI
  • From: Mark Langsdorf <mark.langsdorf@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Mike Travis <travis@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Mike Travis <travis@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH 2/3] CPUFREQ: ondemand/conservative: deprecate sampling_rate{min,max}
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/3] CPUFREQ: Introduce /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/3] CPUFREQ: ondemand/conservative: sanitize sampling_rate restrictions
  • From: Thomas Renninger <trenn@xxxxxxx>
• CPUFREQ: Transition latency tuning enhancements
  • From: Thomas Renninger <trenn@xxxxxxx>
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12389] acpi-cpufreq doesn't detect speed limit when cold booted on battery
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12495] thinkpad problems during resume
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12495] thinkpad problems during resume
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12495] New: thinkpad problems during resume
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request]
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request]
  • From: Mike Travis <travis@xxxxxxx>
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12482] Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: acpi-cpufreq vs p4-clockmod
  • From: Dave Jones <davej@xxxxxxxxxx>
• [Bug 12482] New: Change cpufreq_ondemand to tread SCHED_IDLE time as idle time
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request]
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request]
  • From: Mike Travis <travis@xxxxxxx>
• [PATCH 2/3] work_on_cpu: Use our own workqueue.
  • From: Mike Travis <travis@xxxxxxx>
• [PATCH 3/3] cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
  • From: Mike Travis <travis@xxxxxxx>
• [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq
  • From: Mike Travis <travis@xxxxxxx>
• [PATCH 1/3] work_on_cpu: dont try to get_online_cpus() in work_on_cpu.
  • From: Mike Travis <travis@xxxxxxx>
• Re: acpi-cpufreq vs p4-clockmod
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• unknown P4-clockmod-capable CPU
  • From: Zack <fbui@xxxxxxxxxxx>
• acpi-cpufreq vs p4-clockmod
  • From: Pigeon <pigeon@xxxxxxxxxxx>
• [Bug 12389] acpi-cpufreq doesn't detect speed limit when cold booted on battery
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12389] acpi-cpufreq doesn't detect speed limit when cold booted on battery
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12389] New: acpi-cpufreq doesn't detect speed limit when cold booted on battery
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12385] CPU ondemand governor doesn't work well
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12385] CPU ondemand governor doesn't work well
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12385] CPU ondemand governor doesn't work well
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12385] CPU ondemand governor doesn't work well
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12385] New: CPU ondemand governor doesn't work well
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• problems with cpufreq when AC adapter is plugged in but battery plugged out
  • From: Carsten Moldenhauer <carsten.moldenhauer@xxxxxxxxxxx>
• problems with cpufreq when AC adapter is plugged in but battery plugged out
  • From: Carsten Moldenhauer <carsten.moldenhauer@xxxxxxxxxxx>
• 2.6.27.10: CPU ondemand governor doesn't work well
  • From: Toralf Förster <toralf.foerster@xxxxxx>
• Unknown p4-clockmod-capable CPU
  • From: Jos van der Ende <seraph@xxxxxxxxx>
• Re: Atom 330 message
  • From: Dave Jones <davej@xxxxxxxxxx>
• [Bug 12310] NOHZ appears to cause ondemand to effectively ignore 'ignore_nice_load'
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: Intel Celeron 430
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• [Bug 12310] NOHZ appears to cause ondemand to effectively ignore 'ignore_nice_load'
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Atom 330 message
  • From: Luca Botti <luca.botti@xxxxxxxxx>
• [Bug 12310] New: NOHZ appears to cause ondemand to effectively ignore 'ignore_nice_load'
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Intel Celeron 430
  • From: "Luis Correia" <luis.f.correia@xxxxxxxxx>
• Re: Perfomance governor is still changing frequency
  • From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
• [Bug 12196] cpufreq does not work for Intel Celeron 550 without a patch
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Freeze problems with C3 Ezra and longhaul
  • From: Huub Reuver <h_reuver@xxxxxxxxxxxxxxxxx>
• Re: Via C3 Nehemia
  • From: "pw.marcus@xxxxxxxxxxx" <pw.marcus@xxxxxxxxxxx>
• Re: Via C3 Nehemia
  • From: "pw.marcus@xxxxxxxxxxx" <pw.marcus@xxxxxxxxxxx>
• Re: Via C3 Nehemia
  • From: "Jean-Marc Spaggiari" <jean-marc@xxxxxxxxxxxxx>
• [Bug 12196] cpufreq does not work for Intel Celeron 550 without a patch
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: Perfomance governor is still changing frequency
  • From: Len Brown <lenb@xxxxxxxxxx>
• [Bug 12196] cpufreq does not work for Intel Celeron 550 without a patch
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11299] acpi_cpufreq doesn't load - Intel Q9300 CPU and shuttle SG33G5
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11299] acpi_cpufreq doesn't load - Intel Q9300 CPU and shuttle SG33G5
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 12196] cpufreq does not work for Intel Celeron 550 without a patch
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: Via C3 Nehemia
  • From: "Jean-Marc Spaggiari" <jean-marc@xxxxxxxxxxxxx>
• Re: Via C3 Nehemia
  • From: "pw.marcus@xxxxxxxxxxx" <pw.marcus@xxxxxxxxxxx>
• Re: Via C3 Nehemia
  • From: "Jean-Marc Spaggiari" <jean-marc@xxxxxxxxxxxxx>
• Via C3 Nehemia
  • From: "pw.marcus@xxxxxxxxxxx" <pw.marcus@xxxxxxxxxxx>
• Unknown p4-clockmod-capable CPU
  • From: contact_info@xxxxxxxxx
• [Bug 12196] cpufreq does not work for Intel Celeron 550 without a patch
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: cpufreq/e_powersaver resets scaling ranges
  • From: Herton Ronaldo Krzesinski <herton@xxxxxxxxxxxxxxx>
• cpufreq/e_powersaver resets scaling ranges
  • From: Amin Astaneh <amin@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: PIII Coppermine desktop CPU
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• PIII Coppermine desktop CPU
  • From: "pw.marcus" <pw.marcus@xxxxxxxxxxx>
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Matthew Garrett <mjg@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: p4-clockmod: Unknown p4-clockmod-capable CPU
  • From: Etienne Le Sueur <elesueur@xxxxxxxxxxxxxxx>
• Re: cpufreqd bugs
  • From: Mattia Dongili <malattia@xxxxxxxx>
• Change governor to userspace to avoid suspend/resume lockups
  • From: "Dan Nicholson" <dbn.lists@xxxxxxxxx>
• cpufreqd bugs
  • From: engage <engage@xxxxxxx>
• cpufreqd bugs
  • From: engage@xxxxxxx
• cpufreqd bugs
  • From: engage@xxxxxxx
• Re: p4-clockmod: Unknown p4-clockmod-capable CPU
  • From: Gordon Henderson <gordon@xxxxxxxxxx>
• Re: p4-clockmod: Unknown p4-clockmod-capable CPU
  • From: "Joshua Murphy" <poisonbl@xxxxxxxxx>
• p4-clockmod: Unknown p4-clockmod-capable CPU
  • From: Gordon Henderson <gordon@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Cristiano Prisciandaro <cristiano.p@xxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Cristiano Prisciandaro <cristiano.p@xxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: "Corentin Chary" <corentin.chary@xxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: "Corentin Chary" <corentin.chary@xxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Tom Hughes <tom@xxxxxxxxxx>
• [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver
  • From: Cristiano Prisciandaro <cristiano.p@xxxxxxxxx>
• Re: [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Ingo Molnar <mingo@xxxxxxx>
• [PATCH v2] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
• Re: [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
• Re: [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Ingo Molnar <mingo@xxxxxxx>
• [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
• Re: Unknown p4-clockmod-capable CPU.
  • From: Herton Ronaldo Krzesinski <herton@xxxxxxxxxxxxxxx>
• Unknown p4-clockmod-capable CPU.
  • From: johnny strom <johnny.strom@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Achim Gottinger <achim@xxxxxxxxxx>
• [PATCH] x86: powernow-k8: ignore out-of-range PstateStatus value
  • From: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
• [patch 1/1] cpu-freq/Documentation: add Blackfin to list of supported processors
  • From: akpm@xxxxxxxxxxxxxxxxxxxx
• Re: automatically load kmod for governor on cpufreq-set
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: automatically load kmod for governor on cpufreq-set
  • From: Alexey Klimov <klimov.linux@xxxxxxxxx>
• automatically load kmod for governor on cpufreq-set
  • From: jieryn@xxxxxxxxx
• [PATCH] cpufreq, p4-clockmod: reduce noise
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/1] cpu-freq/Documentation: Add Blackfin to list of supported processors
  • From: Bryan Wu <cooloney@xxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
• Re: sparc64 allmodconfig build failure...
  • From: Sven Wegener <sven.wegener@xxxxxxxxxxx>
• sparc64 allmodconfig build failure...
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• Re: [PATCH] cpufreq: correct broken links and email address
  • From: Dave Jones <davej@xxxxxxxxxx>
• question about cpufreq_conservative.c
  • From: "Alexey Klimov" <klimov.linux@xxxxxxxxx>
• Re: [PATCH] cpufreq: correct broken links and email address
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• [PATCH] cpufreq: correct broken links and email address
  • From: Németh Márton <nm127@xxxxxxxxxxx>
• [PATCH] cpufreq: correct broken links and email address
  • From: Németh Márton <nm127@xxxxxxxxxxx>
• dmesg: Unknown p4-clockmod-capable CPU. Please send an e-mail
  • From: Németh Márton <nm127@xxxxxxxxxxx>
• [Bug 6382] Random lockups, no kernel panic just a compleate hang
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11651] 2.6.27 kernel disables frequency switching on x86_64
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11651] 2.6.27 kernel disables frequency switching on x86_64
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11651] 2.6.27 kernel disables frequency switching on x86_64
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11651] 2.6.27 kernel disables frequency switching on x86_64
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11651] New: 2.6.27 kernel disables frequency switching on x86_64
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• question about cpufreq_conservative.c
  • From: "Alexey Klimov" <klimov.linux@xxxxxxxxx>
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [Bug 11623] New: scaling_available_frequencies reports too high frequencies
  • From: bugme-daemon@xxxxxxxxxxxxxxxxxxx
• [PATCH -mm] cpufreq: BUG: using smp_processor_id() in preemptible code
  • From: Andrea Righi <righi.andrea@xxxxxxxxx>
• cpufreq (kernel?) is not recognising properly my common Intel E6600 processor
  • From: Stéphane Téletchéa <steletch@xxxxxxx>
• cpufreq not recognising my common cpu
  • From: Stéphane Téletchéa <steletch@xxxxxxx>
• Re: [PATCH 2/3] CPUFREQ: powernow-k8: Try to detect old BIOS, not supporting CPU freq on a recent AMD CPUs.
  • From: Pavel Machek <pavel@xxxxxxx>
• Re: [PATCH 1/3] Introduce FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs
  • From: Pavel Machek <pavel@xxxxxxx>
• [PATCH 2/3] CPUFREQ: powernow-k8: Try to detect old BIOS, not supporting CPU freq on a recent AMD CPUs.
  • From: Thomas Renninger <trenn@xxxxxxx>
• Resend: Introduce interface to report BIOS bugs (reworked: FW_BUG simple solution, large description)
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 3/3] ACPI: cpufreq, processor: Detect old BIOS, not supporting CPU freq on a recent CPU.
  • From: Thomas Renninger <trenn@xxxxxxx>
• [PATCH 1/3] Introduce FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: Introduce interface to report BIOS bugs (reworked, FW_BUG simple solution)
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] Introduce FW_BUG and FW_INFO to consistenly tell users about BIOS bugs - with extended description
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: Introduce interface to report BIOS bugs (reworked, FW_BUG simple solution)
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: [PATCH 1/3] Introduce FW_BUG and FW_INFO to consistenly tell users about BIOS bugs
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] Introduce FW_BUG and FW_INFO to consistenly tell users about BIOS bugs
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] Introduce FW_BUG and FW_INFO to consistenly tell users about BIOS bugs
  • From: Thomas Renninger <trenn@xxxxxxx>
• Re: Introduce interface to report BIOS bugs (reworked, FW_BUG simple solution)
  • From: Dave Jones <davej@xxxxxxxxxxxxxxxxx>