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 10 Feb 2010 16:40
On Wed, 10 Feb 2010, Dimitrios Apostolou wrote:
> Hi Arjan,

I have also added Wojo, the user that had the problem, to the CC list so
you can ask him any details you might need.


Dimitris


>
> 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/
From: Arjan van de Ven on 11 Feb 2010 00:00
On Wed, 10 Feb 2010 22:51:38 +0200 (EET)
Dimitrios Apostolou <jimis(a)gmx.net> wrote:


>
>
> 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?

if C3 does not work, this needs to be fixed in the code that implements
C3, not in the code that selects C3.


Modern systems should have working C3; if one does not it needs to be
investigated as to why it's not working. One cause could be a PME that
we're not handling (I've seen that a few times in our lab), lspci -vvv
will show that.

But regardless, it's not the task of the code that selects a C state to
deal with....



--
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 11 Feb 2010 13:10
On Wed, 10 Feb 2010, Arjan van de Ven wrote:
> On Wed, 10 Feb 2010 22:51:38 +0200 (EET)
> Dimitrios Apostolou <jimis(a)gmx.net> wrote:
>>
>> 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?
>
> if C3 does not work, this needs to be fixed in the code that implements
> C3, not in the code that selects C3.
>
>
> Modern systems should have working C3; if one does not it needs to be
> investigated as to why it's not working. One cause could be a PME that
> we're not handling (I've seen that a few times in our lab), lspci -vvv
> will show that.
>
> But regardless, it's not the task of the code that selects a C state to
> deal with....

Wojo (CC'd) can you run as root lspci -vvv and attach the output, so the
experts can have a look?

Arjan, in this case a bisection was not performed but the symptoms are
exactly the same as mine:
* powertop showing thousands of interrups but showing no specific process
causing them
* The situation is caused only when the "processor" module is inserted and
after a message about "marking TSC as unstable due to halts in idle",
exactly like my case

Hmmm actually a difference is that in my case the system used the acpi_pm
clocksource, but in Wojo's case it used hpet.

If I understand correctly what you said, this is a bug in another piece of
code, and I assume that the previous behaviour of the governor was hiding
it, avoiding C3 state completely, right?


Dimitris

>
>
>
> --
> 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: Wojciech Ploskonka on 11 Feb 2010 17:00
On 11.02.2010 19:00, Dimitrios Apostolou wrote:
> On Wed, 10 Feb 2010, Arjan van de Ven wrote:
>> On Wed, 10 Feb 2010 22:51:38 +0200 (EET)
>> Dimitrios Apostolou <jimis(a)gmx.net> wrote:
>>>
>>> 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?
>>
>> if C3 does not work, this needs to be fixed in the code that implements
>> C3, not in the code that selects C3.
>>
>>
>> Modern systems should have working C3; if one does not it needs to be
>> investigated as to why it's not working. One cause could be a PME that
>> we're not handling (I've seen that a few times in our lab), lspci -vvv
>> will show that.
>>
>> But regardless, it's not the task of the code that selects a C state to
>> deal with....
>
> Wojo (CC'd) can you run as root lspci -vvv and attach the output, so the
> experts can have a look?
>
> Arjan, in this case a bisection was not performed but the symptoms are
> exactly the same as mine:
> * powertop showing thousands of interrups but showing no specific
> process causing them
> * The situation is caused only when the "processor" module is inserted
> and after a message about "marking TSC as unstable due to halts in
> idle", exactly like my case
>
> Hmmm actually a difference is that in my case the system used the
> acpi_pm clocksource, but in Wojo's case it used hpet.
>
> If I understand correctly what you said, this is a bug in another piece
> of code, and I assume that the previous behaviour of the governor was
> hiding it, avoiding C3 state completely, right?

Sure Dimitris.
You can find lspci -vvv output from that unfortunate laptop in attachments.

--
Sincerely Yours,
Wojciech 'Wojo' Płoskonka

From: Arjan van de Ven on 12 Feb 2010 00:30
On Thu, 11 Feb 2010 22:58:21 +0100
Wojciech Ploskonka <wploskonka(a)gmail.com> wrote:

> 08:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394
> Controller (rev 05) (prog-if 10 [OHCI])

08:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(rev 05) (prog-if 10 [OHCI])

is the one having PME+ set.

Len: how do we handle PME's again?


--
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/
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