wifi: mt76: mt7915e: mt7916 5GHz and 6GHz stopped working

wifi: mt76: mt7915e: mt7916 5GHz and 6GHz stopped working

[Florian Schmidt]

Hi all,

Using current firmware and kernel 6.1 (or 6.2-rc4 from wireless-testing), the 5 and 6GHz stopped working on MT7916  (from AsiaRF). It used to work with older firmware and kernel.

As a workaround, reverting to the older firmware seems to work. I can also get the 5GHz (but not the 6GHz!) to work building the driver using the workaround described on this dd-wrt bug report: https://github.com/openwrt/mt76/issues/720

How can I be of any assist investigating and fixing this issue?

Thanks,
Florian

Re: wifi: mt76: mt7915e: mt7916 5GHz and 6GHz stopped working

[Ben Greear]

On 1/23/23 5:32 AM, Florian Schmidt wrote:
> Hi all,
> 
> Using current firmware and kernel 6.1 (or 6.2-rc4 from wireless-testing), the 5 and 6GHz stopped working on MT7916  (from AsiaRF). It used to work with older firmware and kernel.
> 
> As a workaround, reverting to the older firmware seems to work. I can also get the 5GHz (but not the 6GHz!) to work building the driver using the workaround described on this dd-wrt bug report: https://github.com/openwrt/mt76/issues/720
> 
> How can I be of any assist investigating and fixing this issue?
> 
> Thanks,
> Florian
> 

We have a patch to hack the driver to allow one or the other with new
firmware.  Can post a version for 5.19 kernel soon, and we'll rebase on
something newer at some point soon.

Looks like root cause is that the mtk firmware added restrictions and cannot
be made to properly calibrate on both bands without a reboot.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: wifi: mt76: mt7915e: mt7916 5GHz and 6GHz stopped working

[Florian Schmidt]

>  On 1/23/23 5:32 AM, Florian Schmidt wrote:
> 
> >    Hi all,
> >  
> >  Using current firmware and kernel 6.1 (or 6.2-rc4 from wireless-testing), the 5 and 6GHz stopped working on MT7916  (from AsiaRF). It used to work with older firmware and kernel.
> >  
> >  As a workaround, reverting to the older firmware seems to work. I can also get the 5GHz (but not the 6GHz!) to work building the driver using the workaround described on this dd-wrt bug report: https://github.com/openwrt/mt76/issues/720
> >  
> >  How can I be of any assist investigating and fixing this issue?
> >  
> >  Thanks,
> >  Florian
> >  
>  On 2023-01-23T15:43:08.000+01:00, Ben Greear <greearb@candelatech.com> wrote:
>
> We have a patch to hack the driver to allow one or the other with new
> firmware.  Can post a version for 5.19 kernel soon, and we'll rebase on
> something newer at some point soon.
> 
> Looks like root cause is that the mtk firmware added restrictions and cannot
> be made to properly calibrate on both bands without a reboot.
> 
> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com

Thanks Ben, that's great news. Please let me know if I can be of any assist testing your patch.

Florian

wifi: mt76: mt7915e: mt7916 monitor ampdu id is invalid

[Florian Schmidt]

Hi all,

Using a mt7916 in monitor mode, I see that the AMPDU reference number is incremented for each part of a single AMPDU. Instead it should be constant, and ideally, the last subframe field should be set on the last part of the AMPDU. Capturing the same traffic with an intel AX200 show each parts of the AMPDU with the same id as expected.

This issue is still present using kernel from tag wireless-testing-2023-03-16.

How can I be of any assist investigating and fixing this issue?

Thanks,
Florian

Re: wifi: mt76: mt7915e: mt7916 monitor ampdu id is invalid

[Florian Schmidt]

>  Hi all,
> 
> Using a mt7916 in monitor mode, I see that the AMPDU reference number is incremented for each part of a single AMPDU. Instead it should be constant, and ideally, the last subframe field should be set on the last part of the AMPDU. Capturing the same traffic with an intel AX200 show each parts of the AMPDU with the same id as expected.
> 
> This issue is still present using kernel from tag wireless-testing-2023-03-16.
> 
> How can I be of any assist investigating and fixing this issue?
> 
> Thanks,
> Florian

Replying to myself, it look like a firmware issue. 

I dived a bit in the code. Toying with the code snippet below (from mt7915/mac.c), show that the firmware actually does something incorrect. It never increment the ampu_ref. This would be okay because the code below increment the ampdu_ref when the timestamp are the same for all parts of the ampdu, unfortunately, the firmware put a different timestamp to each part of the AMPDU. Because of those two conditions, the ampdu_ref is simply incremented by the driver for every single packet even when parts of the same AMPDU.

/* all subframes of an A-MPDU have the same timestamp */
if (phy->rx_ampdu_ts != status->timestamp) {
	dev_warn(dev->mt76.dev, "AMPDU Timestamp diff: ref:%d t1:%d t2:%d\n",
			 phy->ampdu_ref, phy->rx_ampdu_ts, status->timestamp);
	if (!++phy->ampdu_ref)
		phy->ampdu_ref++;
}

I guess I could maybe do some hack around this myself finding some relation between timestamp of the ampdu, computing the end time of the previous part of the AMPDU, but this would be really hacky and complicated for a workaround to what look like a firmware issue.

Is there any mediatek dev around with access to firmware sources to help with this?

Thanks,
Florian