Hi,
I notice a regression report on Bugzilla [1] that have been already handled
there. Quoting from it:
> After switching from 6.4.x kernel to 6.5 I experienced an abnormal battery drain since my laptop is actually never idle.
> I accepted default CPUfreq to schedutil and AMD Processor P-State mode is 3 (active).
>
> I expected a different behaviour, but am I missing something?
> In my boot configuration I had "amd_pstate.shared_mem=1" and tried to remove this switch, but did not affect my power consuption.
>
> Is there something changed from 6.4.x to 6.5 that requires a different configuration to get an optimal power consumption?
>
> Thanks a lot for your attention
See Bugzilla for the full thread.
Anyway, I'm adding it to regzbot:
#regzbot introduced: v6.4..v6.5 https://bugzilla.kernel.org/show_bug.cgi?id=217853
Thanks.
--
An old man doll... just what I always wanted! - Clara
On Fri, Sep 08, 2023 at 12:41:14PM +0800, Huang Rui wrote:
> On Fri, Sep 01, 2023 at 05:42:22PM +0800, Bagas Sanjaya wrote:
> > Hi,
> >
> > I notice a regression report on Bugzilla [1] that have been already handled
> > there. Quoting from it:
> >
> > > After switching from 6.4.x kernel to 6.5 I experienced an abnormal battery drain since my laptop is actually never idle.
> > > I accepted default CPUfreq to schedutil and AMD Processor P-State mode is 3 (active).
> > >
> > > I expected a different behaviour, but am I missing something?
> > > In my boot configuration I had "amd_pstate.shared_mem=1" and tried to remove this switch, but did not affect my power consuption.
> > >
> > > Is there something changed from 6.4.x to 6.5 that requires a different configuration to get an optimal power consumption?
> > >
> > > Thanks a lot for your attention
> >
> > See Bugzilla for the full thread.
> >
> > Anyway, I'm adding it to regzbot:
> >
> > #regzbot introduced: v6.4..v6.5 https://bugzilla.kernel.org/show_bug.cgi?id=217853
> >
>
> + Meng Li/Perry,
>
> May we know which CPU type are you using? Try "lscpu"?
>
Sorry for the replying just now.
The reporter (on Bugzilla) had bisected to commit c8afaa1b0f8bc9 ("locking:
remove spin_lock_prefetch"). Telling regzbot:
#regzbot introduced: c8afaa1b0f8bc9
#regzbot title: spin_lock_prefetch() removal causes abnormal battery drain on Ryzen 5500u
Thanks.
--
An old man doll... just what I always wanted! - Clara
On 11/2/23, Bagas Sanjaya <[email protected]> wrote:
> On Fri, Sep 08, 2023 at 12:41:14PM +0800, Huang Rui wrote:
>> On Fri, Sep 01, 2023 at 05:42:22PM +0800, Bagas Sanjaya wrote:
>> > Hi,
>> >
>> > I notice a regression report on Bugzilla [1] that have been already
>> > handled
>> > there. Quoting from it:
>> >
>> > > After switching from 6.4.x kernel to 6.5 I experienced an abnormal
>> > > battery drain since my laptop is actually never idle.
>> > > I accepted default CPUfreq to schedutil and AMD Processor P-State mode
>> > > is 3 (active).
>> > >
>> > > I expected a different behaviour, but am I missing something?
>> > > In my boot configuration I had "amd_pstate.shared_mem=1" and tried to
>> > > remove this switch, but did not affect my power consuption.
>> > >
>> > > Is there something changed from 6.4.x to 6.5 that requires a different
>> > > configuration to get an optimal power consumption?
>> > >
>> > > Thanks a lot for your attention
>> >
>> > See Bugzilla for the full thread.
>> >
>> > Anyway, I'm adding it to regzbot:
>> >
>> > #regzbot introduced: v6.4..v6.5
>> > https://bugzilla.kernel.org/show_bug.cgi?id=217853
>> >
>>
>> + Meng Li/Perry,
>>
>> May we know which CPU type are you using? Try "lscpu"?
>>
>
> Sorry for the replying just now.
>
> The reporter (on Bugzilla) had bisected to commit c8afaa1b0f8bc9 ("locking:
> remove spin_lock_prefetch"). Telling regzbot:
>
> #regzbot introduced: c8afaa1b0f8bc9
> #regzbot title: spin_lock_prefetch() removal causes abnormal battery drain
> on Ryzen 5500u
>
This particular commit is highly unlikely to be causing anything of the sort.
Looking at the bz I suspect the reporter did not follow through with
bisection, to quote:
> Tried to bisect following docs and I had just this output:
> [c8afaa1b0f8bc93d013ab2ea6b9649958af3f1d3] locking: remove spin_lock_prefetch
But that's what one gets when bisection is still in progress.
Final message, should one go through with everything and this commit
indeed was the culprit, would start with this:
> c8afaa1b0f8bc93d013ab2ea6b9649958af3f1d3 is the first bad commit
Perhaps you could help the reporter through building the kernel and
picking good/bad status. I don't know how easily visible the issue is.
--
Mateusz Guzik <mjguzik gmail.com>