Dear Rafael,
I just recognized that I did not really describe the problem that my patch
fixes. Therefore I attached the output of following command after disconnecting
the AC power without and with my patch:
grep -r "" /sys/devices/system/cpu/cpu0/cpuidle/
One can clearly see that some information is missing and the C3 state is not
used.
Kind regards,
Thomas
Am Freitag, 18. Januar 2013, 21:34:29 schrieb Thomas Schlichter:
> Dear Rafael,
>
> thank you for applying Daniel's patch. I tested 3.8-rc4 and found that one
> patch ist still missing to fix the problem of not usable C-state after
> disconnect. I had it attached with my last e-mail as patch 1. For your
> conveniency, I have attached it here again.
>
> With that patch the problem is fixed for me. So please consider applying
> this, too.
>
> Kind regards,
> Thomas
>
> Am Sonntag, 13. Januar 2013, 21:04:45 schrieb Rafael J. Wysocki:
> > On Sunday, January 13, 2013 03:41:34 PM Daniel Lezcano wrote:
> > > On 01/13/2013 01:34 PM, Thomas Schlichter wrote:
> > > > Hi,
> > > >
> > > > there is a long-standing regression about new C-states not working
> > > > after
> > > > disconnecting AC power from a laptop if the cpuidle driver "acpi-idle"
> > > > is
> > > > used. It was reported here:
> > > >
> > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=42870 (March 5th
> > > > 2012)
> > > > [2] https://bugzilla.kernel.org/show_bug.cgi?id=43349 (June 7th 2012)
> > > > [3] https://lkml.org/lkml/2012/10/16/518 (October 19th 2012)
> > > >
> > > > In [1] Andreas proposed a patch that initialized the missing
> > > > power_usage
> > > > values from within acpi_idle in the same way as cpuidle does.
> > > > In [2] I proposed a patch to use the power values provided by ACPI to
> > > > initialize the power_usage variables.
> > > > In [3] Julius proposed a patch to call the initialization function
> > > > set_power_states() not only once, but always when the C-states
> > > > change.
> > > >
> > > > Currently, Daniel Lezcano seems to be working on an intrusive change
> > > > of
> > > > not
> > > > using the power_usage value at all for choosing a C-state:
> > > >
> > > > [4] https://lkml.org/lkml/2012/12/14/155
> > > >
> > > > As I could not find any of these patches in any git trees to be merged
> > > > for
> > > > 3.8, I propose an other, least intrusive patch for the time being. It
> > > > is
> > > > attached an initializes _all_ power_usage values in the first place.
> > > >
> > > > As this is a real power consumption regression since 3.2, I really ask
> > > > you to apply anything and push it to stable, too!
> > >
> > > Rafael, is possible to apply the patch [1/2] I previously sent ?
> > >
> > > https://patchwork.kernel.org/patch/1878691/
> >
> > I need to talk about this with Len. That should happen tomorrow if
> > everything goes well.
> >
> > > So we get this bug fixed.
> > >
> > > I will resend the patch [2/2] as soon as possible.
> >
> > OK
> >
> > Thanks,
> > Rafael
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu0/cpuidle/state0/time:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI HLT
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/time:147579
/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage:42
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI IOPORT 0x4014
/sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2
/sys/devices/system/cpu/cpu0/cpuidle/state2/time:36250374
/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage:2867
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1
/sys/devices/system/cpu/cpu0/cpuidle/state3/desc:<null>
/sys/devices/system/cpu/cpu0/cpuidle/state3/name:<null>
/sys/devices/system/cpu/cpu0/cpuidle/state3/time:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/usage:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu0/cpuidle/state0/time:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage:0
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI HLT
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/time:4644
/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage:35
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI IOPORT 0x4014
/sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2
/sys/devices/system/cpu/cpu0/cpuidle/state2/time:44430
/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage:52
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1
/sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI IOPORT 0x4016
/sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3
/sys/devices/system/cpu/cpu0/cpuidle/state3/time:25798363
/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/power:0
/sys/devices/system/cpu/cpu0/cpuidle/state3/usage:1826
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency:146
