[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <50F68E4902000078000B61AC@nat28.tlf.novell.com>
Date: Wed, 16 Jan 2013 10:26:01 +0000
From: "Jan Beulich" <JBeulich@...e.com>
To: "Stefan Bader" <stefan.bader@...onical.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Cc: "Borislav Petkov" <bp@...en8.de>,
"Andre Przywara" <andre@...rep.de>,
"xen-devel" <xen-devel@...ts.xen.org>,
"Matthew Garrett" <mjg@...hat.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] kernel 3.7+ cpufreq regression on AMD system
running as dom0
>>> On 15.01.13 at 18:53, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> On Mon, Jan 14, 2013 at 05:34:45PM +0100, Borislav Petkov wrote:
>> On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
>> > --- a/drivers/acpi/processor_perflib.c
>> > +++ b/drivers/acpi/processor_perflib.c
>> > @@ -340,6 +340,9 @@ static void amd_fixup_frequency(struct acpi_processor_px *px
>> > if ((boot_cpu_data.x86 == 0x10 && boot_cpu_data.x86_model < 10)
>> > || boot_cpu_data.x86 == 0x11) {
>> > rdmsr(MSR_AMD_PSTATE_DEF_BASE + index, lo, hi);
>> > + /* Bit 63 indicates whether contents are valid */
>> > + if (!(hi & 0x8000000))
>> > + return;
>>
>> I don't think that's the right change - this is fixing baremetal so that
>> it works on xen. And besides, this code was in powernow-k8 before so I'm
>> wondering why did it work then.
>
> Powernow-k8 only populated the cpufreq policy information. This library
> (processor_perflib) is the generic library used for ACPI P-states parsing.
> This specific function (acpi_processor_get_performance_states) is just
> used to fetch and parse the P-states.
>
> Xen-acpi-processor (which we use to upload the P and C-states to the
> hypervisor) ends up calling this library to parse the P-states
> and this unfortunate quirk clamps the P-states based on the MSRS.
>
> It is odd that this CPU specific quirk got added in this generic
> library. Is there no ACPI quirk system similar to how DMI quirks
> are handled?
>
> Anyhow, I think this patch makes sense - it makes sure that the
> MSR value is sane.
>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Did someone actually _test_ that patch? I ask because the mask
used (0x8000000) doesn't check bit 63 as the comment says, but
bit 59 instead...
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists