Prev: Make Intel 8-way Xeons boot again
Next: [tip:x86/uv] x86, uv: uv_global_gru_mmr_address() macro fix
From: Dimitrios Apostolou on 9 Jan 2010 20:10
On Sat, 9 Jan 2010, Arjan van de Ven wrote:

> On Sun, 10 Jan 2010 02:32:11 +0200 (EET)
> Dimitrios Apostolou <jimis(a)gmx.net> wrote:
>
>> On Sat, 9 Jan 2010, Arjan van de Ven wrote:
>>
>>> On Sun, 10 Jan 2010 01:55:42 +0200 (EET)
>>> Dimitrios Apostolou <jimis(a)gmx.net> wrote:
>>>
>>>> L8400B series Notebook PC
>>>
>>> can you try this patch?
>>>
>>
>> OK I'm compiling a new kernel right now but that will take a while, I
>> only have access to old hardware at the moment... What exactly this
>> patch does?
>>
>
> basically it appears that your machine, when the kernel asks for C2,
> exits C2 immediately again.
>
> The old algorithm somehow caught this and stopped asking for C2 most of
> the time; the new algorithm doesn't see any activity and asks for C2
> again.
>
> What the patch does is tell the kernel to just not use C2 at all...

Indeed, in the past powertop always showed my processor idling in C1
state, and I wondered why it never entered C2. :-)

So thanks for the patch, I guess it works, and my bet is that this
case applies to L8400* (not only B models), except if it is fixed by some
old BIOS upgrade that I must have missed.

While testing your patch, indeed the temperature was not rising and
everything was normal, but the tsc was not marked as unstable so it didn't
switch to acpi_pm clocksource, so that was probably the reason.


Dimitris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 9 Jan 2010 20:40
On Sun, 10 Jan 2010 03:05:38 +0200 (EET)
Dimitrios Apostolou <jimis(a)gmx.net> wrote:

>
> So thanks for the patch, I guess it works, and my bet is that this
> case applies to L8400* (not only B models), except if it is fixed by
> some old BIOS upgrade that I must have missed.
>
> While testing your patch, indeed the temperature was not rising and
> everything was normal, but the tsc was not marked as unstable so it
> didn't switch to acpi_pm clocksource, so that was probably the reason.

that's a feature ;-)

tsc is much nicer than acpi_pm.

now, if you have working C2 you get power savings back for going the
going-back-to-acpi_pm... but since for you, C2 doesn't.... you're now
much better off ...


--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 12 Jan 2010 19:10
On Sun, 10 Jan 2010 03:05:38 +0200 (EET)
Dimitrios Apostolou <jimis(a)gmx.net> wrote:

> On Sat, 9 Jan 2010, Arjan van de Ven wrote:
>
> > On Sun, 10 Jan 2010 02:32:11 +0200 (EET)
> > Dimitrios Apostolou <jimis(a)gmx.net> wrote:
> >
> >> On Sat, 9 Jan 2010, Arjan van de Ven wrote:
> >>
> >>> On Sun, 10 Jan 2010 01:55:42 +0200 (EET)
> >>> Dimitrios Apostolou <jimis(a)gmx.net> wrote:
> >>>
> >>>> L8400B series Notebook PC
> >>>
> >>> can you try this patch?
> >>>
> >>
> >> OK I'm compiling a new kernel right now but that will take a while, I
> >> only have access to old hardware at the moment... What exactly this
> >> patch does?
> >>
> >
> > basically it appears that your machine, when the kernel asks for C2,
> > exits C2 immediately again.
> >
> > The old algorithm somehow caught this and stopped asking for C2 most of
> > the time; the new algorithm doesn't see any activity and asks for C2
> > again.
> >
> > What the patch does is tell the kernel to just not use C2 at all...
>
> Indeed, in the past powertop always showed my processor idling in C1
> state, and I wondered why it never entered C2. :-)
>
> So thanks for the patch, I guess it works, and my bet is that this
> case applies to L8400* (not only B models), except if it is fixed by some
> old BIOS upgrade that I must have missed.
>
> While testing your patch, indeed the temperature was not rising and
> everything was normal, but the tsc was not marked as unstable so it didn't
> switch to acpi_pm clocksource, so that was probably the reason.
>

Arjan, can you please prepare a formal version of the fix? I guess the
cc:stable will be needed as well.

I assume that the effects which Dimitrios described above were the
intended ones?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 13 Jan 2010 00:40
On Tue, 12 Jan 2010 16:07:34 -0800
Andrew Morton <akpm(a)linux-foundation.org> wrote:

> > While testing your patch, indeed the temperature was not rising and
> > everything was normal, but the tsc was not marked as unstable so it
> > didn't switch to acpi_pm clocksource, so that was probably the
> > reason.
> >
>
> Arjan, can you please prepare a formal version of the fix? I guess
> the cc:stable will be needed as well.

sure see below
>
> I assume that the effects which Dimitrios described above were the
> intended ones?

yes absolutely; having a stable tsc is a good thing, and totally expected
if you don't have C2.


Subject: Add two laptops to the C-state DMI table
From: Arjan van de Ven <arjan(a)linux.intel.com>

CC: stable(a)kernel.org

Since the rewrite of the CPU idle governor in 2.6.32, two laptops have surfaced
where the BIOS advertises a C2 power state, but for some reason this state is not
functioning (as verified in both cases by powertop before the patch in .32).

The old governor had the accidental behavior that if a non-working state was chosen
too many times, it would end up falling back to C1. The new governor works differently
and this accidental behavior is no longer there; the result is a high temperature
on these two machines.

This patch adds these 2 machines to the DMI table for C state anomalies; by just not using
C2 both these machines are better off (the TSC can be used instead of the pm timer, giving
a performance boost for example).

Signed-off-by: Arjan van de Ven <arjan(a)linux.intel.com>



diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index d1676b1..6c3145b 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -110,6 +110,14 @@ static struct dmi_system_id __cpuinitdata processor_power_dmi_table[] = {
DMI_MATCH(DMI_BIOS_VENDOR,"Phoenix Technologies LTD"),
DMI_MATCH(DMI_BIOS_VERSION,"SHE845M0.86C.0013.D.0302131307")},
(void *)2},
+ { set_max_cstate, "Pavilion zv5000", {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME,"Pavilion zv5000 (DS502A#ABA)")},
+ (void *)1},
+ { set_max_cstate, "Asus L8400B", {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME,"L8400B series Notebook PC")},
+ (void *)1},
{},
};






--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dimitrios Apostolou on 10 Feb 2010 15:50
Hi Arjan,

it seems that the changes inside processor module have bitten another
user, see relevant thread at archlinux bugtracker:
http://bugs.archlinux.org/task/17771

It can be summarised with the following quote:


I've tested jimis's suggestion about booting with init=/bin/sh and later
modprobing next modules.
I confirm that module called "processor" in any kernel26 2.6.32.* is a
root problem of high power consumption.
Here's output of modprobing it:

ACPI: SSDT 000000003f6d94fb 00238 (v01 PmRef Cpu0Ist 000003000 INTL
20050624)
ACPI: SSDT 000000003f6d8e8c 005EA (v01 PmRef Cpu0Cst 000003001 INTL
20050624)
Marking TSC unstable due to TSC halts in idle
processor LNXCPU:00: registered as cooling_device0
ACPI: SSDT 000000003f6d9733 000C8(v01 PmRef Cpu1Ist 000003000 INTL
20050624)
ACPI: SSDT 00000000376d9476 00085 (v01 PmRef Cpu1Cst 000003000 INTL
20050624)
Swtiching to clocksource hpet
processor LNXCPU:01: registered as cooling_device1



As I understand, in his case the C3 state is unstable and exits
immediately. I have asked him to post the dmidecode output so you can put
him on the exception list too. However I now believe that more and more
users will be facing the same problem, it's not something you find easily,
especially on desktop machines! What do you think?


Thanks,
Dimitris


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Make Intel 8-way Xeons boot again
Next: [tip:x86/uv] x86, uv: uv_global_gru_mmr_address() macro fix