regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Alexander Wetzel <alexander@wetzel-home.de>
To: Linux regressions mailing list <regressions@lists.linux.dev>,
	Felix Fietkau <nbd@nbd.name>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Mann <rauchwolke@gmx.net>,
	Stanislaw Gruszka <stf_xl@wp.pl>,
	Helmut Schaa <helmut.schaa@googlemail.com>,
	Johannes Berg <johannes.berg@intel.com>
Subject: Re: [Regression] rt2800usb - Wifi performance issues and connection drops
Date: Wed, 8 Mar 2023 17:50:05 +0100	[thread overview]
Message-ID: <ba784fc6-ad8f-e5da-ae4e-0db7ad09f7dc@wetzel-home.de> (raw)
In-Reply-To: <2246a9d5-789d-08c9-f6a7-fb9db2edfe9f@leemhuis.info>

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.
https://lore.kernel.org/linux-wireless/7cff27f8-d363-bbfb-241e-8d6fc0009c40@leemhuis.info/T/#t

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:
> https://linux-regtracking.leemhuis.info/about/#tldr
> 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=ba784fc6-ad8f-e5da-ae4e-0db7ad09f7dc@wetzel-home.de \
    --to=alexander@wetzel-home.de \
    --cc=helmut.schaa@googlemail.com \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=rauchwolke@gmx.net \
    --cc=regressions@lists.linux.dev \
    --cc=stf_xl@wp.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).