MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Mon, 22 Nov 2021 22:21:41 +0000
From:   Robert W <rwbugreport@lost-in-the-void.net>
To:     Felix Fietkau <nbd@nbd.name>
Cc:     stf_xl@wp.pl, linux-wireless@vger.kernel.org
Subject: Re: Bug/Regression - Ralink RT2800 kernel deference issue since
 kernel 5.14
In-Reply-To: <5251bf43-a980-3398-80d6-9689f0efc926@nbd.name>
References: <c07b4142fb725ed87a2cef530bae9ee7@lost-in-the-void.net>
 <5251bf43-a980-3398-80d6-9689f0efc926@nbd.name>
Message-ID: <14a6cc0af2b352fc7add49ad01184868@lost-in-the-void.net>
User-Agent: Roundcube Webmail
Precedence: bulk

Hi,

The patch did not want to apply without rejects. I manually edited the 
file in the patch and has been running for a couple of hours yesterday 
and for 8 hours so far today without issue. Yesterdays run was against 
the backports wireless code running on 5.13 and today's due to extra 
time was built and is running on 5.15.

Thanks for your assistance and I will report back should I notice any 
further issue(s) following the change.

---
Robert

  On 2021-11-21 19:46, Felix Fietkau wrote:

> On 2021-⁠11-⁠12 22:21, Robert W wrote:
> 
>> Hi,
>> 
>> I have recently tried to upgrade a system to run the 5.14 kernel and
>> noticed that I was getting hangs on the system which seem to relate to
>> this wireless dongle which I am running hostapd against to provide a
>> small AP. Since that time kernel 5.15 was released and I have tested
>> that kernel as well and the problem persists. The issue sometimes
>> occurs within an hour and other times it takes a few hours. I have 
>> tried
>> to narrow down what is causing the issue. I thought it might be a
>> change elsewhere outside the mac80211/⁠driver area so I tried to run 
>> the
>> wireless backports 5.15-⁠rc6 on top of the last stable kernel of 5.13 
>> so
>> as to have the smallest number of changes on the system. The backports
>> crashes with the same error. I have included below the netconsole
>> output and the gdb of the kernel module in question. The capture was
>> from when I was using the backports, but the error is the same. I hope
>> the pastebins are okay to use on the list. I did try to get some
>> assistance on linux-⁠wireless IRC and some one asked for the outputs I
>> had for the information so I am reusing them here.
>> 
>> The following pastebin is the data sent to a netconsole instance.
>> 
>> https://pastebin.com/UxRrTtUh [1] [1 [1]]
>> 
>> The gdb debug of the kernel module suggests this section of code.
>> 
>> https://pastebin.com/iMzxWEVU [2] [2 [2]]
>> 
>> I am able to run further tests if required. I am not a programmer, but
>> I can usually apply code patches and build the resulting code. Please
>> let me know if require any further information.
> 
> Please try this patch:
> 
> diff -⁠-⁠git a/⁠net/⁠mac80211/⁠tx.c b/⁠net/⁠mac80211/⁠tx.c
> index 278945e3e08a..e19f6e246642 100644
> -⁠-⁠-⁠ a/⁠net/⁠mac80211/⁠tx.c
> +++ b/⁠net/⁠mac80211/⁠tx.c
> @@ -⁠1822,15 +1822,15 @@ static int invoke_tx_handlers_late(struct 
> ieee80211_tx_data *tx)
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-⁠>skb);
> ieee80211_tx_result res = TX_CONTINUE;
> + if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> + CALL_TXH(ieee80211_tx_h_rate_ctrl);
> +
> if (unlikely(info-⁠>flags & IEEE80211_TX_INTFL_RETRANSMISSION)) {
> __skb_queue_tail(&tx-⁠>skbs, tx-⁠>skb);
> tx-⁠>skb = NULL;
> goto txh_done;
> }
> - if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL))
> -⁠ CALL_TXH(ieee80211_tx_h_rate_ctrl);
> -⁠
> CALL_TXH(ieee80211_tx_h_michael_mic_add);
> CALL_TXH(ieee80211_tx_h_sequence);
> CALL_TXH(ieee80211_tx_h_fragment);

  Links:
  ------
  [1] https://pastebin.com/UxRrTtUh [1]
  [2] https://pastebin.com/iMzxWEVU [2]

Links:
------
[1] https://pastebin.com/UxRrTtUh
[2] https://pastebin.com/iMzxWEVU