archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <>
To: Linux regressions mailing list <>,
	Felix Fietkau <>
Cc: "" <>,
	LKML <>,
	Thomas Mann <>,
	Stanislaw Gruszka <>,
	Helmut Schaa <>,
	Johannes Berg <>
Subject: Re: [Regression] rt2800usb - Wifi performance issues and connection drops
Date: Wed, 8 Mar 2023 17:50:05 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 08.03.23 13:21, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 08.03.23 12:57, Felix Fietkau wrote:
>> On 08.03.23 12:41, Alexander Wetzel wrote:
>>> On 08.03.23 08:52, Felix Fietkau wrote:
>>>>> I'm also planning to provide some more debug patches, to figuring out
>>>>> which part of commit 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs
>>>>> for resumption") fixes the issue for you. Assuming my understanding
>>>>> above is correct the patch should not really fix/break anything for
>>>>> you...With the findings above I would have expected your git bisec to
>>>>> identify commit a790cc3a4fad ("wifi: mac80211: add wake_tx_queue
>>>>> callback to drivers") as the first broken commit...
>>>> I can't point to any specific series of events where it would go
>>>> wrong, but I suspect that the problem might be the fact that you're
>>>> doing tx scheduling from within ieee80211_handle_wake_tx_queue. I
>>>> don't see how it's properly protected from potentially being called
>>>> on different CPUs concurrently.
>>>> Back when I was debugging some iTXQ issues in mt76, I also had
>>>> problems when tx scheduling could happen from multiple places. My
>>>> solution was to have a single worker thread that handles tx, which is
>>>> scheduled from the wake_tx_queue op.
>>>> Maybe you could do something similar in mac80211 for non-iTXQ drivers.
>>> I think it's already doing all of that:
>>> ieee80211_handle_wake_tx_queue() is the mac80211 implementation for the
>>> wake_tx_queue op. The drivers without native iTXQ support simply link it
>>> to this handler.
>> I know. The problem I see is that I can't find anything that guarantees
>> that .wake_tx_queue_op is not being called concurrently from multiple
>> different places. ieee80211_handle_wake_tx_queue is doing the scheduling
>> directly, instead of deferring it to a single workqueue/tasklet/thread,
>> and multiple concurrent calls to it could potentially cause issues.
> Alexander, Felix, many thx for looking into this.
> This more and more sounds like something that might take a while to get
> fixed, which makes it harder to get this fixed within those time-frames
> Documentation/process/handling-regressions.rst outlines. So please allow
> me to ask:
> Is reverting the culprit (and reapplying it later once the real cause is
> found and fixed) an option, or would that cause other regressions?

This patch turned out to fix a (much worse) pre-release regression. See e.g.

To fix both regressions will force us to revert more commits other 
patches depends on...

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

  reply	other threads:[~2023-03-08 16:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-04 16:24 [Regression] rt2800usb - Wifi performance issues and connection drops Linux regression tracking (Thorsten Leemhuis)
2023-03-05 17:25 ` Thorsten Leemhuis
2023-03-05 22:05   ` Alexander Wetzel
2023-03-07 20:54     ` Alexander Wetzel
2023-03-07 22:31       ` Thomas Mann
2023-03-08  7:13         ` Alexander Wetzel
2023-03-08 10:26           ` Thomas Mann
2023-03-08 12:10             ` Alexander Wetzel
2023-03-08 12:29             ` Thomas Mann
2023-03-08  7:52       ` Felix Fietkau
2023-03-08 11:41         ` Alexander Wetzel
2023-03-08 11:57           ` Felix Fietkau
2023-03-08 12:21             ` Linux regression tracking (Thorsten Leemhuis)
2023-03-08 16:50               ` Alexander Wetzel [this message]
2023-03-09  7:59                 ` Linux regression tracking (Thorsten Leemhuis)
2023-03-09 22:13             ` Alexander Wetzel
2023-03-11 21:26               ` Alexander Wetzel
2023-03-12  8:58                 ` Felix Fietkau
2023-03-09 17:00       ` Alexander Wetzel
2023-03-09 17:29         ` Thomas Mann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).