Hi Stefan,
* Stefan Sperling wrote:
> On Thu, Apr 22, 2021 at 07:47:29PM +0200, Matthias Schmidt wrote:
> > I have a kernel with your patch running since several hours and
> > noticed a regression. My usual "test case" is copying several large
> > files from my file server via NFSv3 to my laptop. In the beginning the
> > transfer rate was about 2-3M/s and after some time it dropped to around
> > 50-300K/s and never recovered (transfer is now running for 2.5h).
> >
> > I have the following device in a Thinkpad T450s connect to a Fritzbox
> > AP.
> >
> > iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78,
> > msi
> > iwm0: hw rev 0x230, fw ver 34.0.1, address
>
> The patch doesn't actually change anything in the driver's receive path for
> the 8265 chip. You might have seen a side-effect of something else that is
> unrelated to the patch, such as the wifi channel suddently becoming very
> busy with unrelated traffic. We should rule that out with a fair amount
> of certainty before trying to debug the issue. So my question would be if
> this problem is 100% repeatable with the patch and not at all repeatable
> without the patch?
>
> One possibility is that you've managed to trigger a problem in the receive
> path of net80211 with A-MSDUs enabled. Such a bug would already have existed
> but it would have been dormant since July 2019 when A-MSDUs were disabled.
>
> For 8265 devices the entire patch boils down to this change so you could
> simply revert all the other changes and try this much smaller patch instead
> to test for this regression:
I had a new kernel with only your following patch running all day and
never encountered the situation as described in my last email.
Connection was stable and transfer rates remained around 3MB/s. This is
less then the rates mentioned in your recent email but I rarely get
higher speeds. So I assume it is to my environment and has nothing to
do with the patch.
I'll now reboot to your other patch, again, and start testing again.
Cheers
Matthias
> diff 804ff40445876fb6652323b00b9804f826133e70 /tmp/net80211
> blob - a2de00f7bcdef99ced5d09da5e9b4bc8615156bd
> file + ieee80211_input.c
> --- ieee80211_input.c
> +++ ieee80211_input.c
> @@ -2758,7 +2758,7 @@ ieee80211_recv_addba_req(struct ieee80211com *ic, stru
> ba->ba_params = (params & IEEE80211_ADDBA_BA_POLICY);
> ba->ba_params |= ((ba->ba_winsize << IEEE80211_ADDBA_BUFSZ_SHIFT) |
> (tid << IEEE80211_ADDBA_TID_SHIFT));
> -#if 0
> +#if 1
> /* iwm(4) 9k and iwx(4) need more work before AMSDU can be enabled. */
> ba->ba_params |= IEEE80211_ADDBA_AMSDU;
> #endif
> blob - 5bd45d993b558bac50a513c1c4422508d96f44ba
> file + ieee80211_proto.c
> --- ieee80211_proto.c
> +++ ieee80211_proto.c
> @@ -695,7 +695,7 @@ ieee80211_addba_request(struct ieee80211com *ic, struc
> ba->ba_params =
> (ba->ba_winsize << IEEE80211_ADDBA_BUFSZ_SHIFT) |
> (tid << IEEE80211_ADDBA_TID_SHIFT);
> -#if 0
> +#if 1
> /* iwm(4) 9k and iwx(4) need more work before AMSDU can be enabled. */
> ba->ba_params |= IEEE80211_ADDBA_AMSDU;
> #endif
