mbox series

[SRU,H,I,0/2] cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline

Message ID 20211115184339.68847-1-philip.cox@canonical.com
Headers show
Series cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline | expand

Message

Philip Cox Nov. 15, 2021, 6:43 p.m. UTC 
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

BugLink: https://bugs.launchpad.net/bugs/1950584

[Impact]

"Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
 ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
 desired values in certain usage scenarios, but it did not prevent
 them from being leaked into the confugirations in which HWP desired
 is expected to be 0"

I believe I'm seeing this issue on my laptop during suspend/resume. The upstream fix is:

commit dbea75fe18f60e364de6d994fc938a24ba249d81
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Wed Nov 3 19:43:47 2021 +0100

    cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline

[Fix]

dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline

Comments

Kleber Sacilotto de Souza Nov. 16, 2021, 11:15 a.m. UTC | #1 
On 15.11.21 19:43, Philip Cox wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1950584
> 
> [Impact]
> 
> "Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
>   ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
>   desired values in certain usage scenarios, but it did not prevent
>   them from being leaked into the confugirations in which HWP desired
>   is expected to be 0"
> 
> I believe I'm seeing this issue on my laptop during suspend/resume. The upstream fix is:
> 
> commit dbea75fe18f60e364de6d994fc938a24ba249d81
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date: Wed Nov 3 19:43:47 2021 +0100
> 
>      cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
> 
> [Fix]
> 
> dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
> 
> 

The SRU template has a section "[Where problems could occur]" to be used
to describe what is the regression potential and how problems would show
up in case there are issues with this patch (please see [1]). You don't
need to resubmit the patchset to include it, but it would be nice to
have some quick analysis added to the launchpad bug report.

Apart from it there's also a typo in one of the patches that can be
fixed by the person applying the patch.


Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

Thanks!



[1] https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
Tim Gardner Nov. 16, 2021, 12:38 p.m. UTC | #2 
Commit dbea75fe18f60e364de6d994fc938a24ba249d81 is a clean cherry-pick 
to both repos. We only use 'backported' when there is a conflict. As 
Stefan mentioned, always provide a brief description of the conflict 
resolution after your S-O-B. Otherwise 'git cherry-pick -s -x' leaves 
the right info in the patch, though you still have to add the BugLink. 
See kteam-tools/maintscripts/maint-modify-patch for that.

When sending version 2 be sure to note that in the subject, e.g., " 
[SRU][H, I][PATCH 0/2 v2] cpufreq: intel_pstate: Clear HWP desired on 
suspend/shutdown and offline".

As with an upstream patch, note in the patch description what the 
changes were from v1-->v2.

rtg

On 11/15/21 11:43 AM, Philip Cox wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1950584
> 
> [Impact]
> 
> "Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
>   ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
>   desired values in certain usage scenarios, but it did not prevent
>   them from being leaked into the confugirations in which HWP desired
>   is expected to be 0"
> 
> I believe I'm seeing this issue on my laptop during suspend/resume. The upstream fix is:
> 
> commit dbea75fe18f60e364de6d994fc938a24ba249d81
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date: Wed Nov 3 19:43:47 2021 +0100
> 
>      cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
> 
> [Fix]
> 
> dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
> 
>
Kleber Sacilotto de Souza Nov. 16, 2021, 2:35 p.m. UTC | #3 
Hey Tim,

On 16.11.21 13:38, Tim Gardner wrote:
> Commit dbea75fe18f60e364de6d994fc938a24ba249d81 is a clean cherry-pick
> to both repos. We only use 'backported' when there is a conflict. As

It was me who instructed Phil to send them as "backported from ..." and
in two patches because the same version cannot be applied to both trees.

These patches are not a clean cherry-picks in the meaning that we use it,
which is somewhat different from upstream.

Our general rule is that if you can create a patch from that original sha1
with "git format-patch" and apply it with "git am" on the destination
tree that would be considered a "cherry picked from ...". Otherwise,
if you need to make any changes, including context adjustments, it's
considered a "backported from ...".


Kleber

> Stefan mentioned, always provide a brief description of the conflict
> resolution after your S-O-B. Otherwise 'git cherry-pick -s -x' leaves
> the right info in the patch, though you still have to add the BugLink.
> See kteam-tools/maintscripts/maint-modify-patch for that.
> 
> When sending version 2 be sure to note that in the subject, e.g., "
> [SRU][H, I][PATCH 0/2 v2] cpufreq: intel_pstate: Clear HWP desired on
> suspend/shutdown and offline".
> 
> As with an upstream patch, note in the patch description what the
> changes were from v1-->v2.
> 
> rtg
> 
> On 11/15/21 11:43 AM, Philip Cox wrote:
>> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>>
>> BugLink: https://bugs.launchpad.net/bugs/1950584
>>
>> [Impact]
>>
>> "Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
>>    ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
>>    desired values in certain usage scenarios, but it did not prevent
>>    them from being leaked into the confugirations in which HWP desired
>>    is expected to be 0"
>>
>> I believe I'm seeing this issue on my laptop during suspend/resume. The upstream fix is:
>>
>> commit dbea75fe18f60e364de6d994fc938a24ba249d81
>> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> Date: Wed Nov 3 19:43:47 2021 +0100
>>
>>       cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
>>
>> [Fix]
>>
>> dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline
>>
>>
>
Philip Cox Nov. 16, 2021, 2:38 p.m. UTC | #4 
I have spoken to Tim, and I have got a cherry-pick to work cleanly for both
hirsute and impish where the format-patch/am didn't.  I am working on
sending out a v2 of this change.

On Tue, Nov 16, 2021 at 9:35 AM Kleber Souza <kleber.souza@canonical.com>
wrote:

> Hey Tim,
>
> On 16.11.21 13:38, Tim Gardner wrote:
> > Commit dbea75fe18f60e364de6d994fc938a24ba249d81 is a clean cherry-pick
> > to both repos. We only use 'backported' when there is a conflict. As
>
> It was me who instructed Phil to send them as "backported from ..." and
> in two patches because the same version cannot be applied to both trees.
>
> These patches are not a clean cherry-picks in the meaning that we use it,
> which is somewhat different from upstream.
>
> Our general rule is that if you can create a patch from that original sha1
> with "git format-patch" and apply it with "git am" on the destination
> tree that would be considered a "cherry picked from ...". Otherwise,
> if you need to make any changes, including context adjustments, it's
> considered a "backported from ...".
>
>
> Kleber
>
> > Stefan mentioned, always provide a brief description of the conflict
> > resolution after your S-O-B. Otherwise 'git cherry-pick -s -x' leaves
> > the right info in the patch, though you still have to add the BugLink.
> > See kteam-tools/maintscripts/maint-modify-patch for that.
> >
> > When sending version 2 be sure to note that in the subject, e.g., "
> > [SRU][H, I][PATCH 0/2 v2] cpufreq: intel_pstate: Clear HWP desired on
> > suspend/shutdown and offline".
> >
> > As with an upstream patch, note in the patch description what the
> > changes were from v1-->v2.
> >
> > rtg
> >
> > On 11/15/21 11:43 AM, Philip Cox wrote:
> >> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/1950584
> >>
> >> [Impact]
> >>
> >> "Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
> >>    ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
> >>    desired values in certain usage scenarios, but it did not prevent
> >>    them from being leaked into the confugirations in which HWP desired
> >>    is expected to be 0"
> >>
> >> I believe I'm seeing this issue on my laptop during suspend/resume. The
> upstream fix is:
> >>
> >> commit dbea75fe18f60e364de6d994fc938a24ba249d81
> >> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >> Date: Wed Nov 3 19:43:47 2021 +0100
> >>
> >>       cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and
> offline
> >>
> >> [Fix]
> >>
> >> dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear
> HWP desired on suspend/shutdown and offline
> >>
> >>
> >
>
>