[regression] ath11k broken in v6.7

[regression] ath11k broken in v6.7

[Kalle Valo]

Hi,

Just trying to make everyone aware because I suspect this will affect
quite a few people: ath11k is crashing during suspend on v6.7 due to a
mac80211 patch, more info:

https://bugzilla.kernel.org/show_bug.cgi?id=218364

Proposed fix:

https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/

Kalle

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> writes:

> Just trying to make everyone aware because I suspect this will affect
> quite a few people: ath11k is crashing during suspend on v6.7 due to a
> mac80211 patch, more info:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=218364
>
> Proposed fix:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/

The fix is now applied:

https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc

I'll try to use regzbot for the first time, let's see how it goes:

#regzbot introduced: 0a3d898ee9a8 ^

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> writes:

> Kalle Valo <kvalo@kernel.org> writes:
>
>> Just trying to make everyone aware because I suspect this will affect
>> quite a few people: ath11k is crashing during suspend on v6.7 due to a
>> mac80211 patch, more info:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=218364
>>
>> Proposed fix:
>>
>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>
> The fix is now applied:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>
> I'll try to use regzbot for the first time, let's see how it goes:
>
> #regzbot introduced: 0a3d898ee9a8 ^

Forgot to include the bug report:

#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> writes:

> Kalle Valo <kvalo@kernel.org> writes:
>
>> Kalle Valo <kvalo@kernel.org> writes:
>>
>>> Just trying to make everyone aware because I suspect this will affect
>>> quite a few people: ath11k is crashing during suspend on v6.7 due to a
>>> mac80211 patch, more info:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=218364
>>>
>>> Proposed fix:
>>>
>>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>>
>> The fix is now applied:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>>
>> I'll try to use regzbot for the first time, let's see how it goes:
>>
>> #regzbot introduced: 0a3d898ee9a8 ^
>
> Forgot to include the bug report:
>
> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364

#regzbot fix: 556857aa1d0855aba02b1c63bc52b91ec63fc2cc

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Linux regression tracking (Thorsten Leemhuis)]

On 22.01.24 08:36, Kalle Valo wrote:
> Kalle Valo <kvalo@kernel.org> writes:
>> Kalle Valo <kvalo@kernel.org> writes:
>>> Kalle Valo <kvalo@kernel.org> writes:
>>>
>>>> Just trying to make everyone aware because I suspect this will affect
>>>> quite a few people: ath11k is crashing during suspend on v6.7 due to a
>>>> mac80211 patch, more info:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=218364

Many thx for the heads up, much appreciated. Sorry, forgot to add it to
the tracking myself: during the merge window thing are sometimes a bit
chaotic for myself as well. And I was head-down in rewriting some parts
of regzbot (see below).

>>>> Proposed fix:
>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>>>
>>> The fix is now applied:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>>>
>>> I'll try to use regzbot for the first time, let's see how it goes:
>>>
>>> #regzbot introduced: 0a3d898ee9a8 ^
>>
>> Forgot to include the bug report:
>>
>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364

FWIW, that usage was slightly off and not how it's supposed to be done.
But whatever, let's ignore that. I'm reworking things currently
slightly, as you are not the first one that slightly got mislead -- and
the newer commands will hopefully be mire intuitive.

> #regzbot fix: 556857aa1d0855aba02b1c63bc52b91ec63fc2cc

Great, thx. Hope it reached mainline soon. Maybe once it's there you or
I should tell Greg to pick this up quickly for stable given that it
apparently "might affect quite a few people".

Thx again!

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

"Linux regression tracking (Thorsten Leemhuis)"
<regressions@leemhuis.info> writes:

> On 22.01.24 08:36, Kalle Valo wrote:
>> Kalle Valo <kvalo@kernel.org> writes:
>>> Kalle Valo <kvalo@kernel.org> writes:
>>>> Kalle Valo <kvalo@kernel.org> writes:
>>>>
>>>>> Just trying to make everyone aware because I suspect this will affect
>>>>> quite a few people: ath11k is crashing during suspend on v6.7 due to a
>>>>> mac80211 patch, more info:
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=218364
>
> Many thx for the heads up, much appreciated. Sorry, forgot to add it to
> the tracking myself: during the merge window thing are sometimes a bit
> chaotic for myself as well. And I was head-down in rewriting some parts
> of regzbot (see below).

No worries, this was a good time to learn all this myself.

>>>>> Proposed fix:
>>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>>>>
>>>> The fix is now applied:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>>>>
>>>> I'll try to use regzbot for the first time, let's see how it goes:
>>>>
>>>> #regzbot introduced: 0a3d898ee9a8 ^
>>>
>>> Forgot to include the bug report:
>>>
>>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364
>
> FWIW, that usage was slightly off and not how it's supposed to be done.
> But whatever, let's ignore that. I'm reworking things currently
> slightly, as you are not the first one that slightly got mislead -- and
> the newer commands will hopefully be mire intuitive.

Just to educate myself, how should I have done it? (But feel free to
skip the question if you are busy)

>> #regzbot fix: 556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>
> Great, thx. Hope it reached mainline soon. Maybe once it's there you or
> I should tell Greg to pick this up quickly for stable given that it
> apparently "might affect quite a few people".

I'll try to remember that but the thing is that I don't really follow
stable releases. I wish there would be a person who could follow stable
releases from wireless perspective and make sure everything is ok there.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Thorsten Leemhuis]

On 22.01.24 09:24, Kalle Valo wrote:
> "Linux regression tracking (Thorsten Leemhuis)"
> <regressions@leemhuis.info> writes:
>> On 22.01.24 08:36, Kalle Valo wrote:
>>> Kalle Valo <kvalo@kernel.org> writes:
>>>> Kalle Valo <kvalo@kernel.org> writes:
>>>>> Kalle Valo <kvalo@kernel.org> writes:
>>>>>>
>>>>>> Proposed fix:
>>>>>> https://patchwork.kernel.org/project/linux-wireless/patch/20240111170629.1257217-1-benjamin@sipsolutions.net/
>>>>> The fix is now applied:
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=556857aa1d0855aba02b1c63bc52b91ec63fc2cc
>>>>> I'll try to use regzbot for the first time, let's see how it goes:
>>>>> #regzbot introduced: 0a3d898ee9a8 ^
>>>> Forgot to include the bug report:
>>>>
>>>> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218364
>>
>> FWIW, that usage was slightly off and not how it's supposed to be done.
>> But whatever, let's ignore that. I'm reworking things currently
>> slightly, as you are not the first one that slightly got mislead -- and
>> the newer commands will hopefully be mire intuitive.
> 
> Just to educate myself, how should I have done it? (But feel free to
> skip the question if you are busy)

I think that's not worth it, as I hope to introduce the new commands in
the near future (but you know how it is with the last 5 to 10
percent...). But let me show you how it's then supposed to be done in
this situation, that way you can give early feedback:

  #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218364
  #regzbot introduced: 0a3d898ee9a8

That "#regzbot report" will be new and make it more obvious to users
what regzbot should consider to be the report (e.g. what Link:/Closes:
tags later in commits fixing the issue will link to). You used "#regzbot
introduced: 0a3d898ee9a8 ^" and due to the "^" it assumed the start of
this thread would be the report (side note: mixing that aspect into the
"introduced" command was a stupid idea anyway.).

That "#regzbot link:" will vanish as well (at least from the docs, it
will remain to be supported), as people use it wrong in various
different ways: for duplicates, reports (like your did), patch
submissions fixing the issue (then 'regzbot monitor' should have been
used) among others. Which is totally understandable now that I look at
it. That's why it will be replaced by "#regzbot related: <url>" to avoid
any connection with the Link: tag used in commits; for duplicates
"#regzbot dup:" will stay around.

>> Great, thx. Hope it reached mainline soon. Maybe once it's there you or
>> I should tell Greg to pick this up quickly for stable given that it
>> apparently "might affect quite a few people".
> I'll try to remember that but the thing is that I don't really follow
> stable releases.

Let me do it, it's easy for me. And FWIW, I don't even follow the stable
releases for that, I just drop Greg a mail when I notice the patch
reached mainline through the weekly net merge. He'll take care of the rest.

> I wish there would be a person who could follow stable
> releases from wireless perspective and make sure everything is ok there.

Maybe at some point regression tracking can help somewhat with that. But
I still have to fix a few things to make people use it and scale it up.

Side note: some people seem to have gotten the impression that I care a
lot about *all* stable/longterm kernels. Let me use this opportunity to
say that it's not really the case. I fully understand and respect that
those series are a somewhat separate thing some developers don't want to
be involved in (especially the older trees). But the thing is: the
latest stable tree is what we tell users to use -- and something quite a
few important distros ship as their regular kernel these days. That's
why I take special care of regression that found there.

Ciao, Thorsten

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

> On 22.01.24 09:24, Kalle Valo wrote:
>> "Linux regression tracking (Thorsten Leemhuis)"
>> <regressions@leemhuis.info> writes:
>>
>>> FWIW, that usage was slightly off and not how it's supposed to be done.
>>> But whatever, let's ignore that. I'm reworking things currently
>>> slightly, as you are not the first one that slightly got mislead -- and
>>> the newer commands will hopefully be mire intuitive.
>> 
>> Just to educate myself, how should I have done it? (But feel free to
>> skip the question if you are busy)
>
> I think that's not worth it, as I hope to introduce the new commands in
> the near future (but you know how it is with the last 5 to 10
> percent...).

I sure do know :) I assume you will announce in the regressions list
once the new interface is available, I'll then take a look at it in
detail and update my notes.

> But let me show you how it's then supposed to be done in this
> situation, that way you can give early feedback:
>
>   #regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218364
>   #regzbot introduced: 0a3d898ee9a8
>
> That "#regzbot report" will be new and make it more obvious to users
> what regzbot should consider to be the report (e.g. what Link:/Closes:
> tags later in commits fixing the issue will link to).

Thanks, this looks very intuitive to me.

> You used "#regzbot introduced: 0a3d898ee9a8 ^" and due to the "^" it
> assumed the start of this thread would be the report

Actually I did that on purpose as I wanted to test how including a mail
to a regression report works :)

> (side note: mixing that aspect into the "introduced" command was a
> stupid idea anyway.).
>
> That "#regzbot link:" will vanish as well (at least from the docs, it
> will remain to be supported), as people use it wrong in various
> different ways: for duplicates, reports (like your did), patch
> submissions fixing the issue (then 'regzbot monitor' should have been
> used) among others. Which is totally understandable now that I look at
> it. That's why it will be replaced by "#regzbot related: <url>" to avoid
> any connection with the Link: tag used in commits; for duplicates
> "#regzbot dup:" will stay around.

So, in the new interface, how should I handle a situation that a
regression is first reported on the mailing list, added to regzbot and
later there's also a bug report opened for the issue?

>> I wish there would be a person who could follow stable
>> releases from wireless perspective and make sure everything is ok there.
>
> Maybe at some point regression tracking can help somewhat with that. But
> I still have to fix a few things to make people use it and scale it up.

I just feel it should be more than that, I'm worried that randomly
taking wireless commits to stable releases is risky. There really should
be someone looking after wireless (read: reviewing patches) in stable
releases. This would be a good role for someone who is interested to
learn how kernel.org development works and helping the community. Do we
have a way to announce these kind volunteer vacancies somewhere? :)

> Side note: some people seem to have gotten the impression that I care a
> lot about *all* stable/longterm kernels. Let me use this opportunity to
> say that it's not really the case. I fully understand and respect that
> those series are a somewhat separate thing some developers don't want to
> be involved in (especially the older trees). But the thing is: the
> latest stable tree is what we tell users to use -- and something quite a
> few important distros ship as their regular kernel these days. That's
> why I take special care of regression that found there.

Yeah, I understand that a lot of users use stable kernel releases. But
the reality is that we in wireless really don't have the bandwidth to
manage stable kernels, it is enough of a challenge to manage Linus'
releases. So help here is very much needed.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Thorsten Leemhuis]

On 29.01.24 12:33, Kalle Valo wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> writes:
>> On 22.01.24 09:24, Kalle Valo wrote:
>>> "Linux regression tracking (Thorsten Leemhuis)"
>>> <regressions@leemhuis.info> writes:
>>
>> That "#regzbot link:" will vanish as well (at least from the docs, it
>> will remain to be supported), as people use it wrong in various
>> different ways: for duplicates, reports (like your did), patch
>> submissions fixing the issue (then 'regzbot monitor' should have been
>> used) among others. Which is totally understandable now that I look at
>> it. That's why it will be replaced by "#regzbot related: <url>" to avoid
>> any connection with the Link: tag used in commits; for duplicates
>> "#regzbot dup:" will stay around.
> 
> So, in the new interface, how should I handle a situation that a
> regression is first reported on the mailing list, added to regzbot and
> later there's also a bug report opened for the issue?

You will have to options: reply to the first report with a "#regzbot
duplicate https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542"
or add a comment to the bugzilla ticket pointing to a report already
tracked by regzbot, e.g. "#regzbot duplicate
https://lore.kernel.org/not_relevant/msgid-423423423423423423/"

>>> I wish there would be a person who could follow stable
>>> releases from wireless perspective and make sure everything is ok there.
>> Maybe at some point regression tracking can help somewhat with that. But
>> I still have to fix a few things to make people use it and scale it up.
> I just feel it should be more than that, I'm worried that randomly
> taking wireless commits to stable releases is risky. There really should
> be someone looking after wireless (read: reviewing patches) in stable
> releases. This would be a good role for someone who is interested to
> learn how kernel.org development works and helping the community. Do we
> have a way to announce these kind volunteer vacancies somewhere? :)

Not that I know of. Guess kernelnewbies might be the best place for that
(and maybe they have something like that already...).

Ciao, Thorsten

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

Thorsten Leemhuis <regressions@leemhuis.info> writes:

>> So, in the new interface, how should I handle a situation that a
>> regression is first reported on the mailing list, added to regzbot and
>> later there's also a bug report opened for the issue?
>
> You will have to options: reply to the first report with a "#regzbot
> duplicate https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542"
> or add a comment to the bugzilla ticket pointing to a report already
> tracked by regzbot, e.g. "#regzbot duplicate
> https://lore.kernel.org/not_relevant/msgid-423423423423423423/"

Oh, regzbot also follows bugzilla comments? Didn't know that, very nice.

One more question, I promise it's the last one :) When using the Closes
tag in patches does it matter which URL is used, either the original or
the duplicate? For example, do these both tags close the issue:

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542
Closes: https://lore.kernel.org/not_relevant/msgid-423423423423423423/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [regression] ath11k broken in v6.7

[Linux regression tracking (Thorsten Leemhuis)]

On 02.02.24 11:45, Kalle Valo wrote:
> Thorsten Leemhuis <regressions@leemhuis.info> writes:
> 
>>> So, in the new interface, how should I handle a situation that a
>>> regression is first reported on the mailing list, added to regzbot and
>>> later there's also a bug report opened for the issue?
>>
>> You will have to options: reply to the first report with a "#regzbot
>> duplicate https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542"
>> or add a comment to the bugzilla ticket pointing to a report already
>> tracked by regzbot, e.g. "#regzbot duplicate
>> https://lore.kernel.org/not_relevant/msgid-423423423423423423/"
> 
> Oh, regzbot also follows bugzilla comments? Didn't know that, very nice.

Right not it only notices them. Commands in comments are not supported
yet, but will be once the partial rewrite lands.

> One more question, I promise it's the last one :) When using the Closes
> tag in patches does it matter which URL is used, either the original or
> the duplicate? For example, do these both tags close the issue:
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542
> Closes: https://lore.kernel.org/not_relevant/msgid-423423423423423423/

Yes, you can use either or both of them together to make regzbot close a
issue and it's duplicates. But to make Linus happy I guess he'd prefer
to have both links in there, if those are reports from different people
that contain background information that might sooner or later be handy
to have at hand.

Ciao, Thosten

Re: [regression] ath11k broken in v6.7

[Kalle Valo]

"Linux regression tracking (Thorsten Leemhuis)"
<regressions@leemhuis.info> writes:
>> One more question, I promise it's the last one :) When using the Closes
>> tag in patches does it matter which URL is used, either the original or
>> the duplicate? For example, do these both tags close the issue:
>> 
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=325423423423542
>> Closes: https://lore.kernel.org/not_relevant/msgid-423423423423423423/
>
> Yes, you can use either or both of them together to make regzbot close a
> issue and it's duplicates. But to make Linus happy I guess he'd prefer
> to have both links in there, if those are reports from different people
> that contain background information that might sooner or later be handy
> to have at hand.

Good point, I didn't consider that. I think I have now a good grasp of
regzbot and I'll try to use it actively from now on. Good luck for the
rewrite, I hope you get it finished soon.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches